WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Best practice for steering to screen reader-only stylesheets

for

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

From: Tech
Date: Thu, Jul 17 2008 4:30PM
Subject: Best practice for steering to screen reader-only stylesheets
No previous message | Next message →

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Folks,<br>
<br>
When I designed my <a
href="http://76.100.0.7:2801/src/z-webpersist/jescrollgrid/demo1min.html">fluid
grid with a fixed header and a scrolling body,</a> I assumed it would
be simple to hide the extra header meant only for sighted users, from
screen readers (and vice versa).&nbsp; But lacking any good auto-detection
for readers, this will require the user of a reader to request a
special style sheet.&nbsp; <br>
<br>
So I figure the only option is a link for "Goto Accessible version,"
which I've never done before.&nbsp; Are there best practices for this? Do I
put it right after the body tag, and hide, with display:none, which can
still seen by readers, or must it remain visible?&nbsp; Are there any
bulletproof ways of detecting a reader, that I've never heard of yet?<br>
<br>
Forgive my ignorance here. I am still pretty knew to doing this stuff
myself, and trying to stay accessible from the outset.<br>
<br>
<br>
</body>
</html>

From: Jared Smith
Date: Thu, Jul 17 2008 4:50PM
Subject: Re: Best practice for steering to screen reader-only stylesheets
← Previous message | Next message →

On Thu, Jul 17, 2008 at 4:28 PM, Tech < = EMAIL ADDRESS REMOVED = > wrote:

> When I designed my fluid grid with a fixed header and a scrolling body, I
> assumed it would be simple to hide the extra header meant only for sighted
> users, from screen readers (and vice versa).

There is not a way (that I'm aware) of to display content in the page,
but have it ignored by a screen reader. I also can't think of a reason
why you would ever want to do this. If it's important enough to show
to sighted users, why not allow screen reader users to read it.

> So I figure the only option is a link for "Goto Accessible version," which
> I've never done before.

It's probably not a good idea to create a separate version when the
main page can probably be made accessible. It's also a direct Section
508 violation (if you're concerned about such things). Please explain
what you're trying to accomplish.

> Do I put it
> right after the body tag, and hide, with display:none, which can still seen
> by readers, or must it remain visible?

Most screen readers will not read content styled with display:none or
visibility:hidden. The following article shows how to hide content
visually but allow it to be read by a screen reader -
http://webaim.org/techniques/css/invisiblecontent/ This should be used
VERY sparingly and only when purely visual information would be useful
to screen reader users. For example, on the WebAIM site we use it to
identify the beginning of advertisement. Visual users can visually
identify the advertisement blocks, but screen reader users may not
know they are ads until after they read them.

> Are there any bulletproof ways of detecting a reader, that I've never heard of yet?

No.

Jared Smith
WebAIM

From: Tech
Date: Thu, Jul 17 2008 6:50PM
Subject: Re: Best practice for steering to screen reader-only stylesheets
← Previous message | Next message →

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<big>Jared Smith wrote:<br>
&lt;&lt;Please explain what you're trying to accomplish.<br>
<br>
Jared, this is an issue I discussed earlier in the week, so I merely
posted my demo, and didn't re-explain it.&nbsp; Let me do so again here in
more detail.&nbsp; <br>
<br>
My question<a
href="http://76.100.0.7:2801/src/z-webpersist/jescrollgrid/demo1min.html.">
refers to this table with fixed-header solution, which I built. </a></big><br>
<br>
<big>The goal is to find a way to create, for sighted users, a fixed
and non-scrolling header above a data table that can have a variable
width, and not a more typical fixed-width grid style (which requires
horizontal scrollbars to see most of the columns out of view).<br>
<br>
Because the overflow property is not well supported on the TBody
element across browsers, there is no way anyone has come up with&nbsp; (that
I've found), which can make such a fixed header neatly align with the
columns below. The best efforts you can find anywhere use one of these
4 basic approaches: </big><br>
<ol>
<li>A pure CSS approach, that almost fails in one browser or another
with no fix possible<br>
<br>
</li>
<li>Some form of CSS/Javascript hack that comes close, but usually
fails in one browser or another.<br>
<br>
</li>
<li>A fixed-width grid, which, for reasons stated above,&nbsp; is just not
useful or desirable in many contexts (like mine), where the fluid style
is essential.<br>
<br>
</li>
<li>A dual table solution like mine, which uses javascript to keep
the upper header-table lined up with the lower body-table columns.&nbsp;<b>
Google docs,</b> and other heavy DHTML solutions have used this
approach, but theirs breaks in many browsers, or steps on the last
column's data with the scroll bar.</li>
</ol>
<b>My approach is #4, and can be seen at the link above.&nbsp; If you
examine the source, you can see the normal header, and the secondary
table acting as a header above it.&nbsp; In theory, the concept is to allow
screen readers to use the normal table header, which has no need to be
fixed, and allow sighted users to see the upper table--just a single
row of header elements--which can be fixed, allowing the data table to
scroll inside a div (with its overflow set to auto) below it.<br>
<br>
You can find literally thousands of posts on the web, of people trying
to achieve this fixed header concept on a fluid width table.&nbsp;
Christiane,in this group, posted many links to the better known of them
earlier this week.&nbsp; To my knowledge, mine is the only solution that
works in most&nbsp; browsers with no serious issues.<br>
<br>
</b><b>The only issue is, how to handle the accessibility aspects. Both
the original header row, and the clone of it--the fixed Header--must
exist in the same source.&nbsp; I need to explore ways to handle such a
situation.&nbsp;&nbsp; &nbsp; I am&nbsp; too new to the accessibility area to know what
options I might have.&nbsp; All I know is that just as Google docs used this
solution, I must use it too.&nbsp; I just want to do the best I can to make
it adequately accessible.&nbsp; If there are other solutions, I haven't
found them.&nbsp; Not having the fixed header feature is just not an option
I want to live with.&nbsp; It works too well, and is far too convenient for
sighted users who get very frustrated when they cannot tell what a
column contains after normal headers scroll from view.</b><br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Jared Smith wrote:
<blockquote
cite="mid: = EMAIL ADDRESS REMOVED = "
type="cite">
<pre wrap="">On Thu, Jul 17, 2008 at 4:28 PM, Tech <a class="moz-txt-link-rfc2396E" href="mailto: = EMAIL ADDRESS REMOVED = ">&lt; = EMAIL ADDRESS REMOVED = &gt;</a> wrote:

</pre>
<blockquote type="cite">
<pre wrap="">When I designed my fluid grid with a fixed header and a scrolling body, I
assumed it would be simple to hide the extra header meant only for sighted
users, from screen readers (and vice versa).
</pre>
</blockquote>
<pre wrap=""><!---->
There is not a way (that I'm aware) of to display content in the page,
but have it ignored by a screen reader. I also can't think of a reason
why you would ever want to do this. If it's important enough to show
to sighted users, why not allow screen reader users to read it.

</pre>
<blockquote type="cite">
<pre wrap="">So I figure the only option is a link for "Goto Accessible version," which
I've never done before.
</pre>
</blockquote>
<pre wrap=""><!---->
It's probably not a good idea to create a separate version when the
main page can probably be made accessible. It's also a direct Section
508 violation (if you're concerned about such things). Please explain
what you're trying to accomplish.

</pre>
<blockquote type="cite">
<pre wrap="">Do I put it
right after the body tag, and hide, with display:none, which can still seen
by readers, or must it remain visible?
</pre>
</blockquote>
<pre wrap=""><!---->
Most screen readers will not read content styled with display:none or
visibility:hidden. The following article shows how to hide content
visually but allow it to be read by a screen reader -
<a class="moz-txt-link-freetext" href="http://webaim.org/techniques/css/invisiblecontent/">http://webaim.org/techniques/css/invisiblecontent/<;/a> This should be used
VERY sparingly and only when purely visual information would be useful
to screen reader users. For example, on the WebAIM site we use it to
identify the beginning of advertisement. Visual users can visually
identify the advertisement blocks, but screen reader users may not
know they are ads until after they read them.

</pre>
<blockquote type="cite">
<pre wrap="">Are there any bulletproof ways of detecting a reader, that I've never heard of yet?
</pre>
</blockquote>
<pre wrap=""><!---->
No.

Jared Smith
WebAIM
</pre>
</blockquote>
<br>
</body>
</html>

From: Benjamin Hawkes-Lewis
Date: Sat, Jul 19 2008 2:20AM
Subject: Re: Best practice for steering to screen reader-only stylesheets
← Previous message | Next message →

Tech wrote:
> 2. Some form of CSS/Javascript hack that comes close, but usually
> fails in one browser or another.

Hmm. Do you have examples of where this fails?

I'd be wary, very wary, of assuming the big DHTML frameworks have
exhausted all the options.

--
Benjamin Hawkes-Lewis

From: Becky Reed
Date: Fri, Sep 05 2008 11:50AM
Subject: Best Practice for interaction between Closed Captioning and Audio
← Previous message | Next message →

I am working on adding closed captioning to a web application that uses audio extensively (explains critical educational concepts using audio over video). I am looking for what the best practice is around closed captioning as I have noted varied implementation of this feature and really want to get to the right thing...

I have two issues I'm working through:

(1) When supplying a closed captioning button on the interface:

1. Mute all audio when I bring up CC
2. Leave audio rolling in addition to the CC

(2) Also, a "sound off" (mute) button has been discussed. Behavior would be to turn on CC when the "mute" button is selected. While I think CC on for a mute/sound off is fine, I'm hesitant to accept a mute button as a sufficient visual cue to indicate CC is available. I have seen instances of this, but it doesn't quite feel right. Thoughts on this?

Any feedback is appreciated. Experience/testing around either of these issues?

Thanks very much,

Becky Reed
IxD, Healthwise

From: Benjamin Hawkes-Lewis
Date: Fri, Sep 05 2008 12:50PM
Subject: Re: Best Practice for interaction between Closed Captioning and Audio
← Previous message | Next message →

Becky Reed wrote:
> (1) When supplying a closed captioning button on the interface:
>
> 1. Mute all audio when I bring up CC
> 2. Leave audio rolling in addition to the CC

I don't understand why you'd want to do (1). I often have closed
captions and audio on, personally.

> (2) Also, a "sound off" (mute) button has been discussed. Behavior would be to turn on CC when the "mute" button is selected. While I think CC on for a mute/sound off is fine, I'm hesitant to accept a mute button as a sufficient visual cue to indicate CC is available. I have seen instances of this, but it doesn't quite feel right. Thoughts on this?

However, I don't think a "mute" button is a sufficient cue to the
availability of closed captions. It's important for users to be able to
show captions and for them to be able to mute audio, but these should be
separate controls in my view.

Turning on captions when the "mute" button is selected sounds like a
cute idea, however. When Mute is pressed, show closed captions even if
CC is not depressed. When sound is restored, turn of the closed captions
if CC is not depressed. If CC is depressed, keep closed captions on
regardless of Mute status.

> Experience/testing around either of these issues?

I wish. :)

--
Benjamin Hawkes-Lewis

From: Zdenek, Sean
Date: Fri, Sep 05 2008 1:00PM
Subject: Re: Best Practice for interaction between Closed Captioning and Audio
← Previous message | Next message →

Becky,

Re: #1. I'd go with the standard practice of leaving the audio rolling even when captions are activated. Hearing/Deaf is not a binary opposition in which people who are hearing can't benefit from captions and people who are d/Deaf can't benefit from audio. Instead, there are a range of subject positions with varying preferences and needs: hearing, audiologically deaf (with varying degrees from profound to severe hearing loss), hard-of-hearing (with varying degrees from mild to moderate hearing loss), Culturally Deaf (i.e. but also able to pass for hearing).

Just as we double up when color is involved (Ensure that all information conveyed with color is also available without color -- WCAG 1.0, Guideline 2.1 & Section 508, section 1194.22c), we should do the same for captions (i.e. captions are available together with audio, rather than each on its own).

Re: #2. Whatever you do, it should not be a surprise to the user (like a pop-up window that a screen reader user doesn't know about).

Sean
---------------------------
Sean Zdenek, PhD
Assistant Professor
Technical Communication & Rhetoric
Department of English
Texas Tech University
806.742.2500 x284
Office: 472 English Building
= EMAIL ADDRESS REMOVED =

http://cms.english.ttu.edu/zdenek
http://seanzdenek.com

From: Cliff Tyllick
Date: Fri, Sep 05 2008 1:10PM
Subject: Re: Best Practice for interaction between Closed Captioning and Audio
← Previous message | No next message

To extend what Sean said, I would think that having to press "Mute" to activate CC would qualify as "a surprise to the user." At least I would think most users would not expect "Mute" to mean "Turn on CC."

Cliff Tyllick
Web development coordinator
Agency Communications Division
Texas Commission on Environmental Quality
512-239-4516
= EMAIL ADDRESS REMOVED =

>>> "Zdenek, Sean" < = EMAIL ADDRESS REMOVED = > 9/5/2008 1:53 PM >>>
Becky,

Re: #1. I'd go with the standard practice of leaving the audio rolling even when captions are activated. Hearing/Deaf is not a binary opposition in which people who are hearing can't benefit from captions and people who are d/Deaf can't benefit from audio. Instead, there are a range of subject positions with varying preferences and needs: hearing, audiologically deaf (with varying degrees from profound to severe hearing loss), hard-of-hearing (with varying degrees from mild to moderate hearing loss), Culturally Deaf (i.e. but also able to pass for hearing).

Just as we double up when color is involved (Ensure that all information conveyed with color is also available without color -- WCAG 1.0, Guideline 2.1 & Section 508, section 1194.22c), we should do the same for captions (i.e. captions are available together with audio, rather than each on its own).

Re: #2. Whatever you do, it should not be a surprise to the user (like a pop-up window that a screen reader user doesn't know about).

Sean
---------------------------
Sean Zdenek, PhD
Assistant Professor
Technical Communication & Rhetoric
Department of English
Texas Tech University
806.742.2500 x284
Office: 472 English Building
= EMAIL ADDRESS REMOVED =

http://cms.english.ttu.edu/zdenek
http://seanzdenek.com