Accessibility issues on the website

[NickColley]

High level

Off the back of reading the It's Disability Pride Month! Let's Get Accessible blog post I noticed that the navigation used on the website had poor colour contrast, I then ran some automated testing and found more issues.

My recommendation is to adopt an end-to-end accessibility policy where access is prioritised from people hearing about Elementary on the web all the way to them downloading it and using it.

While I understand this is a project primarily ran by volunteers more care can be taken to triaging and prioritising access barriers raised by real users and to track them in the overall project: https://github.com/orgs/elementary/projects/111. Issues like https://github.com/elementary/website/issues/3378 should be considered high priority bugs as the user is describing the download functionality to be completely broken.

Website accessibility

Through some very quick reviewing examples of issues look like:

Colours used are hard to read

In this example one of the most important elements, the download button does not have sufficient contrast between the text colour and the background, this could mean that some users with visual impairments struggle to read what the button says.

This sort of issue can be seen elsewhere for example the blog post page has particularly low contrast (2.10) for the main navigation

Potential solution here is to increase the contrast so that these meet 4.5 contrast ratio at minimum.

Easy to get lost when using a keyboard

If you tab through the homepage some elements have focus styles and others have no styles at all which makes it very difficult to know where you are on the page if you're using a keyboard to navigate, this could mean some users with physical impairments will find it hard to get around the website.

Potential solution here is to add clear focus styles for all tabbable elements.

Images are not described non-visually

There are many images that do not have alternative text, this could mean some users of screen readers, for example blind users, will not know what the images mean.

Potential solution here is to add alternative text to all non-presentational images.

These examples are non-exhaustive I have spent very little time putting them together, to properly understand the amount of barriers that exist I propose the following next steps:

Next steps

1. Go through existing GitHub issues and triage and label any access barriers already raised
2. Do a review of the most important web journeys
   • [ ] Create a list of the web pages most used and critical for using Elementary e.g. downloading the distro, asking for help.
   • [ ] Run automated testing and manual testing using a tool like https://accessibilityinsights.io †
   • [ ] Raise found access barriers as GitHub issues with severity attached for prioritisation
3. If issues are simple and high impact, fix them ASAP
4. Review the overall process for prioritising work so that accessibility work is not stuck in backlogs and is actively pushed forward.
   • [ ] Consider bug bounty for access related work
5. Review existing design process end-to-end to see where accessibility can be promoted to avoid new issues in the future.

† Ideally we'd do a full expert review and then user testing with disabled people but for now I think this is pragmatic first step.

[NickColley]

Went through the existing issues...

Issues that need triaging as potential access issues:

• https://github.com/elementary/website/issues/3378
• https://github.com/elementary/website/issues/2849
• https://github.com/elementary/website/issues/2725

[NickColley]

I think that trying to get to the point where the standard for the website is meeting Web Content Accessibility Guidelines (WCAG) to level AA would be a good start as well.

[danirabbit]

thanks for doing this investigation and building interest around this topic! There’s definitely a lot to do here

Gonna convert this to a discussion since it’s more of a meta thing and not a concise actionable individual issue