Accessibility

Requirements and resources

Every day is a chance to work hands-on with accessibility. Being good at accessibility is the same as being good at building interfaces because it’s done simultaneously.

When we talk about accessibility as its own thing, we refer to:

• Certain criteria we, as people of expertise, should take pride in fulfilling.
• Legal requirements based on a selection of mentioned criteria.
• Tools and methods that help us check our work and increase our experience.
• Reasons why accessibility is important and why MVPs aren’t viable if they don’t fulfil the criteria.

Meeting WCAG 2.2

Mybring’s goal is to meet WCAG 2.2; the design system covers many requirements by default but doesn’t relieve anyone of their responsibility when developing our services.

Current legal requirements are based on 35 of the 61 criteria in WCAG 2.0, but we try to avoid aiming for lower standards when building new things.

The Authority for Universal Design of ICT’s resource list for WCAG 2.0 is, ironically, in Norwegian only. However, there exists a decent resource in English. The WCAG 2.2 standard is also a good reference.

Tools and testing

We don’t need to remember everything in a spec, but it helps to know the main areas and to use some tools that can help us checking what we make. Automation can check things like contrast, colour, sizes, ARIA attributes and correct use of HTML elements, but only to a certain extent.

Some things to verify manually

• Write valid code in a logical structure; it’s a good base for accessibility and responsiveness. There are a lot of HTML elements, besides div and span, with both meaning and functionality.
• Navigate the interface using the keyboard to ensure links, inputs and buttons are reachable by tabbing and in a logical order.
• Zoom, change font size and resize your browser to simulate different scenarios.
• ARIA is a language that somewhat extends HTML and should only be used when necessary.
• Don’t use Bring green against white on meaningful content, it fails minimum constrast tests.

Plugins and crawlers

• Browser developer tools’ accessibility inspection.
• Wave standalone API, runners and Firefox and Chrome extensions.
• SiteImprove - Accessibility Checker compliance checks and how to fix them. Includes color blindness simulation. For Chrome, Firefox, Opera and Edge.
• ARC toolkit Chrome extension
• Lighthouse in the Chrome dev tools and extension for Firefox.
• Axe for Firefox, Chrome and Android.
• Axe-core node module to integrate with automated tests.
• Equal Access Accessibility Checker for Firefox
• Equal Access Accessibility Checker for Chrome

Screen readers and simulators

• Sara Soueidan’s guide to setting up a screen reader testing environment – you should at least have tried the one that comes with your computer.
• Silktide - Accessibility checker for Chrome. Various tools such as disability simulators, keyboard navigation focus order, screen reader, compliance checks etc.
• Let’s get color blind for Firefox (some more options than the one included in SiteImprove accessibility checker)
• Web disability simulator for Chrome.
• ChromeLens - visual impairment simulation for Chrome.

Validators and other resources

• Nu HTML checker
• CSS validator
• stylelint.io
• If you want to take a deep dive, Adrian Roselli’s articles are informative and have a practical approach.

What happens if we don’t comply?

Universal accessibility enables as many people as possible to use the web. Without it, some might be unable to do their job, others have bad experiences, and some might dread using our services. It ultimately affects our continued ability to offer our services.

There are also fines for not complying. Don’t develop to avoid fines. Develop to give users the tools they need.