Automated Accessibility Reports
First, most accessibility reports are long! Even on a website with relatively few accessibility issues, reports can be 50 pages, and some may run upwards of 100 pages. While reading, understanding, and acting on the data provided in these reports can seem like a daunting task, just remember that accessibility is an ongoing effort and we’re here to support you.
Breaking Down the Report
Accessibility reports are generally broken into several sections, the most common of which are:
Overall Accessibility Score
The overall score is generally an average of the scores your website receives in other sections of the report. This score can be raised by focusing on the improvements detailed in the sections below.
Quality Assurance
The quality assurance component encompasses multiple individual items, but some of the common errors that surface in this area include:
- Broken Links.
- HTML errors (empty containers, unclosed paragraphs, etc.).
- Console or JavaScript errors.
Accessibility
The accessibility section focuses on the Web Content Accessibility Guidelines (WCAG) compliance of your website. This is often divided by level (A, AA, AAA) or by confirmed versus potential issues.
Compatibility
Website compatibility flags device and/or browser errors encountered when using the website. Common issues include errors with Apple or Safari, or those related to Internet Explorer 11 or older browsers.
Search (or SEO)
This section provides recommendations on how to improve Search Engine Optimization (SEO) on your website. This section may be less actionable, as search engines rank using algorithms. While the advice offered may be useful, actions taken may not directly improve scores in this area.
Focus on Accessibility
While all sections of automated accessibility reports are useful—and addressing errors and issues will contribute to the overall usability of your website—we’re going to focus on how to best address accessibility issues.
WCAG Overview
Web Content Accessibility Guidelines are broken up into four principles that include 13 guidelines, each of which include additional rule breakouts (notated by the numbers included in parentheses below).
Perceivable
- Text Alternatives (1)
- Time-Based Media (9)
- Adaptable (6)
- Distinguishable (13)
Operable
- Keyboard Accessible (4)
- Enough Time (6)
- Seizures and Physical Reactions (3)
- Navigable (10)
- Input Modalities (6)
Understandable
- Readable (6)
- Predictable (5)
- Input Assistance (6)
Robust
While this level of detail can seem overwhelming, it’s important to note that most issues fall in the Perceivable or Operable categories, and many of them can be addressed with simple updates.
Addressing Issues
Break the List Down into Manageable Chunks
When faced with resolving potentially hundreds of items, it can be hard to figure out where to start. To make the task more approachable, try to find ways to break it down into smaller chunks.
Start by focusing on meeting the accessibility rules that apply to your organization. While it’s important to work toward achieving all of the requirements long-term, focusing on what your organization is mandated to uphold is a good initial focus.
Options for Approaching
If you have a good grasp of the WCAG rules and are confident in the accessibility direction you should take, or if you have dedicated content teams in place for each section of your website, break the list out by sections of the website. This allows individual departments—Parks, Police, Public Works, etc.—to work on improving their specific web pages.
However, if you are just starting your journey into WCAG, or if your website content team is small, break the list out by type of issue. With this approach, you can tackle one area at a time; for instance, focusing on all of the perceivable criteria before moving to the next set.
Resolving Specific Issues
Once you select an issue to focus on, determine which accessibility rule is being broken, then read the details of that rule. Siteimprove and other accessibility scanners often call out what is being done wrong, but may not provide information on why it’s wrong, or which rules are being broken.
For example:
In this case, the dashboard doesn’t provide information on which rule is being broken or the specifics on how to fix it. A Google search for “WCAG Headings” leads to a specific rule from www.W3.org, which explains the purpose of headings is to provide a sense of the page structure for sighted users (via visual hierarchy) and screen reader users (via Accessibility tools).
In this example, an empty heading may be causing an odd visual break on the page. To a screen reader, it can be either a small error or a larger worry. If the screen reader user is jumping from heading to heading and finds an empty one, it needs to determine if there is simply no content or if there is content that can’t be accessed. This can necessitate switching modes and then slowly navigating word by word to make sure important information isn’t missed.
The next step is to find the page the error is on. The report should show which page the issue is on, and often what line of the page. Use that information to locate the error on the page. From there, determine if the problem is coming from your content or if it’s something created by your content management system (CMS) or web development provider.
Edge Cases
Edge cases are possible. In this example cited above, if the heading is hidden with a “display: none” rule via CSS, it should have no visual impact and screen readers will skip it. While it may not be optimal code, it’s not a WCAG violation, as it’s not in the hierarchy of the page, nor is it impacting user access. In this case, the error can be marked as a false flag for the purposes of accessibility score.
The resolution in this example is simple: Either the empty heading should be removed, or it should have content added to make it useful and clear. If it’s not something that you can control, move the issue to a separate list to report to your CMS/website provider. There may be a good reason why it is set up this way and a website provider should be able to either provide that information or steps for resolving the issue. Purely design-related issues may need to be handled via a website refresh or redesign, depending on where the issue is, or the complexity of the resolution.
Steps to Follow
As a recap, here are the steps to follow:
- Identify the issue.
- Identify the rule.
- Locate the issue on a page.
- Consider the edge cases.
- Resolve the issue.
- Repeat.
And remember, while automated accessibility scanners are useful tools, they often flag items that aren’t truly accessibility issues. Your job is to review the report with your new WCAG knowledge to identify and resolve true accessibility issues. Your community will thank you!
