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.
contentinfo) landmark was added to the root of the document so it exists alongside
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.
The same was applied to all other pages on the site.
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.
Automated accessibility checker
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
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.
When ran against the article page, axe mentioned the issue with duplicated
figcaption descriptions - when using screen reader it would announce every image twice - once from the
alt attribute, and once from
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.
W3 validator happily concludes that all pages are without errors or warnings.
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.
Six failing guidelines were fixed so now the site is indeed Level AA accessible.
1.1 Text alternatives
- 1.1.1 Non-text content - PASS - checked via Tenon.io - all images now have
- 1.4.3 Contrast (Minimum) - PASS - all contrast is at least
- 1.4.11 Non-text Contrast - PASS - all contrast is at least
- 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
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.