Reporting accessibility issues as effectively as possible

Note: This post is older than two years. It may still be totally valid, but things change and technology moves fast. Code based posts may be especially prone to changes...

Number of words: 465.

(Loaded 982 times)

After researching on the net I’ve decided to pour some thoughts of mine on the brilliant WCAG-EM report tool for web accessibility evaluation

What is the most efficient and effective way to describe a accessibility issue that you have just run into when testing or maybe even just using a web site / web application or maybe even a mobile app?

As a accessibility tester I want to document accessibility problems in the most effective way possible, so that developers and designers can make it work for all users.

random QA engineer after accessibility test

Well – we can again be thankful to W3C and Web Accessibility Initiative experts because this is also thought of when they went through all the phases of improving their webpages and adding value to them:

WCAG-EM Report Tool Website Accessibility Evaluation Report Generator (opens in new window) is the way to start when you have to think about accessibility evaluation and reporting it in a most efficient way.

Just a spoiler, it boils down to the following:

  1. Map the scope – scope identification is the key for a good start, what are our goals? Are they WCAG 2.1 on level AAA? What is our main target public, personas if you will, do we have the capacity to test with real users,…
  2. Concentrate – there are some pages / parts that are popular and must work and there are some pages / parts that are probably not seen at all. Do a research, use your analytics tools, then do a manual research, be an explorer, plant some flags and reorder them by priority (value to user, business value,…),…
  3. Audit – use automatic tools at first, they should catch at least the obvious (ideally should be solved when developing and not at the end of the timeline, continuous integration should prevent commiting them to your main branch at least), use a keyboard, screen-reader combined with browser, follow checklists,…
  4. Report, start with simple and understandable summary. Everybody, also non-technical people should understand the problem. Then continue with technical details an if possible come with suggestions for a fix. Rely on ARIA guidelines as much as possible, so that person(s) resolving issue will get their acceptance criteria and also learn from them…

These points here are my own and I am sure that can be improved, so please read more about the WCAG-EM Report Tool Website Accessibility Evaluation Report Generator (opens in new window) and make your own opinion (and when you do – make sure you share it with everybody 😀 ).

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: