If you use a screen reader, you’ll now get feedback when you “Like” a comment on FutureLearn – something which rarely happens on other sites and social networks. Our Front-end Developer, Nicky Thompson, explains how we recently fixed this accessibility problem.
At FutureLearn, we try to design for everyone, everywhere. This means that, as well as designing mobile-first, to make sure features are available on mobile and tablet devices as much as they are on desktop computers, we also build the website in a way that is accessible for assistive technologies like screen readers.
We think that if we’ve taken the effort to design and build a feature for visual users, it should also exist for screen reader users. And so it follows that if the feature allows a user to perform an action, they should get feedback in a form that’s appropriate for whichever device they happen to be using.
So, when we realised that our “Like” functionality – which allows people to like comments within our course discussions – wasn’t working as well as it could for screen reader users, we decided to fix it. We’d already designed the comments in such a way that the “Like” count on a comment would be read out, but we didn’t give any feedback via the screen reader when the screen reader user themselves “Liked” a comment.
Researching screen readers
To start with, I spent some time reading accessibility blogs and websites (like The Accessibility Project and The Paciello Group), but I found it really hard to find any detailed literature on how other social networks manage to make their “Like” and “Favourite” buttons accessible. Reading all about how screen readers work is fine, but it was time to find out how a screen reader user really experiences the web.
I used a screen reader to look at all of the websites below. It turns out that, while most social networks allow users to add and remove favourites using the keyboard, not all of them give screen reader users any feedback. In some cases, this feedback is provided by a colour change or some other visual clue, which screen readers won’t notice. Even those sites that update the text on the page don’t all do it in a way a screen reader would understand.
At the time of writing this post, we captured the current accessibility of some popular websites’ “Like” buttons. All were tested using VoiceOver on OSX or iOS in Safari.
|Site||Read count?||Add?||Get feedback?|
|App.net||N/A (3)||Yes||No (6)|
1. It lists the names, but doesn’t label them as the people who “Liked”
2. It shows your own, but not the total number of shares
3. It doesn’t show you other people’s “Stars” in the timeline view
4. The total – eg “4567” – is there, but is broken up and read as “4 button 567”
5. The “Likes” and “Repins” are listed, but not differentiated
6. Not at the time of “Liking” – the text changes, but it’s not announced
7. Tested on iOS only.
Finding a bug (the technical bit)
After researching other websites’ solutions, we turned to our own codebase to try to fix it. Unfortunately we came across a different bug with a keyboard focus, which made it very hard to test the original issue – after “Liking” a comment, the keyboard focus was returning to the URL bar.
When I tested hitting “Like” multiple times, the keyboard focus would jump around the page. Trying to write code to fix this bug was very frustrating – probably as frustrating as it would be for someone who was actually trying to use the site.
As this was a small change that would improve things generally, we immediately tested it and pushed it out to the site, as per our approach of continuous deployment, before continuing to work on “Likes.”
Getting screen reader feedback on “Likes”
Once we’d got that bug out of the way, it was easier to see where we needed to make the change to make the screen reader provide feedback when a user “Liked” a comment.
One good feedback method is to add an `aria-live` region to a containing element, which will announce the changed content after it’s updated. I used the value “polite” – choosing between “off,” “polite” and “assertive” – because:
“Normally, only aria-live=”polite” is used. Any region which receives updates that are important for the user to receive, but not so rapid as to be annoying, should receive this attribute. The screen reader will speak changes whenever the user is idle.” – Aria-live documentation
We hit a snag when it turned out that we needed the screen reader to nicely pluralise the phrase “One like/two likes” when it’s spoken, but we only want the “Like” count to appear on screen, without extra text. Luckily Alice Bartlett’s work on making search accessible on GOV.UK explains a solution – to use CSS to hide screen reader-only content from visual users, and use the Aria state `aria-hidden` to hide the visual-only text from screen readers.
Like Alice, I’m always nervous of duplicating content in this way because it adds complexity, but I’m reassured to see that the Government Digital Service (GDS), with their focus on accessibility, have also used this technique.
The thing that I’m curious about is why sending feedback to screen readers is so rarely supported by the social networks we looked at. Maybe it’s because they did the user research and found that screen reader users don’t actually care about their “Likes” and “Favourites,” maybe they found that this amount of feedback didn’t scale with their already very busy websites. I’d be really interested to know.
Besides that, while we do guerilla testing with members of the public in the British Library, and have a regular, full-accessibility audit from a specialist organisation, I know we have screen reader users out there, and would love to know if the changes we’ve made to “Likes” work for you.
Do you use a screen reader to access FutureLearn? We’d love to hear from you! You can leave your feedback in the comments below or drop us a line at email@example.com.
Here are some other links that we found useful while thinking about this:
- Accessibility and how to get the most from your screenreader – GDS
- Things I learned by pretending to be blind for a week – Silktide
- Screen Reader User Survey #5 Results – WebAIM