WCAG compliance

[m-mikulica]

fix: accessibility and theming improvements

• Add visually-hidden labels for search inputs (CC, FIPS, PP search pages, CVE/CPE vuln search)
• Fix heading hierarchy: change "Search" subheading from h3 to h2 on all search pages
• Add empty table header label "Actions" in FIPS MIP and IUT index tables
• Refactor status badge colors: replace Bootstrap text-success/warning/danger with custom
  CSS classes (status-active, status-archived, status-historical, status-revoked) supporting
  separate light/dark mode colors via data-bs-theme selectors in base.css
• Split btn-outline-primary color overrides into light (#0060F0) and dark (#85B6FF) themes
• Add alert-primary link color override for light mode (#0a58ca)
• Fix research link color in index page analysis section using CSS custom property override

[jborsky]

This should address #574.

Thanks. I'll review it in the coming days.

Worth noting that I'm currently reworking the search UX, so the version these accessibility fixes apply to will likely be replaced, though there won't be major UI changes, just more inputs, columns, filtering options and so on. I'll make sure to check accessibility before that lands. But everything outside the search is relevant.

[jborsky]

I've tested the branch with WAVE and axe DevTools and still got some things flagged:

Main page

• research link in the Trend Visualization section has insufficient contrast
• Project, Quick links, and Contact us in the footer look like headings visually but aren't using actual heading tag, so screen readers won't treat them as headings

Certificate page (such as https://sec-certs.org/cc/bbfc9f8bead71236/)

• several contrast issues
• aria-label attribute cannot be used on a span with no valid role attribute

Login page:

• Sign in with email or GitHub has insufficient contrast in dark mode

Can you run through the tools again and make sure nothing is flagged?

Also, please manually verify that the page can be navigated using only a keyboard and that it functions well with screen readers. For instance, I wasn't able to select the feedback button on the side of the page using just the keyboard, which violates criterion 2.1.1 of the standard.

Here I also found a checklist that may be useful:
https://webaim.org/standards/wcag/checklist

[jborsky]

Need to resolve issues identified by automated tools and perform manual testing using a keyboard and screen reader.

[J08nY]

• Project, Quick links, and Contact us in the footer look like headings visually but aren't using actual heading tag, so screen readers won't treat them as headings

I thought I fixed this even before this PR. Hmm. Maybe not. Is there another way to make them like headings without being headings? Should they be headings?

• aria-label attribute cannot be used on a span with no valid role attribute

I guess role=tooltip may work?

[jborsky]

I thought I fixed this even before this PR. Hmm. Maybe not. Is there another way to make them like headings without being headings? Should they be headings?

I think they should, as they label distinct groups of links. According to additional details from the flagged issue in the tool, it can be done using role="heading".

https://docs.deque.com/advanced-rules/1/en/advanced/heading-markup

[m-mikulica]

I did manual testing with WAVE tool and AXE accessibility on every page in both modes. The only errors I got were on the /cc/network/ page, where is the graph and the links inside have no discernible text. I also did manual testing of keyboard-only navigation on the website and it worked well.

[m-mikulica]

I just tested the whole page with Linux Orca screen reader and it works well. The only problem page is again the cc/network/ page with the graph, where it reads every one of 900+ nodes.

[m-mikulica]

Checked the new EUCC pages with ORCA screen reader and WAVE tool + AXE dev tools accessibility test and everything was alright.