[whatwg] [HTML5] Accessibility question
bhawkeslewis at googlemail.com
Sun Mar 23 10:36:06 PDT 2008
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
Hmm. I think we need to take a step back and define this problem more
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
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
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">
<img alt="A well-fed white bunny demolishes a carrot with relish."
<p>Bunnies 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>
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:
Arguably, the best-of-breed technique is to hide additional content
off-screen using CSS:
Nicholas is worried that this hiding isn't signified by the markup. But
all developers need to do is add a class to their markup:
<a href="http://example.com/more-about-bunnies.html">Read more<span
class="extra-context"> about bunnies</span>
This solution is hacky but works for decontextualized navigation and
nonsequential browsing. The problem is it obfuscates the linear
consumption of the page with extra verbosity.
Perhaps an extra element (or perhaps attribute) designed for this
purpose would improve the linear experience and would be backwards
compatible with the off-screen technique? For lack of a better name,
let's call it <extracontext/> for the sake of argument:
more<extracontext> about bunnies</extracontext></a>
By positioning <extracontext/> off-screen with CSS, this element would
work as well as the current best practice technique in current agents.
But future agents could simply ignore <extracontext/> when the user is
What do we think of this suggestion? What other solutions might there be?
* Solutions for use-case B: Separation of content from graphical
There are lots of current techniques including:
1. HTML images (IMG/INPUT/OBJECT plus text equivalents). While they do
allow the extraction of text equivalents, they closely couple markup
with a particular CSS skin.
2. Scalable Flash replacement. Cons include dependence on a proprietory
technology; degrading performance; and a focus in current
implementations (i.e. sIFR) on font styling rather than graphical
mastheads and icons.
3. CSS background-image replacement with text positioned off-screen.
This technique should simply be avoided, as it has major accessibility
and interoperability problems. Specifically, if the user has images
disabled or his own colors and backgrounds enforced, then the
background-image won't be applied but the text will still be positioned
out of sight.
4. Other CSS background-image replacement techniques. While I'm willing
to allow some might work as robustly as HTML images in particular
situations, I haven't seen one that will work everywhere.
I suspect HTML5 doesn't need to provide a solution for this use-case
however. It's a matter of presentation and CSS is already beginning to
cover it with @font-face and the "content" property, which can be used
for content replacement:
It's not entirely clear to me whether CSS yet specifies how to resize
boxes to fit generated content or text fallbacks as necessary, but if
this is indeed missing doesn't it need fixing in CSS not HTML5?
More information about the whatwg