Adhere to WCAG2.1 accessibility guidelines

[samccann]

Our site should be accessible to all users.

• Consider accessibility during design and implementation of the wireframe
• Find open accessibility testing tools we can apply to the new website
• Complete WCAG assessment for the homepage
• Complete WCAG assessment for blog posts

[samccann]

ideally we have some accessibility experts involved in the WG (some RH internal people have this skills)

[samccann]

This resource will help us set guidelines
https://www.ibm.com/able/

[oraNod]

This resource will help us set guidelines https://www.ibm.com/able/

Thanks @samccann There is also https://ux.redhat.com/ available.

We've reached a point where the WIP version of the web site matches the wireframe fairly closely and the structure is in place with all content loaded and css classes defined. It's time for an update on this issue and to discuss some next steps.

Firstly I feel that we can mark the "Consider accessibility at all steps of the process" complete. Actually I'm going to change the wording on that one otherwise we'll never be able to close it. There are still more steps in this process to come and accessibility is an ongoing commitment.

As far as the WIP version goes we still need to add all the media breakpoints for mobile responsiveness but we have used a 12 column grid layout with that in mind. The content is mostly text and should be easily navigable for users of assistive technology like screen readers etc. The layout of each section follows a logical order (heading 3 follows heading 2) and there is no use of semantic markup for layout. Any images are clearly labelled with meaningful alternative descriptions. In no case is an image or other visual object the sole means of communication to the viewer, etc.

There are probably some elements that are missing labels but I can use mozilla tools to navigate through the site and detect any violations. We'll need to ensure that we deal with any violations we find before go-live.

As for WCAG2.1 conformity, I'm looking at this: https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported

To my mind this makes it clear that there are two parts to truly claiming accessibility support. We're OK on the 2nd item there -- supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS) -- but the 1st item is what I'm unsure about.

For the actual accessibility testing is this something we can ask Red Hat to facilitate? I think that is the thing we need to be fully conformant with WCAG2.1. But if we do our own testing is that robust enough to satisfy requirements?

Here's a screengrab of what I see with the mozilla accessibility console:

[oraNod]

Tools we can use for accessibility testing (other than mozilla dev tools):

• https://wave.webaim.org/
• https://github.com/pa11y/pa11y
• https://github.com/marketplace/axe-linter
• https://github.com/dequelabs/axe-core
• https://github.com/nickcolley/jest-axe

It's also worth looking through https://webaim.org/standards/wcag/checklist

[oraNod]

WCAG assessment for the homepage

• Check for WCAG2.1 conformity so that information and user interface components are presentable to users in ways they can perceive
• Check for WCAG2.1 conformity so that user interface components and navigation are operable
• Check for WCAG2.1 conformity so that information and the operation of user interface are understandable
• Check for WCAG2.1 conformity so that site content is robust
• Test site navigation using appropriate assistive technology (AT).

[oraNod]

I have completed accessibility testing of the homepage using the WCAG2.1 guidelines and checklists. To the best of my ability I have tested navigability and robustness of the site using both my keyboard and text to speech functionality on an iPad.

I have verified that all colour contrasts pass WCAG A and WCAG AA tests with the following tools:

• https://webaim.org/resources/contrastchecker/
• https://webaim.org/resources/linkcontrastchecker/

I used the following evaluation tool to ensure that the site does not trigger any alerts or errors related to WCAG standards: https://wave.webaim.org/report#/https://ansible-community-website.readthedocs.io/en/latest/

I used axe-core tooling for additional quality checks and to adhere to best practices:

VSCode extension (linter): https://marketplace.visualstudio.com/items?itemName=deque-systems.vscode-axe-linter
Browser extension: https://www.deque.com/axe/browser-extensions/

Note that https://github.com/dequelabs/axe-core provides ci tools to automate testing. This tooling is more geared towards NodeJS and web applications than static sites. Now that we have a fully accessible baseline we can just do ad-hoc testing and look for issues in pull requests.

There is also a GitHub action but it requires an API key stored in a secret. I don't feel comfortable setting something like this up in a community repo and am wary of licensing concerns. It also seems like overkill for a static site. I would recommend we create a set of custom check for basic tests like an img must have accompanying alt; a href needs target="_blank"; so on.

I'll update the main README with instructions on how to test for accessibility as well.

[oraNod]

WCAG assessment checklist for blog posts

• Check for WCAG2.1 conformity so that information and user interface components are presentable to users in ways they can perceive, for example:
  -- [ ] Ensure that all images have meaningful and descriptive alternative text.
  -- [ ] Ensure that no images are the sole means to convey information.
  -- [ ] Check for contrast violations and remediate.
  -- [ ] Check for missing labels or alternative text and remediate.
• Check for WCAG2.1 conformity so that user interface components and navigation are operable, for example:
  -- [ ] Disable or ignore icons or other decorative elements for assistive technology devices.
  -- [ ] Check that section headings are used to organize content appropriately.
• Check for WCAG2.1 conformity so that information and the operation of user interface are understandable, for example:
  -- [ ] Ensure that links open to the expected target.
  -- [ ] Check buttons are predictable and behave as expected.
  -- [ ] Ensure that any user input is clearly labelled and has instructions.
• Check for WCAG2.1 conformity so that site content is robust, for example:
  -- [ ] Elements have complete start and end tags
  -- [ ] Elements are nested according to their specifications
  -- [ ] Elements do not contain duplicate attributes
  -- [ ] Any IDs are unique
• Test site navigation using appropriate assistive technology (AT).