During Knowbility’s Implementing Accessible Solutions: Screen Readers webinar, there were attendee questions we didn’t have time to answer. Our team of experts, including presenter Alicia Evans, answered these overflow questions and we’re sharing them with everyone!
Talkback Screen Reader
Question: We noticed that, at least with Talkback, it requires a lot of “swipe rights” to get out of a list box to get to the confirm button below it, as the options are also considered “controls”. Is there a way to alleviate this problem for Talkback users? (On desktop this is not an issue, because the options are not navigated by TAB but by arrow keys, so you can quickly skip to the confirm button with a single TAB)
Answers:
Eric Eggert: If it works in other assistive technologies, this could be an issue with Talkback itself. The best thing you can do is make sure you are on the latest version of Talkback, which was released in February 2021.
Emily Lewis: Beyond that, we don’t recommend modifying code or interactions to get a specific screen reader to behave a certain way. That could cause problems in other assistive technologies. You also can’t account for the wide range of preferences that screen reader users have for how they want to interact with their screen reader. It’s best to follow the core accessibility standards and leave software/hardware nuances as something for users and manufacturers to resolve.
Form Errors
Question: Do you have any recommended reading on accessible UX patterns error message handling on forms?
Answers:
Eric Eggert: The baseline information for errors is included in the WAI forms tutorial, but its focus is not on the user experience itself, more on the technical functionality of errors.
Alicia Evans: Don’t forget the AccessU pre-conference workshop on forms!
Emily Lewis: WebAIM has a good intro to accessible form validation and errors. I also like Nielsen Norman Group’s suggestions on form error design (contains one looping GIF), though these focus on usability, not accessibility.
Browser Inspector Tools
Question: What do you think of Firefox Accessibility tools vs Chrome?
Answers:
Alicia Evans: I've only briefly tried using Firefox's a11y tools. They looked fine. I only use Chrome because those are the dev tools I use most often.
Eric Eggert: They are both good. Firefox has a leg up with some functionality (I find the color contrast stuff better), but in general they show all the relevant information, especially with roles and such.
Alt Text
Question: Quick question on alt text for a photo of a person-we have an about us page with photos of all the executives with their name underneath - would you put “Portrait of this person” or just leave it empty because their name is right below it?
Answers:
Sharron Rush: There is no single right answer. I would probably handle it by using a heading "Photo Gallery of our executive Board" or something like that and then use empty alt text since the name will be onscreen.
Alicia Evans: I think this is an it depends kind of question. If the alt text is just going to be the person's name or "portrait of [person's name]" then no. Leave the alt attribute empty. If the person is juggling or doing something interesting, then include alternative text. And more and more people are actually describing people in their images, but that's relatively new.
Eric Eggert: They are redundant, so yes, empty alt is OK there. They could also have a long description that really describes the person on a profile page. If the photos are on profile pages, too, there might be a slight argument to make to have a best practice “Headshot of Firstname Lastname” as the alternative text to make it discoverable for blind or low vision people who need the headshot, for example for including it on a conference page.
Emily Lewis: Good alt text is science and art. It takes an understanding of the user, of the content and of the context. Our next webinar on accessible images will dive into all of those considerations.
Dialog Focus Management
Question: How do you move focus to the modal dialog/restrict focus to it? I apologize if that’s through JavaScript/HTML and not accessibility tactics. I’m not a developer.
Answers:
Attendee Joppe Kroon: That would indeed be through Javascript. Restricting the focus to the dialog is notoriously difficult.
Attendee Diana Nickels: The WAI-ARIA Authoring Practices website has great examples and code snippets
Eric Eggert: inert is the HTML attribute that is supposed to do that (in the future!), and there are polyfills available