Accessibility - VoiceOver iOS anchor bug
Published: 2020-08-17 15:10:29

---
title: Accessibility - VoiceOver iOS anchor bug
published: false
date: 2020-08-15 18:50:03 UTC
tags: 
canonical_url: https://tomandrews.co.uk/blog/2020-08-15-accessibility-voiceover-ios-anchor/
published: true
---

An interesting thing about accessibility work on the web is that they bring a completely newmechanism for interacting with webpages - the rotor. The rotor is a mechanism for jumping todifferent 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 tomandrews.co.uk](https://tomandrews.co.uk/static/9c8d8d7a86d5ede0e17bf54713fbac69/fcda8/rotor-example.png "Example of heading rotor with VoiceOver for Mac and Chrome on a blog post for tomandrews.co.uk")](/static/9c8d8d7a86d5ede0e17bf54713fbac69/09262/rotor-example.png)

The thing about the rotor is that it removes the context you would get normally in a page so forexample if you have download links for different documents in different formats you would have agrouping containing the title of the document and then the different download links just containingthe 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 andover 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 lightreading there is an [enlightening github issue](https://github.com/h5bp/main.css/issues/12) aboutthe one in html 5 boilerplate. There is also [another interesting github issue](https://github.com/w3c/csswg-drafts/issues/560)where the amazing [Sara Soueidan](https://twitter.com/SaraSoueidan) raises the possibility ofgetting this built in to CSS all the way back in 2016. This seems like a no brainer to me given thatlots of people are having to add this in user space and that the benefits of a stable solution forusers using a screen would be immense.

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

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

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

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

So after some digging I found [some research from Nick Colley of the gov.uk frontend team](https://gist.github.com/nickcolley/19b80ed24d0364cfd3afd3b1b49c4014)who had researched this thoroughly. The best solution was to give up on `visuallyhidden` and switchto using `aria-label`.

So it became:

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

Whilst the change wasn’t drastic the complexity of getting to the solution and finding out how toresolve it was the tricky part. Additionally I did a small amount of research to how well this wassupported in JAWS - the last major screen reader I don’t have access to. In my search I came acrossa tool similar to [Can I Use](https://caniuse.com/) but for screen readers called [Screen reader reliability by PowerMapper](https://www.powermapper.com/tests/screen-readers/).