E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Jim Homme
Date: Thu, Oct 03 2019 6:17AM
Subject: When Should You Show Web Content Only To Screen Readers
No previous message | Next message →

Hi,
I feel like this should almost never happen. What do you think? When do you think it is OK to show web content only to screen readers?

Thanks.

Jim



==========
Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions

From: Mark Magennis
Date: Thu, Oct 03 2019 7:56AM
Subject: Re: [EXTERNAL] When Should You Show Web Content Only To Screen Readers
← Previous message | Next message →

Depends what you call content Jim. But I think there are often good reasons for screen reader users to be given different names, extra descriptions, and specific feedback messages. If that's what you meant I could give some examples.

Mark

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


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jim Homme
Sent: 03 October 2019 13:17
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] [WebAIM] When Should You Show Web Content Only To Screen Readers

Hi,
I feel like this should almost never happen. What do you think? When do you think it is OK to show web content only to screen readers?

Thanks.

Jim



==========
Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions

From: Abby Kingman
Date: Thu, Oct 03 2019 8:24AM
Subject: Re: When Should You Show Web Content Only To Screen Readers
← Previous message | Next message →

I am interested in this as well. Some designers like to have a very sparse
page layout, where essentially the structure of the page is implied
visually. A sighted user will know they are scanning from one section to
another on the page because the nature of the content changes. But I have
concerns about whether this is difficult for non-sighted users.

For example, how do AT users know that they are moving to a section of the
page that contains a group of filters that can be used to restrict the
information in the content listing below? After the h1 there is a label for
a dropdown list, then another and another - but why? have considered
adding hidden headers for the filter area and listing area, but I don't
know for sure that it is helpful. Maybe wrapping those areas with tags and
creating a landmark would be cleaner, but I think many users don't rely
heavily on landmarks. And maybe it is all more obvious than I think, so
neither of those are needed.

I am looking forward to having some AT user testing done on these pages
soon. Of course that will give me information on what that individual user
prefers, but it's better than no insight at all.

Abby

--
Abby Kingman, CPACC

Last Call Media

From: Jonathan Avila
Date: Thu, Oct 03 2019 8:30AM
Subject: Re: When Should You Show Web Content Only To Screen Readers
← Previous message | Next message →

If headings are needed for screen reader users I'd argue that they are likely needed for users with cognitive and learning disabilities as well. If you find something useful to a user who is blind because something is implied in the visual page then the same implied information is likely to be missed by other users including people who are low vision or that have other print disabilities.

Jonathan

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Abby Kingman
Sent: Thursday, October 3, 2019 10:25 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] When Should You Show Web Content Only To Screen Readers

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


I am interested in this as well. Some designers like to have a very sparse page layout, where essentially the structure of the page is implied visually. A sighted user will know they are scanning from one section to another on the page because the nature of the content changes. But I have concerns about whether this is difficult for non-sighted users.

For example, how do AT users know that they are moving to a section of the page that contains a group of filters that can be used to restrict the information in the content listing below? After the h1 there is a label for a dropdown list, then another and another - but why? have considered adding hidden headers for the filter area and listing area, but I don't know for sure that it is helpful. Maybe wrapping those areas with tags and creating a landmark would be cleaner, but I think many users don't rely heavily on landmarks. And maybe it is all more obvious than I think, so neither of those are needed.

I am looking forward to having some AT user testing done on these pages soon. Of course that will give me information on what that individual user prefers, but it's better than no insight at all.

Abby

--
Abby Kingman, CPACC

Last Call Media

From: Jeremy Echols
Date: Thu, Oct 03 2019 8:49AM
Subject: Re: When Should You Show Web Content Only To Screen Readers
← Previous message | Next message →

I feel like there are cases where I use screen-reader-only content because it's the lesser of two evils, such as when we have a text field that can't easily be labeled due to branding concerns (a sitewide search box comes to mind, though at least that's in a relevant "search" region), but I generally feel the same as Jonathan.

I don't think WCAG has this covered well, because as I understand it hidden headers and hidden field labels are indeed valid techniques, but I try to do these things very sparingly.

One risk is that some users won't "get" what your visual style is trying to imply - this could be cultural differences, cognitive issues, or simply your designers' biases at play ("it makes sense to *me*").

Another risk is that your screen-reader-only content gets out of sync from the page since devs are often rushing to fix things and not testing that the accessible page makes sense.

Then there's the risk that a sighted screen-reader user gets confused because what's read isn't the same as what's visible.

And of course there's always the risk that you're too "helpful", wasting a blind user's time with extremely verbose instructions (if those instructions are necessary for a blind person, why aren't they necessary for all users?).

Style and branding concerns sometimes trump everything, but there are legitimate issues you should carefully consider before using hidden text.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: Thursday, October 03, 2019 7:30 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] When Should You Show Web Content Only To Screen Readers

If headings are needed for screen reader users I'd argue that they are likely needed for users with cognitive and learning disabilities as well. If you find something useful to a user who is blind because something is implied in the visual page then the same implied information is likely to be missed by other users including people who are low vision or that have other print disabilities.

Jonathan

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Abby Kingman
Sent: Thursday, October 3, 2019 10:25 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] When Should You Show Web Content Only To Screen Readers

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


I am interested in this as well. Some designers like to have a very sparse page layout, where essentially the structure of the page is implied visually. A sighted user will know they are scanning from one section to another on the page because the nature of the content changes. But I have concerns about whether this is difficult for non-sighted users.

For example, how do AT users know that they are moving to a section of the page that contains a group of filters that can be used to restrict the information in the content listing below? After the h1 there is a label for a dropdown list, then another and another - but why? have considered adding hidden headers for the filter area and listing area, but I don't know for sure that it is helpful. Maybe wrapping those areas with tags and creating a landmark would be cleaner, but I think many users don't rely heavily on landmarks. And maybe it is all more obvious than I think, so neither of those are needed.

I am looking forward to having some AT user testing done on these pages soon. Of course that will give me information on what that individual user prefers, but it's better than no insight at all.

Abby

--
Abby Kingman, CPACC

Last Call Media

From: Mark Magennis
Date: Thu, Oct 03 2019 8:53AM
Subject: Re: [EXTERNAL] When Should You Show Web Content Only To Screen Readers
← Previous message | Next message →

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


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Abby Kingman
Sent: 03 October 2019 15:25
To: = EMAIL ADDRESS REMOVED =
Subject: [EXTERNAL] [WebAIM] When Should You Show Web Content Only To Screen Readers

I am interested in this as well. Some designers like to have a very sparse
page layout, where essentially the structure of the page is implied
visually. A sighted user will know they are scanning from one section to
another on the page because the nature of the content changes. But I have
concerns about whether this is difficult for non-sighted users.

For example, how do AT users know that they are moving to a section of the
page that contains a group of filters that can be used to restrict the
information in the content listing below? After the h1 there is a label for
a dropdown list, then another and another - but why? have considered
adding hidden headers for the filter area and listing area, but I don't
know for sure that it is helpful. Maybe wrapping those areas with tags and
creating a landmark would be cleaner, but I think many users don't rely
heavily on landmarks. And maybe it is all more obvious than I think, so
neither of those are needed.

I am looking forward to having some AT user testing done on these pages
soon. Of course that will give me information on what that individual user
prefers, but it's better than no insight at all.

Abby

--
Abby Kingman, CPACC

Last Call Media

From: Jim Homme
Date: Fri, Oct 11 2019 1:58PM
Subject: Re: When Should You Show Web Content Only To Screen Readers
← Previous message | Next message →

Hi,
I think that you should assume that you are going to show content to only screen readers as a last resort. Mostly someone with another disability will benefit from seeing the same content. I might even go so far as to say that even something like a chart would work better in tabular form for everyone, people without disabilities included, especially when you start thinking of wider uses for your content, such as SEO. As for your concern about how people who are blind or who have low vision seeing certain content is concerned, that would be the time to reach out before you design the content and talk to someone with blindness or low vision about the design before you do the page, so that you can avoid making the mistake of assuming that they cannot access something, and possibly saving yourself a lot of unneeded effort.

Thanks.

Jim




==========
Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Abby Kingman
Sent: Thursday, October 3, 2019 10:25 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] When Should You Show Web Content Only To Screen Readers

I am interested in this as well. Some designers like to have a very sparse page layout, where essentially the structure of the page is implied visually. A sighted user will know they are scanning from one section to another on the page because the nature of the content changes. But I have concerns about whether this is difficult for non-sighted users.

For example, how do AT users know that they are moving to a section of the page that contains a group of filters that can be used to restrict the information in the content listing below? After the h1 there is a label for a dropdown list, then another and another - but why? have considered adding hidden headers for the filter area and listing area, but I don't know for sure that it is helpful. Maybe wrapping those areas with tags and creating a landmark would be cleaner, but I think many users don't rely heavily on landmarks. And maybe it is all more obvious than I think, so neither of those are needed.

I am looking forward to having some AT user testing done on these pages soon. Of course that will give me information on what that individual user prefers, but it's better than no insight at all.

Abby

--
Abby Kingman, CPACC

Last Call Media

From: Peter Shikli
Date: Sat, Oct 12 2019 12:38PM
Subject: Re: When Should You Show Web Content Only To Screen, Readers
← Previous message | Next message →

Jim,

We encounter this often in our growing business of making maps
accessible.  Lots more to say about that than will fit here, but suffice
it to say that we find ourselves using the longdesc tag to explain map
content to the disabled, explanations available to sighted users only
through the longdesc they are unlikely to use, but explanations they are
unlikely to need.

We have encountered situations where the longdesc includes tabular
versions of map content the blind find so useful that our clients have
moved that from the longdesc to the main content for everyone to use. 
Intermediate solutions include adding a "map narrative" or a "map data
tables" link for all to follow.

From a compliance standpoint, we see this as no more reverse
discrimination against sighted users than an ALT attribute, which screen
readers use without browsers displaying it to sighted users, though they
can easily take the trouble to see it, as they can a longdesc.

Cheers,
Peter Shikli
Access2online

From: Guy Hickling
Date: Tue, Oct 15 2019 1:29PM
Subject: Re: When Should You Show Web Content Only To Screen, Readers
← Previous message | No next message

Peter, you said:

> We have encountered situations where the longdesc includes tabular
versions of map content the blind find so useful that our clients have
moved that from the longdesc to the main content for everyone to use.

That demonstrates that descriptions for complex graphs and images shouldn't
be done with longdesc, they should be made available as a normal link for
everyone beside the image right from the start.

And as others have already said in this thread, it is rarely right that
special information should be given only to blind people.

Regards,
Guy Hickling