Below are a handful of observations from user testing on mobile websites and applications I’ve seen recently. All users had some form of disability including people with limited mobility, sight impairments, cognitive impairments dyslexia or hearing loss. Testing was carried out using Android or iOS with blind users accessing using the TalkBack or VoiceOver screen readers respectively. For obvious reasons I can’t share with you any details about the products.
Disclaimer: This is purely based on my observations and should not be taken as fact. I’ve added in commentary and interpretation but again this is my own opinion. What I’m really interested in is hearing what you think, especially if you are a disabled user.
Apps versus browsing
Many users say they use native apps over and above browsing.
[Apps are] quite focused, I find it easier than the website – A blind iPhone user
This makes sense. Apps are tasked based, have less clutter and tend not to cross sell information. Standard UI components for iOS and Android also come with accessibility baked in for screen reader users i.e they have the correct trait and hint assigned so elements can be identified and explained correctly to the user by their software. All the developer needs to do is assign a label (alternative) to describe the component. As Alistair Campbell pointed out when we discussed this, activating a button within an app takes you directly to the next step in whatever you are doing. On a website however activating a link will most likely refresh the page which you have to navigate within in order to get to the place where you left off.
Many screen reader users tend to navigate using headings over and above landmarks. Users who were aware of landmarks didn’t always seem to bother using them. The following user didn’t have landmarks set up as an option within Web Rotor on their iPhone.
I find they’re not particularly used that well – A blind Jaws and iPhone user
I’d have to agree – an issue that affects both desktop and mobile. It’s hard to say why users aren’t making the most of landmarks but recent research from WebAim on how screen reader users access the web did suggest usage is on the increase. There is fairly good support for landmarks by screen readers and browsers alike (on both desktop and mobile) so my guess is we are not implementing them in a way that is as useful as they could be. It’s also likely that not all users know they exist.
It’s important to consider content order and placement of headings in relation to landmarks as what is announced by the screen reader can vary. For example:
- Jaws for Windows announces “Navigation region start” and “Navigation region end
- NVDA 2012.3 for Windows announces “Navigation region start” nothing at the end
- iOS VoiceOver announces “Landmark start” and “Landmark end” . It fails to identify which landmark (in this case ‘navigation’) opting instead to announce the next item in the content order together with the ‘landmark start’
- Android TalkBack announces “Navigation” but nothing at the end
This means placement of appropriate content such as a heading after the landmark in the code order or use of aria-label is worth considering in order to make them more helpful. I’ve written a little bit more about this in usable landmarks across desktop and mobile.
Portrait versus landscape
Quite a few disabled users, not just screen reader users, don’t use landscape and may even lock their screens so they can’t go into landscape.
I don’t use landscape, the speaker gets covered so I can’t hear, so far as I know other blind people do as well – A blind user of iPhone
Aside from covering up the speaker possible reasons for not using landscape for screen reader users might be that there is no need to rearrange screen real estate in order to better read text, watch video or play games. Having said that this might not be the case for a sighted screen reader user, such as someone with cognitive impairments, who rely on the speech to help them understand what’s happening on screen. A blind user might also want to minimise changes in layout and content that sometimes occurs when moving from portrait to landscape. It can be frustrating to have content appear or disappear and potentially change the structure of a page.