Accessibility - VoiceOver iOS anchor bug

15th August, 2020

An interesting thing about accessibility work on the web is that they bring a completely new mechanism for interacting with webpages - the rotor. The rotor is a mechanism for jumping to different parts of the pages by the type of the item, this could be links, headings, tables etc.

Example of heading rotor with VoiceOver for Mac and Chrome on a blog post for

The thing about the rotor is that it removes the context you would get normally in a page so for example if you have download links for different documents in different formats you would have a grouping containing the title of the document and then the different download links just containing the format e.g. xls, csv etc.

When this example is pulled out into a rotor you get a list of links saying xls, csv over and over again which is really not helpful and would be super confusing to the user.

The solution is usually to add some additional context that only the screen reader would notice. This content is hidden using a very hackish CSS class usually called something like sr-only or visuallyhidden. These classes are very complex and fraught with danger. If you want some light reading there is an enlightening github issue about the one in html 5 boilerplate. There is also another interesting github issue where the amazing Sara Soueidan raises the possibility of getting this built in to CSS all the way back in 2016. This seems like a no brainer to me given that lots of people are having to add this in user space and that the benefits of a stable solution for users using a screen would be immense.

So basically we were bound to find places where adding visuallyhidden elements was not going to work and here is one of them.

On VoiceOver for iOS (v13.6.1) the visuallyhidden text is ignored when added inside of a link so for example from an article page

<a href="/download?id=123&format=xls">
  <span class="visuallyhidden">Download table A as</span>xls

It would read just xls and only show xls in the rotor. Which is very confusing when on an article with lots of tables!

So after some digging I found some research from Nick Colley of the frontend team who had researched this thoroughly. The best solution was to give up on visuallyhidden and switch to using aria-label.

So it became:

<a href="/download?id=123&format=xls" aria-label="Download table A as xls">

Whilst the change wasn’t drastic the complexity of getting to the solution and finding out how to resolve it was the tricky part. Additionally I did a small amount of research to how well this was supported in JAWS - the last major screen reader I don’t have access to. In my search I came across a tool similar to Can I Use but for screen readers called Screen reader reliability by PowerMapper.