[whatwg] [HTML5] Accessibility question
Nicholas C. Zakas
html at nczonline.net
Wed Mar 26 10:56:32 PDT 2008
I agree with the two use cases you've listed. The first use case is now handled in HTML 5 via @irrelevant. My point n bringing up accessibility is that if HTML is going to now specify when content should be hidden versus allowing CSS to do it, then we should open the conversation to other reasons for hiding content. We currently now use display: none or visibility: hidden to hide content that isn't necessary for users at that time, which is the same purpose as @irrelevant (from previous discussions).
I'm very familiar with defining separate CSS classes for moving content offscreen, and it seems like a big hack to me. It also seems that this is a common enough use case that it merits further investigation.
I'm open to the idea that this should be handled via CSS, but then @irrelevant sticks out as being out of place. Perhaps the greater question is whether or all showing/hiding of content is really a CSS issue or if there are some that use cases that do belong in HTML.
-Nicholas
----- Original Message ----
From: Benjamin Hawkes-Lewis <bhawkeslewis at googlemail.com>
To: Nicholas C. Zakas <html at nczonline.net>
Cc: whatwg List <whatwg at whatwg.org>; Ian Hickson <ian at hixie.ch>
Sent: Sunday, March 23, 2008 10:36:06 AM
Subject: Re: [whatwg] [HTML5] Accessibility question
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">
<h2>Bunnies</h2>
<img alt="A well-fed white bunny demolishes a carrot with relish."
src="bunny.jpg">
<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>
</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
http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/
Arguably, the best-of-breed technique is to hide additional content
off-screen using CSS:
http://www.w3.org/TR/WCAG20-CSS-TECHS/C7.html
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:
<a href="http://example.com/more-about-bunnies.html">Read
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
browsing linearly.
What do we think of this suggestion? What other solutions might there be?
* Solutions for use-case B: Separation of content from graphical
enhancements *
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:
http://www.w3.org/TR/REC-CSS2/generate.html#propdef-content
http://www.w3.org/TR/CSS21/generate.html#propdef-content
http://www.w3.org/TR/css3-content/#replacedContent
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?
--
Benjamin Hawkes-Lewis
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080326/50d1cba9/attachment-0001.htm>
More information about the whatwg
mailing list