[whatwg] [HTML5] Accessibility question

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@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.htm>

Received on Wednesday, 26 March 2008 10:56:32 UTC