Skip to main content

Part 3: Follow-up accessibility audit

Published on April 05, 2019 in Audit category

W3 validator showing no errors for the Pragmatic Access homepage

In the first post of the series, I performed the accessibility audit of the homepage to get a better grasp on how to perform an audit and what things to watch for. In second post the fixes were deployed to remedy the accessibility errors.

In this post, I’ll do another audit to make sure everything works as expected and no new issues are introduced, including the other pages on the site as well. Majority of bugs should be resolved on other pages just by working on the homepage as many elements are reused (header, footer, CSS for contrast, etc.).

Tab key navigation

All actionable elements were reachable from the get-go so nothing major was worked on here. The issue with focus rings being a bit hard to see was resolved with higher contrast fixes.

Article previews were refactored so that only image and a title are clickable (are links), everything else is just a text, opposed to the first iteration where whole article bundle was a link and screen readers would read out loud the whole article summary as a consequence.

Article preview outlines

Landmarks

Footer (contentinfo) landmark was added to the root of the document so it exists alongside navigation and main. Further, header was added for the top area, but it’s not a landmark as it’s inside the main, but should help with the semantics.

Homepage HTML5 outline

The same was applied to all other pages on the site.

Headings

Nothing big, but the h2 was converted to h1 to better fit the whole structure, including the /articles as they share the same article preview code.

Homepage headings Articles headings

Automated accessibility checker

Tenon.io

To my surprise, Tenon.io now shows a bit fewer errors, but still counting at 43 issues (although when manually counted I get 33 issues). You can tell there are just 4 types of errors happening and those are:

  • (8) Actionable element smaller than minimum size. - not sure why it’s getting triggered as now all the elements are >= 44px
  • (2) This element uses absolute positioning. - understandable as it’s used for screen reader only things (like skip link)
  • (21) This may be an implicit heading. - this one is weird as it marks anything that is bold, but not a (h)eader, which leads to many false positives
  • (2) Element has orphaned aria attributes. - getting triggered on two spots where I’m not sure where the error is as everything is connected with proper ID’s

Tenon.io report

So overall I don’t see anything that needs to be fixed further. I’m in touch with Karl from Tenon.io to figure out where is the catch with these false positives.

axe

When ran against the article page, axe mentioned the issue with duplicated alt and figcaption descriptions - when using screen reader it would announce every image twice - once from the alt attribute, and once from figcaption text.

Sample image with figure caption

That is happening because I’m using caption.js library which extracts the text from alt tags (which are generated from Markdown via Jekyll) and puts them into figcaptions. I’ll create the Pull Request on that, but for now, I modified the library to set all the alt tags to nothing when showing figure captions so image descriptions are read only once. The reason why I’m using figure captions is to show sighted users a better context of the image. Still not sure if setting the alt tags to nothing is the best idea, so will need to dig deeper.

Markup validator

W3 validator happily concludes that all pages are without errors or warnings.

No warnings on W3 validator

Screen reader test

Now using VoiceOver all images have alt tags or their respective figcaption descriptions. The menu is still announced as a menu with a list of 4 items which will stay as-is, and horizontal splitters are hidden now so they are not announced at all.

Color contrast analysis

This was the most straightforward one, now contrast being >=4.50 across the board, all texts and buttons are legible at the AA level.

WCAG guidelines

Six failing guidelines were fixed so now the site is indeed Level AA accessible.

1. Perceivable

1.1 Text alternatives

  • 1.1.1 Non-text content - PASS - checked via Tenon.io - all images now have alt tags

1.4 Distinguishable

  • 1.4.3 Contrast (Minimum) - PASS - all contrast is at least 4.50
  • 1.4.11 Non-text Contrast - PASS - all contrast is at least 4.50

2. Operable

2.4 Navigable

  • 2.4.1 Bypass Blocks - PASS - skip link is implemented
  • 2.4.5 Multiple Ways - PASS - added /sitemap and /sitemap.xml in part because not sure which one counts more, which one is better
  • 2.4.7 Focus Visible - PASS - fixed with increased contrast

Summary

Majority of the time was spent on investigating how the things are actually done, reading about particular usability quirks, figure out why false positives are occurring, etc. Actually fixing them in the code was the easy part.

The next tasks will be to take some more complex website and perform an audit, implement the a11y checks in-code (build process) and figure out how to more easily write the a11y report for someone else.

Sven Kapuđija profile image
Sven Kapuđija
Author