Nicholas C. Zakas wrote:
The problem I'm trying to solve is the case where you need descriptive
text for screen readers but that text is not necessary for sighted
users.
Hmm. I think we need to take a step back and define this problem more
carefully.
Arguably, screenreader users are sometimes hindered by descriptive text
as much as helped. Moreover, they are by no means the only group who
benefit from text descriptions and equivalents. Other users who might
benefit include:
1. Users of non-screen media types (e.g. printing pages or using voice
browsers or console browsers).
2. Users of graphical browsers who disable images, either for
accessibility reasons or because of low bandwidth.
3. Users of graphical browsers who enforce their own colors and
backgrounds (a common option).
4. Users of graphical browsers who turn off author stylesheets or apply
user stylesheets.
5. Users of graphical browsers using more-or-less atypical navigation
strategies (e.g. links lists, document maps, typeahead find, reading
snippets in a search engine).
I suspect there are actually at least two different use-cases here:
Use-case A: Decontextualized navigation (where parts of the page are
shown for navigational purposes (e.g. lists of elements by type,
potentially reordered, or snippets in a search result) and nonsequential
browsing (e.g. jumping to the next link or list element). Ideally, tools
should be able to infer relationships between different bits of
presented content, and use this to provide essential context. Examples
include headers for data cells; long descriptions for images; headings
for sections; definitions for terms; labels for buttons. But where
relationships either cannot be programatically inferred or are hard to
express in a user interface, publishers want to support decontextualized
navigation and nonsequential browsing with targeted, additional content
that provides the minimum requisite context for users to understand
where they're going and where they've arrived.
Use-case B: Separation of content from graphical enhancements. Examples
include graphical mastheads, icons, and buttons that vary between themes
(i.e. alternate stylesheets).
Can anyone think of any others?
I would argue the ideal behavior of a screenreader is not the same in
these different use-cases. With use-case A, you only need the additional
content rendered when using decontextualized navigation or engaged in
non-sequential browsing. For example, let's say you have five promotion
modules each with markup along the lines of:
div class=module promotion
h2Bunnies/h2
img alt=A well-fed white bunny demolishes a carrot with relish.
src=bunny.jpg
pBunnies are full of intrinsic win, being as they are floppy-eared,
fluffy, and cute…/p
a href=http://example.com/more-about-bunnies.html;Read more/a
/div
If a consuming agent abstracts the links out into a list of all links in
the document, then users have no way of knowing what the five Read
more links refer to. It would help if some extra context was provided,
for example: Read more about bunnies. However, if you're reading
linearly through content and have just read Bunnies are full of win,
being as they are floppy-eared, fluffy, and cute…, then the addition of
about bunnies would be superfluous verbiage reducing accessibility by
slowing you down.
However, with use-case B, you would always want to hear or braille the
text rendering of the content, whether browsing in or out of context.
* Solutions for use-case A: decontextualized navigation and
nonsequential browsing *
CSS display: none; is still often used to hide context-providing
content, but it doesn't work in practice because:
1. Publishers often apply display: none; to all media types explicitly
under the illusion that display refers only to visual rendering.
2. Popular browsers default to applying styles to all media types not
screen, but publishers don't realize that (the HTML 4.01 specification
says the default type is screen).
3. display: none; is often used to hide content that is unhidden
through scripted behavior, without any thought about what happens in
other media types. Rendering content with display: none; could easily
hinder accessibility in such cases.
4. Popular screenreaders work from the screen media type and generally
don't read content hidden with display: none;.
5. The problem we're trying to solve does not arise from different
visibility being appropriate to different media types, but from
different visibility being appropriate to different browsing strategies.
Another common technique is to annotate content (e.g. lists and links)
with context using with the TITLE attribute. But TITLE is overloaded
with uses (abbreviation expansions, tooltip help, keyword spamming) and
has its own accessibility problems:
http://www.w3.org/TR/WCAG20-CSS-TECHS/H33.html
