Making Better Software for EVERYONE
What is Accessibility?
If you google for the word, you will get some definitions:
Accessibility is is also known as assistive technology. Even spectacles, pill organizers are great examples of assistive products.
not just those with a
The W3C (World Wide Web Consortium) is an international community that develop Web standards. The W3C, in cooperation with individuals and organizations around the world, they developed the
WCAG 2.0 (Web Content Accessibility Guidelines).
It is a standard with 3 levels of conformance (A, AA, & AAA).
WCAG 2.0 Level A is the minimal compliance
Some notable WCAG 2.0 Level A requirements include:
No keyboard traps
Navigable with a keyboard
Non-text content alternatives
Meaning is not conveyed through shape, size, color etc. alone
Clearly identified input errors
Language of Page is set
WCAG 2.0 Level AA is the acceptable compliance
Color contrast is, in most instances, at least 4.5:1
Alt text or a similar solution is used for images that convey meaning
Navigation elements are consistent throughout the site
Form fields have accurate labels
Status updates can be conveyed through a screen reader
Headings are used in logical order
WCAG 2.0 Level AAA is the optimal compliance
Sign language interpretation for audio or video content
Color contrast is at least 7:1 in most instances
Timing is not an essential part of any activity
Context-sensitive help is available
How to test Accessibility
Manual accessibility testing
There are some browser plugins available already that can help us. To name a few: AXE, Lighthouse, Wave, SiteImprove, Accessibility Insights for Web. These are the ones I have tried. In the end I decided to go with AXE.
Once it’s added to the browser it becomes available in the Developer Toolbar.
Once a page is analysed we not only get a list of errors but explanations and guidelines on fix too. The issue description also tells us which WCAG level contains that requirement.
Shift-left on accessibility testing
Using a checklist could help in building accessibility in. Having accessibility built in gives us many benefits. During the planning period it would worth to ask some questions, that also could be added to a checklist later on.
What to consider during the planning?
– Plan for content to be viewed in both portrait and landscape orientations
– Define the background color or color on a specified element
– Suggest fixes for user and input errors
– Support multiple languages
– Search bars to suggest common keyword phrases
– Provide a way for additional instructions and information to be displayed
… what else to add to the checklist? Please, share your thoughts!
Can accessibility testing be automated?
I have been playing around with Cypress and Axe library. Axe-core supports checks against WCAG 2.1, WCAG 2.0 and Section 508 accessibility standards.
npm i -D cypress-axe npm i -D cypress axe-core
Available cypress-axe functions:
The different standards that we can check against – from the axe-core documentation:
|TAG NAME||ACCESSIBILITY STANDARD|
|WCAG 2.0 Level A|
|WCAG 2.0 Level AA|
|WCAG 2.1 Level A|
|WCAG 2.1 Level AA|
|Common accessibility best practices|
|WCAG success criterion e.g. wcag111 maps to SC 1.1.1|
|W3C approved Accessibility Conformance Testing rules|
|Old Section 508 rules|
|Requirement in old Section 508|
This injects the
axe-core runtime into the page under test. You must run this after a call to
cy.visit() and before you run the
checkA11y(). You may also call this either in your test, or in a
beforeEach, as long as the
visit comes first.
In the code it may look like this:
Which will be used by
This will run axe against the document at the point in which it is called with the preferred options.
To educate yourself more on the topic you should visit these sites:
If you have other useful resources, share them in the comment section 🙂