Reading/Web/Desktop Improvements/Repository/Accessibility testing

Translate this page

As a part of the Vector 2022 skin evaluation, the Web team wanted to test its decisions around accessibility changes and improvements from the previous Vector legacy skin. We wanted to ensure we are providing a better experience for all of our users. In this work, we partnered with the American Foundation for the Blind (AFB) for a comprehensive review of the new Vector 2022 site.

Summary of results

Overall, both the Vector legacy and Vector 2022 skins were assessed to be acceptable from the accessibility and usability perspective, with no major concerns. AFB noted potential areas for improvements, which the team will classify and address in the future and take into consideration when developing new features and tools.

Full report

How are your impressions of the landmark regions in Vector 2022 vs Vector legacy?

For Vector 2022, the landmarks work well with JAWS and NVDA. They are helpful in the footer, nicely separating the various sections. The 4^th landmark is spoken by screen readers as “Contents [hide].” The word “hide” could be confusing and should be removed. The 6^th landmark is spoken by screen readers as “Namespaces,” which is not a particularly meaningful label and could be confusing to users.

For Vector legacy, the landmarks work well with JAWS and NVDA. As with the Vector 2022 site, the Namespaces landmark would benefit from a more meaningful name.

In general, both the 2022 and Legacy versions are fine from an accessibility and usability perspective. The 2022 version could benefit from improvements to the two landmark names mentioned above. Because the headings are done so well in the main content, no landmarks are less important within the main content of the page.

How are your impressions of the heading structure in Vector 2022 vs Vector legacy?

The heading structure is very good in both the 2022 and legacy versions. Each has proper headings where needed and there is proper heading level hierarchy throughout. This makes it very easy for a screen reader user to find and navigate to sections of interest and to understand the structure and layout of the page.

Your impressions of the ordering of elements in the DOM and general semantic structure in Vector 2022 vs Vector legacy

Vector 2022 moves the page toolbar below the page titlebar and into <main>. This has resulted in keyboard users needing to tab through more elements before reaching the article text (more context). What's the best approach to maintain the experience for keyboard users while adhering to accessibility best practices?
- The “Jump to content” link plays a big part in this being better for keyboard users. Users can quickly use that link to skip over the navigation element. This may also be better for keyboard users that are unfamiliar with the keyboard layout of Wikipedia since the legacy layout is set up for the content to be focused first rather than the navigation which can be backwards for most users. For screen reader users, this change does not have a big impact since they can navigate around the page quickly with screen reader shortcuts.
How important is it for the TOC to be inside <main>?
- This is not a very important aspect to most users. There is really no standard way of doing it one way or another. Users will most likely have seen both types of implementations. The TOC being in the <main> is not as important as the TOC being above or before the main content, referring to the main content rather than the main landmark.

We employ the checkbox hack in our dropdown menu implementation to support no-js users. How accessible are our dropdown menus to screen reader users? Specifically the user menu dropdown and the language dropdown in Vector 2022 (no need to evaluate the contents of the language popup).

For the Language menu, the placement in the DOM seems a little strange, when pressing shift+tab, I would expect my focus to go back to the Language button to allow me to close it. Requiring the escape key to close or dismiss the dropdown may make it difficult for some users to understand. The addition of a close button would help with this. For screen reader users, the button itself was clearly defined as a button and opened with enter or space which is to be expected. After closing the menu, with NVDA, focus returns to the top of the page rather than the Language button.

For the User menu, the focus order and DOM placement appears to work as expected. However, the escape button does not appear to close the menu as would be expected. The name of the menu may also cause some confusion. For screen reader users, it is presented as “Personal Tools”, but the title attribute indicates that it is also the “User menu”. This could cause some confusion for a sighted user attempting to instruct a screen reader user on where to find their user settings. There was one issue when using JAWS where you are in what seems to be “forms mode” when expanding the menu. You have to activate the PC cursor by pressing escape or JAWS Key-colon and then you can arrow through those menu items. Alternatively you can tab through the menu items.

Additionally, what are your thoughts on this alternate option, which uses aria-hidden on the label element to reduce verbosity for screen readers?

This would be an improvement for screen reader users. When navigating with the arrow keys, the screen reader announces the button a single time rather than twice where the second announcement does not provide any additional information.

How does the accessibility of the table of contents compare in Vector 2022 vs Vector legacy? Including the collapsed TOC implementation on viewports under 1000px.

With the Vector 2022 layout, the focus order of the TOC is incorrect when under 1000px. After expanding the TOC, pressing the tab key does not place focus inside of the TOC menu. Pressing shift+tab will place focus at the bottom of the TOC. The TOC does not dismiss after pressing the escape key.

The legacy TOC does not really change much for screen widths under 1000px. However, the advantage of the Vector 2022 layout is that the TOC appears above the content rather than embedded within the article. This makes it a lot easier to access.

The sticky header in Vector 2022 is entirely hidden from screen reader users given it contains purely duplicated content. What do you think of this approach?

This is the approach that we recommend for most sticky headers. If the sticky header is not hidden from screen readers, users may encounter the sticky header when pressing ctrl+home which has a slightly different layout than the normal header. This could be confusing to some users. The current approach of having the sticky header is the best compromise.

How accessible is the contents of the language dropdown in Vector 2022?

The only notable issue with the contents of the language dropdown is that the search field is only labeled using placeholder text. VoiceOver is out of scope for this testing, but there are issues with providing an accessible name for fields using only placeholder text with VoiceOver. After entering text into a field that is only labeled using placeholder text, VoiceOver will no longer announce the accessible name for the field. This issue is not present on NVDA and JAWS.

Does Vector 2022's search field fulfill user expectations in regards to keyboard and screen reader accessibility and is beneficially usable?

When encountering the search field, NVDA announces “Search Wikipedia combo box collapsed has auto complete editable Search Wikipedia [alt-shift-f] Alt+f Search Wikipedia blank”. This is a lot of information for screen reader users. There is a combination of attributes that is contributing to this:

Title attribute: Search Wikipedia [alt-shift-f]
aria-label attribute: Search Wikipedia
placeholder attribute: Search Wikipedia
accesskey attribute: this is causing the alt+f announcement. Pressing alt+f in Chrome only opens the Chrome menu and doesn't focus the field

These 4 attributes are causing duplicate announcements. The aria-label attribute can be removed since it contains the same information as the title attribute and the title attribute is providing supplemental information on mouse hover.

The accesskey and title attributes are causing conflicting instructions. This is due to Chrome requiring the shift modifier key for some accesskeys but not others. We do not have a good solution for this issue.

There also appears to be a “Go” button that only appears before the search field. This can only be seen if the search field never gains focus. For screen reader users this is only encountered when navigating in browse mode.

Does our analysis of accessibility requirements for the in progress Page Tools feature (design prototype, task) cover accessibility concerns?

Yes, we believe that the accessibility requirements are sufficient for this feature. In general for a feature like this, we would be looking for the following items:

Discoverability: This is covered by the landmarks
Focus management: There appeared to be some tasks related to making sure that the content was focused immediately after the toggle button in the DOM. One point for this would be to make sure that focus is placed correctly after pinning and unpinning. Sometimes screen readers will move focus back to the top of the screen if the element that is currently being focused disappears from the DOM.
ARIA Spec: It appears that the disclosure widget was chosen for this which would be a good fit. It is always important to try and find what ARIA widget would be best for more complex solutions like this.