<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">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). </DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">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.</DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">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.<BR></DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">-Nicholas</DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR> </DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com><BR>To: Nicholas C. Zakas <html@nczonline.net><BR>Cc: whatwg List <whatwg@whatwg.org>; Ian Hickson <ian@hixie.ch><BR>Sent: Sunday, March 23, 2008 10:36:06 AM<BR>Subject: Re: [whatwg] [HTML5] Accessibility question<BR><BR>Nicholas C. Zakas wrote:<BR>> The problem I'm trying to solve is the case where you need descriptive<BR>> text for screen readers but that text is not necessary for sighted<BR>> users.<BR><BR>Hmm. I think we need to take a step back and define this problem more <BR>carefully.<BR><BR>Arguably, screenreader users are sometimes hindered by descriptive text <BR>as much as helped. Moreover, they are by no means the only group who <BR>benefit from text descriptions and equivalents. Other users who might <BR>benefit include:<BR><BR>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 <BR>should be able to infer relationships between different bits of <BR>presented content, and use this to provide essential context. Examples <BR>include headers for data cells; long descriptions for images; headings <BR>for sections; definitions for terms; labels for buttons. But where <BR>relationships either cannot be programatically inferred or are hard to <BR>express in a user interface, publishers want to support decontextualized <BR>navigation and nonsequential browsing with targeted, additional content <BR>that provides the minimum requisite context for users to understand <BR>where they're going and where they've arrived.<BR><BR>Use-case B: Separation of content from graphical enhancements. Examples <BR>include graphical mastheads, icons, and buttons that vary between themes <BR>(i.e. alternate stylesheets).<BR><BR>Can anyone think of any others?<BR><BR>I would argue the ideal behavior of a screenreader is not the same in

 <BR>these different use-cases. With use-case A, you only need the additional <BR>content rendered when using decontextualized navigation or engaged in <BR>non-sequential browsing. For example, let's say you have five promotion <BR>modules each with markup along the lines of:<BR><BR><div class="module promotion"><BR><h2>Bunnies</h2><BR><img alt="A well-fed white bunny demolishes a carrot with relish." <BR>src="bunny.jpg"><BR><p>Bunnies are full of intrinsic win, being as they are floppy-eared, <BR>fluffy, and cute…</p><BR><a href="<A href="http://example.com/more-about-bunnies.html" target=_blank>http://example.com/more-about-bunnies.html</A>">Read more</a><BR></div><BR><BR>If a consuming agent abstracts the links out into a list of all links in <BR>the document, then users have no way of knowing what the five "Read <BR>more" links refer to. It would help if some extra context was provided, <BR>for

 example: "Read more about bunnies". However, if you're reading <BR>linearly through content and have just read "Bunnies are full of win, <BR>being as they are floppy-eared, fluffy, and cute…", then the addition of <BR>" about bunnies" would be superfluous verbiage reducing accessibility by <BR>slowing you down.<BR><BR>However, with use-case B, you would always want to hear or braille the <BR>text rendering of the content, whether browsing in or out of context.<BR><BR>* Solutions for use-case A: decontextualized navigation and <BR>nonsequential browsing *<BR><BR>CSS "display: none;" is still often used to hide context-providing <BR>content, but it doesn't work in practice because:<BR><BR>1. Publishers often apply "display: none;" to all media types explicitly <BR>under the illusion that display refers only to visual rendering.<BR>2. Popular browsers default to applying styles to all media types not <BR>screen, but publishers don't realize that (the

 HTML 4.01 specification <BR>says the default type is screen).<BR>3. "display: none;" is often used to hide content that is unhidden <BR>through scripted behavior, without any thought about what happens in <BR>other media types. Rendering content with "display: none;" could easily <BR>hinder accessibility in such cases.<BR>4. Popular screenreaders work from the screen media type and generally <BR>don't read content hidden with "display: none;".<BR>5. The problem we're trying to solve does not arise from different <BR>visibility being appropriate to different media types, but from <BR>different visibility being appropriate to different browsing strategies.<BR><BR>Another common technique is to annotate content (e.g. lists and links) <BR>with context using with the TITLE attribute. But TITLE is overloaded <BR>with uses (abbreviation expansions, tooltip help, keyword spamming) and <BR>has its own accessibility problems:<BR><BR><A

 href="http://www.w3.org/TR/WCAG20-CSS-TECHS/H33.html" target=_blank>http://www.w3.org/TR/WCAG20-CSS-TECHS/H33.html</A><BR><BR><A href="http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/" target=_blank>http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/</A><BR><BR>Arguably, the best-of-breed technique is to hide additional content <BR>off-screen using CSS:<BR><BR><A href="http://www.w3.org/TR/WCAG20-CSS-TECHS/C7.html" target=_blank>http://www.w3.org/TR/WCAG20-CSS-TECHS/C7.html</A><BR><BR>Nicholas is worried that this hiding isn't signified by the markup. But <BR>all developers need to do is add a class to their markup:<BR><BR><a href="<A href="http://example.com/more-about-bunnies.html" target=_blank>http://example.com/more-about-bunnies.html</A>">Read more<span <BR>class="extra-context"> about bunnies</span><BR><BR>This solution is

 hacky but works for decontextualized navigation and <BR>nonsequential browsing. The problem is it obfuscates the linear <BR>consumption of the page with extra verbosity.<BR><BR>Perhaps an extra element (or perhaps attribute) designed for this <BR>purpose would improve the linear experience and would be backwards <BR>compatible with the off-screen technique? For lack of a better name, <BR>let's call it <extracontext/> for the sake of argument:<BR><BR><a href="<A href="http://example.com/more-about-bunnies.html" target=_blank>http://example.com/more-about-bunnies.html</A>">Read <BR>more<extracontext> about bunnies</extracontext></a><BR><BR>By positioning <extracontext/> off-screen with CSS, this element would <BR>work as well as the current best practice technique in current agents. <BR>But future agents could simply ignore <extracontext/> when the user is <BR>browsing linearly.<BR><BR>What do we think of this

 suggestion? What other solutions might there be?<BR><BR>* Solutions for use-case B: Separation of content from graphical <BR>enhancements *<BR><BR>There are lots of current techniques including:<BR><BR>1. HTML images (IMG/INPUT/OBJECT plus text equivalents). While they do <BR>allow the extraction of text equivalents, they closely couple markup <BR>with a particular CSS skin.<BR><BR>2. Scalable Flash replacement. Cons include dependence on a proprietory <BR>technology; degrading performance; and a focus in current <BR>implementations (i.e. sIFR) on font styling rather than graphical <BR>mastheads and icons.<BR><BR>3. CSS background-image replacement with text positioned off-screen. <BR>This technique should simply be avoided, as it has major accessibility <BR>and interoperability problems. Specifically, if the user has images <BR>disabled or his own colors and backgrounds enforced, then the <BR>background-image won't be applied but the text will still be

 positioned <BR>out of sight.<BR><BR>4. Other CSS background-image replacement techniques. While I'm willing <BR>to allow some might work as robustly as HTML images in particular <BR>situations, I haven't seen one that will work everywhere.<BR><BR>I suspect HTML5 doesn't need to provide a solution for this use-case <BR>however. It's a matter of presentation and CSS is already beginning to <BR>cover it with @font-face and  the "content" property, which can be used <BR>for content replacement:<BR><BR><A href="http://www.w3.org/TR/REC-CSS2/generate.html#propdef-content" target=_blank>http://www.w3.org/TR/REC-CSS2/generate.html#propdef-content</A><BR><BR><A href="http://www.w3.org/TR/CSS21/generate.html#propdef-content" target=_blank>http://www.w3.org/TR/CSS21/generate.html#propdef-content</A><BR><BR><A href="http://www.w3.org/TR/css3-content/#replacedContent" target=_blank>http://www.w3.org/TR/css3-content/#replacedContent</A><BR><BR>It's not entirely

 clear to me whether CSS yet specifies how to resize <BR>boxes to fit generated content or text fallbacks as necessary, but if <BR>this is indeed missing doesn't it need fixing in CSS not HTML5?<BR><BR>--<BR>Benjamin Hawkes-Lewis<BR><BR></DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>

      <hr size=1>Never miss a thing.  <a href="http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs"> Make Yahoo your homepage.</a></body></html>