[Tracking issue] Findings Accessibility audit wpaccessibility.org by Level Level

[rianrietveld]

Florian Schroiff (@fschroiff) from Level Level did an accessibility audit (WCAG 2.2 AA) of wpaccessibility.org.

Issues found

Callout blocks CSS content (fixed)

SC 1.1.1 Non-text content The callout blocks have labels ("Info", "Alert", "Warning") that are added via CSS pseudo elements. Some screenreaders do not read text contained in pseudo elements. To fix this add the text as regular text. Examples of the callout boxes can be seen on https://wpaccessibility.org/docs/topics/core/ .

Solution: The CSS content will be replaced by text in the content. To prevent the text looks like a heading and should be coded as a heading, the text will be added inline and bold to the callout text
Related issue: #233

For example:

Alert: This content will be reviewed and restructured. Related issue on GitHub #122 Topic WordPress Core Accessibility Standards.

Intro section (fixed)

SC 1.3.1 Info and relationship: One blogpost has an introduction-text that is styled differently than the rest of the article. It has a very light grey line next to it and uses a larger font. This needs to be communicated to users with a visual impairment. For example by wrapping the intro in a <section> with aria-label="Introduction". Seen here: https://wpaccessibility.org/blog/2025/offer-multiple-ways-of-contact/

Solution: We will not add the section with an aria-label, but add an H2 heading with the text Summary or Introduction, depending of the content to the page when using the callout {: .lead}.
Related issue: #234

Code errors (fixed)

Code errors or classes that are not correctly added or are missing while implementing the new design:

• This blogpost also has larger intro text, but without the light grey line: https://wpaccessibility.org/blog/2025/accessible-error-messages-forms/ .
• One blogpost has an introduction-text that is styled differently than the rest of the article. It has a very light grey line (#F6F6F7) next to it and uses a larger font. The light grey line marks that this is a different type of content from the rest of the article. This means it needs to have a contrast ratio of at least 3:1. Alternatively consider removing the line. https://wpaccessibility.org/blog/2025/offer-multiple-ways-of-contact/
• Related issue: Correctly load variable.

Solution: fix the code errors.
Related issue: #235

Focusable Code blocks and tables (fixed)

SC 2.2.2 keyboard: The code blocks are scrollable but cannot be focussed with the keyboard. That means keyboard only users can't read code that overflows the container. The code examples must be made focusable, that way scrolling with the arrow keys is possible. Firefox autmatically makes overflow boxes scrollable, so it's easy to miss the issue when Firefox is your default browser. This occurs on all pages with code blocks, for example https://wpaccessibility.org/docs/topics/content/alt-text/

Note Rian: There is a tabindex on the code blocks, but to make axe Devtools shut up it must be on the direct container <div class="highlight"> and not on the wrapper <div class="language-html highlighter-rouge" tabindex="0">.

<div class="language-html highlighter-rouge" tabindex="0">
  <div class="highlight">
    <pre class="highlight">
      <code>
        [...]

Solution: Move tabindex="0" to <div class="highlight">.
Related issue: #2376

SC 2.2.2 keyboard: Tables can overflow horizontally, the container needs to be focusable so keyboard-only users can use the arrow keys to scroll sideways. Similar to the code blocks issue. We saw table overflow occur in Safari when we zoomed the page https://wpaccessibility.org/docs/topics/core/ to 400%.

Solution: Add tabindex="0" to <div class="table-wrapper">.
Related issue: #237

Sidebar menu (fixed)

SC 4.1.2 Name, role, value: When directly visiting a sub-page, e.g. https://wpaccessibility.org/docs/topics/content/links/link-image/, the sub-menus are expanded by default to show the current page in the menu. In this case the buttons that expand and collapse the sub-menu have a wrong value of "false" in the aria-expanded attribute. They are expanded, but they get announced as "collapsed".

Solution: fix the aria-expanded status toggle. Related issue: #238

The search functionality (fixed)

• SC 2.4.7 Focus Visible: The search dropdown acts as a modal, especially on smaller screens. With the screenreader it is still possible to reach content that is completely obscured by the open search modal. Consider making all content that is visually hidden unreachable by setting the attribute "inert" on it.
• SC 2.4.7 Focus Visible and 3.2.2 On Input: Mobile view: When you remove the previously entered text via backspace the empty search input will jump off screen while still being focused.

SC 4.1.3 Status Messages: When entering a search term a dropdown list with possible results appears. This change in content is not announced to screen reader users. An alert should be read, e.g."Eight results available, use down arrow".

Solution: Voiceover has difficulties pronouncing the aria-live region with the changes. Should we add a delay on the announcement? My personal view is not to do that. The code is correct, we leave it at is. This needs testing in NVDA.

Related issue: #222.

Color contrast of the search input in Safari (fixed)

SC 1.4.11 Non-text Contrast: In Safari the search form input field's lower and right borders have a very light color (#D5DADD). This has a contrast rate of 1,.7:1 with the main background color (#fcfcfc). If you make this the same color as the upper border (#333435) the contrast ratio is excellent. Seen on all pages, e.g. https://wpaccessibility.org/ (The button uses a different shade of gray (#848789), maybe they should all be the same.)

Solution: Fix the color contrast. Related issue: #239.