[whatwg] [HTML5] Accessibility question

@irrelevant is virtually indistinguishable from setting content to display: none. My point in bringing up accessibility with a possible attribute or element is to figure out where the lines between HTML and CSS are, as it appears HTML 5 has muddied the water. As I stated earlier on this list, if something is truly "irrelevant", then it's not included in the page. Something that's on the page and hidden is relevant, just perhaps not at the current time, which led to the suggestion on this list to rename the attribute "ignore". 

I understand your point about superfluity being defined by the presentation (one could argue the same about relevance...). Aural CSS seemed, at one point, like it would make sense for handling such issues. However, since screen readers read the "screen" media styles, it doesn't really help. 

I still feel like it's a good idea to have an optional attribute on each element that indicates the element's content should not be ignored by screen readers regardless of the style applied. Perhaps this could be better handled by an ARIA role...

-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: Wednesday, March 26, 2008 12:27:37 PM
Subject: Re: [whatwg] [HTML5] Accessibility question

Nicholas C. Zakas wrote:
> The first use case is now handled in HTML 5 via @irrelevant. 

I don't think it is, actually:

http://www.w3.org/html/wg/html5/#the-irrelevant

Additional content is not "irrelevant"; it's helpful sometimes and 
superfluous at other times.

The draft spec says "User agents should not render elements that have 
the irrelevant attribute specified". This is incompatible with what I'm 
suggesting, which is that user agents might want to render additional 
content when it is helpful and ignore it when it is superfluous.

The intention of the draft seems to be that @irrelevant should be 
manipulated by scripting. That too is incompatible with what I'm 
suggesting, where UA logic and user actions decide whether to render 
additional content or not (a bit like @title).hey

> 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).

Display: none; or visibility: hidden; affect only the suggested 
presentation of information; @irrelevant changes the semantics.

It's true that developers sometimes try to use display: none; and 
visibility: hidden; like @irrelevant could be used; I think that's 
(often) unwise because they are such brittle tweaks in the wrong layer.

> I'm very familiar with defining separate CSS classes for moving content 
> offscreen, and it seems like a big hack to me.

It is very hacky, agreed.

> It also seems that this 
> is a common enough use case that it merits further investigation.

Yep.

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

Sometimes content's superfluity is itself dependent on the 
presentational skin. For example, if CSS radically distinguishes a 
navigation area from surrounding content, having a "Navigation" header 
might become superfluous. In such cases, it makes more sense to use the 
off-screen hack or some better (future) CSS technique, e.g.:

nav h1:out-of-context {
     display: block;
}

But ideally a suggested presentational skin should not be used to try 
and designate content to be superflous when its superfluity depends on 
browsing context not the skin itself, for example when part of a link's 
text is superfluous if you're going through the document in order.

--
Benjamin Hawkes-Lewis







      ____________________________________________________________________________________
No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo! users and friends. 
http://tc.deals.yahoo.com/tc/blockbuster/text1.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080330/2aad807c/attachment.htm>

Received on Sunday, 30 March 2008 22:10:02 UTC