Skip to Main content

Non-Functional Requirements

Use this page when feature work looks finished and you need to prove the frontend is ready for real traffic. It focuses on practical checks for SEO, accessibility, security, and HTML validity, plus the evidence worth keeping before you call the work done.

Use these checks after the main UI work is in place and before you hand the page to QA or backend integration. The aim is not to chase a perfect score. The aim is to catch the issues that can quietly slip into production and become harder to fix later.

SEO

Use PageSpeed Insights as the first pass. It is fast, easy to share, and good at exposing the obvious problems before performance concerns spread into QA, SEO, or stakeholder feedback.

Suggested flow

  1. Open the target page in PageSpeed Insights.

  2. Run both the mobile and desktop reports. Mobile usually exposes the more painful regressions first.

  3. Review the SEO section, then cross-check the Performance and Accessibility sections if the reported issue overlaps with rendering, heading structure, or image handling.

  4. Fix the frontend issues you actually own, then rerun the report on the same URL.

What to verify

  • The page has a clear title and meta description.
  • Important images include useful alt text when they carry content.
  • Links and buttons have accessible names instead of mystery meat markup.
  • There are no avoidable SEO warnings caused by broken headings, missing metadata, or non-descriptive anchors.

Accessibility

Use the WAVE Evaluation Tool on the rendered page rather than on design files or screenshots.

Suggested flow

  1. Open the page in a browser and run WAVE.

  2. Fix every reported Error. Treat these as blocking issues.

  3. Work through Contrast Errors next. Design intent does not help much if the final contrast is still difficult to read.

  4. Review Alerts, Features, Structural Elements, and ARIA results to confirm the page still makes sense to screen readers and automated tooling.

  5. Re-test after each meaningful batch of fixes until the report is stable.

What to verify

  • Every interactive element is reachable and usable with a keyboard.
  • Form controls have visible labels or an equivalent accessible name.
  • Heading order and landmark regions make sense when read out of visual context.
  • No WAVE errors remain on the tested page.

If the page includes forms, the Create accessible forms article is a useful companion reference.

Security

Use Mozilla Observatory or ImmuniWeb for an external scan of the deployed page. These tools are most useful when the page is already reachable in a public or preview environment.

Suggested flow

  1. Scan the target environment with at least one of the tools above.

  2. Start with the high-impact findings that frontend work can influence directly: CSP compatibility, third-party assets, inline scripts, inline styles, and missing security attributes.

  3. Coordinate with the backend team for headers and cookie policies, but make sure the frontend markup does not force insecure exceptions.

  4. Re-run the scan after fixes or after backend header changes land.

HTTP Observatory

The report covers more than the frontend can control, but these are the items worth checking before you hand the work over.

Content Security Policy

Move inline scripts and styles into asset files whenever possible. If something truly must stay inline, wire it so the backend can attach a nonce and include that nonce in the final CSP header.

<script nonce="some-random-string">
  // some script
</script>
<style nonce="some-random-string">
  /* style */
</style>

For the final policy, avoid unsafe-inline in script-src and style-src, and avoid unsafe-eval in script-src. The frontend team's job is to keep the markup compatible with a strict policy so the backend team can finish the header implementation without unnecessary rework.

Verify the result by checking that required scripts and styles still load correctly after the stricter policy is applied.

Subresource Integrity (SRI)

When you must load a third-party asset from a CDN, add an integrity attribute if the resource is stable enough to support it.

<link
  rel="stylesheet"
  href="https://cdn.other-domain.com/assets/script-v1.2.3.js"
  integrity="sha512-jnSuA4Ss2PkkikSOLtYs8BlYIeeIK1h99ty4Y..............."
  crossorigin="anonymous"
  referrerpolicy="no-referrer" />

The browser compares the downloaded file with the supplied hash. If they do not match, the resource is blocked instead of being executed quietly.

Some third-party scripts change too often for SRI to be practical. That is not a reason to ignore SRI completely. Use it wherever the asset version is pinned and predictable.

Verify the result by reloading the page in the browser and confirming that the protected resource still loads without console errors.

Nu Html Checker

Use Nu Html Checker near the end of the task, once the page is rendering correctly. It validates the output HTML, which is what browsers and assistive technologies ultimately receive after templates, scripts, and integrations are applied.

  1. Validate the rendered page URL, not just the component source. If the page only exists in a preview environment, use that preview URL.

  2. Start with validation errors. Fix invalid nesting, duplicate id values, illegal attributes, broken form markup, and incorrect ARIA usage before you spend time on warnings.

  3. Re-run the checker after each batch of fixes. A single broken wrapper can generate a surprising number of follow-on errors further down the document.

  4. If the same component appears on multiple page types, validate more than one page. Shared markup issues often appear in more than one place.

What it is good at catching

  • Invalid HTML structure such as nested interactive elements or elements in the wrong parent.
  • Duplicate id attributes.
  • Invalid or obsolete attributes.
  • Incorrect ARIA roles, states, and relationships.
  • Form markup that looks fine visually but is not valid in the DOM.

What to verify

  • The target page completes with no validation errors.
  • Remaining warnings, if any, are understood and intentionally accepted rather than ignored because the page still "looks fine".
  • Fixes made for validity do not break styling, JavaScript behavior, or analytics hooks.

Nu Html Checker is not a replacement for accessibility testing, but it is excellent at catching invalid markup early. Use it as a last structural sweep before you mark the frontend work as complete.