How accessible is my post about accessibility?

The accessibility empathy lab at the Government Digital Services building

tl;dr

Keep yourself honest by checking how accessible your digital work is. Tenon is a web-based tool that can help with this.

Digital accessibility

I wrote about an accessibility workshop at the recent Sprint 18 conference.

I’ve since been to a more in-depth workshop with Government Digital Service (GDS), who have just launched the latest version of their ‘testing for accessibility’ guidance in the Service Manual and also the GOV.UK Design System, which contains reusable GOV.UK styles, patterns and components with accessibility in mind.

At the session I learnt a bit more about some web-based services that can evaluate web pages against the Web Content Accessibility Guidelines (WCAG 2.0). Tenon and WAVE were mentioned specifically and you can find more in the World Wide Web Consortium’s (W3C) list of web accessibility evaluation tools.

What better way to investigate one of these services that to test it on myself? I’m going to assess the accessibility of my post about accessibility (at time of writing). So meta.

Tenon example

Tenon is a web service that tests for compliance against WCAG 2.0¹. It reports back on errors and warnings and assigns an order of priority for fixing the problems.

Tenon offers an API for automating accessibility tests. You can test the service in your browser by inputting a URL into the search box on their website.

Output

The service reported back that 4 of 74 tests failed for the post.

In-browser results of Tenon’s test

The in-browser output also provides a CSV report of the failures. I’ve hosted my report in a GitHub Gist.

An example of an error is that one of my images was missing alt-text. Tenon reported:

• the line of HTML code causing the error
• the priority for fixing the issue
• the line location in the HTML code
• the specific WCAG 2.0 guideline that was breached
• a description of why this is a problem
• a link to a recommended fix for the problem

Example of an error, where it is, and a recommended fix

Reflection

Not too bad.

The default settings for the blog’s Hugo theme was accountable for at least one issue: the Hugo logo in the footer is missing alt-text, so it can’t be described by a screen reader.

I also had problems where I actually did have alt-text in place. These were identified as being too long. I tried to be as descriptive as possible, but went too far. For example, I used these 24 words for one image:

Thumbnail views of example posters including designing for users on the autistic spectrum, for users of screen readers and for users with low vision

That’s verbose. I could do this in half the number of words:

Posters by the Home Office showing the dos and don’ts of accessibility

The use of implicit headings was also flagged. This was because I had whole lines—audience questions—tagged as <strong> (meaning bold). It would be preferable for all section titles to use the header tags (first-level header is <h1>, second-level is <h2>, etc), since these a recognised specifically by screen readers.

Behaviour change

I will:

• keep my alternative text short but descriptive
• use explicit headers using the HTML header tags (<h1>, etc)
• investigate default settings for accessibility before using them

Other improvements could be made. For example, I also ran the webpage through WAVE web accessibility tool and one of the errors was the low contrast between the white background and the light grey of the date and author name. These could be made darker.

The obvious next step is to assess the accessibility of my post that assesses the accessibility of my post about accessibility. Or perhaps the world isn’t ready for accessibility inception.

‘Design accessible services’ advice posters made by the Home Office

Environment

Session info

Last rendered: 2023-08-08 22:38:04 BST

R version 4.3.1 (2023-06-16)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.2.1

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.11.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: Europe/London
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] htmlwidgets_1.6.2 compiler_4.3.1    fastmap_1.1.1     cli_3.6.1        
 [5] tools_4.3.1       htmltools_0.5.5   rstudioapi_0.15.0 yaml_2.3.7       
 [9] rmarkdown_2.23    knitr_1.43.1      jsonlite_1.8.7    xfun_0.39        
[13] digest_0.6.33     rlang_1.1.1       evaluate_0.21    

Footnotes

1. Other tools are available. I mention this service because it was discussed specifically in the workshop.

Reuse