WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXTERNAL] When Should You Show Web Content Only To Screen Readers

for

From: Mark Magennis
Date: Oct 3, 2019 8:53AM

I would say that adding hidden headings can often be useful. Also adding region names which are not displayed visually, or even adding hidden links. All this is valid and can be used to craft a much better user experience.

We have a design something like what you describe Abby and it has brought up some interesting requirements for screen reader users.

Our Search Results page has a bunch of filters. Visually, they are in a panel to the left of the search results list. In the code order, they come before the search results. This sounds bad but when the page loads, focus is placed on the overall results statement, e.g. "7,585 results for management" which is the main page heading and is after the filter panel. This is one of the rare situations where it is sensible to move focus to a point on the page when it loads. Because you can guarantee with 100% certainty that when a search results page loads, the user will want to read the results and not use the top navigation bar. So we move focus past it. But we also skip over the filters because we think the most common use case is to start reading the results and not use the filters. But we need to make the filters easily findable. So after the main page heading we have a 'Jump to search filters' link which is normally not visible but appears on keyboard focus, like the 'Jump to main cont
ent' link at the top of the page. The 'Jump to search filters' link moves focus to the search panel which has the name "Search filters".

The filters are separated into four sets - Type (containing course, book, video, etc. as this is a search for training content), Training Credits, Expertise, Duration. Each has a number of filter options under those headings. These sets are presented as show/hide panels where activating the heading opens the panel with that set of filters. In most cases, users will want to use only the 'Type' filters so after the 'Type' set we have a 'Jump to Search Results' link so they don't have to go through the remaining filter options to get back to the newly filtered results. We have the same link after each set and it is again hidden but appears on keyboard focus.

This works well except we feel that screen reader users may get to the first 'Jump to Search Results' link and think they have come to the end of the filtering panel, not realising there are more filtering options below. So we are considering adding a description to the panel "Available search filters: Type, Expertise, Training Credits, Duration". This would be only for screen reader users and would tell them in advance what was below. This is just one idea we are working through at the moment because there are issues with how exactly to add the description (just using aria-describedby is not that straightforward or robust). We may look at using a list to give the information ("List of 4 items" may indicate there are four filter groups). Or other ideas.

There's a lot to this - how to make it efficient, how to cater for the most common use case, how to also allow for other use cases, what extra information to provide that isn't obvious to screen reader users, and how to code the whole thing so it works across the full range of browser/AT combinations we need to support. It's a case of crafting a solution and then seeing whether it flies in practice.

But generally I think visually hidden names, descriptions, links, etc. can be very effective in doing this, as long as it doesn't all become too complex.

Mark

Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist