- From: John Foliot <jfoliot@stanford.edu>
- Date: Mon, 23 Aug 2010 11:02:48 -0700 (PDT)
- To: "'Jonas Sicking'" <jonas@sicking.cc>, "'Joshue O Connor'" <joshue.oconnor@cfit.ie>
- Cc: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'HTML WG'" <public-html@w3.org>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>, "'Barry McMullin'" <barry.mcmullin@dcu.ie>, "'Laura Carlson'" <laura.lee.carlson@gmail.com>
Jonas Sicking wrote: > > You can even support older UAs which doesn't support the > 'hidden' attribute using CSS or simply adding a style="display:none;" > attribute. Hi Jonas, FYI, both the @hidden attribute and "display:none;" hides content from screen-readers as well. Whether or not this is appropriate behaviour for a screen reader has been discussed before at great length, but regardless of which side of that discussion you come down on, as the browser folk keep reminding us, the implementation behaviour is the one that counts today, and that's what screen readers do at this time. (In the case of @hidden, this is in fact the behavior that is described in the spec:) "When specified on an element, it (@hidden) indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified." [1] So the longer description is not "relevant"? Hmmm.... (I'm positive Jonas that this is not what you actually want) The real problem with out-right removing a perfectly valid but under-used part of HTML (whether an element or attribute) today is that there are ripple effects that the simple engineering decision affects that fall outside of the direct engineering decision. Deprecating @longdesc (or as it is structured in HTML5, conforming but with an advisory) would have allowed a graceful longer-tail exit strategy (if one assumes that @longdesc is fatally flawed - and many do not even accept that). That is also why it was the second (lesser preferred but accepted) option that the Accessibility Task Force put forth [2] (yet the Chairs suggested that this was the least preferred option - despite the fact that it is already the option and behaviour for @summary... [3][4]). The current decision simply removes things immediately, and leave the fall-out to somebody else to clean up - a situation that is *extremely* objectionable to many. Rest assured, this is not resolved yet by any stretch of the imagination. The flip-side question is: Why is it so difficult for today's browsers to provide the attribute support for all users? Is it really that hard for Mozilla to go from showing the URL of a long description link in the right-click context menu, to actually making it a workable/serviceable link for all users? Nobody has adequately explained why browsers today (outside of Opera and iCab) have not supported this now decade-old attribute in any useful way (an attribute BTW, that remains conformant and valid in HTML 4/XHTML 1 today). Why must the accessibility community find work-around solutions for browser failures? What happened to users over authors over implementers over technical purity? It seems that removing the attribute is a technically pure solution to a perceived problem, but it only solves one problem, and even then the problem it solves is not the bigger problem but rather a detail of the larger issue: complex images require complex descriptions for those users who cannot see or otherwise grasp what the image is seeking to convey, and to date most web authors have simply not provided that longer description - in page, off page, anywhere. The quality of the longer description is the real problem, not the method that we use to link it to any given image: in this regard @longdesc is actually quite elegant, as it makes the link a direct attribute of the image asset (as opposed to creating an association to an external link that then goes to the same longer description) - as well, @longdesc *today* can point to both URI's *OR* IDREF's (if authors really believe that in-page descriptions are better - a point still debated [5]), whilst aria-described by is limited to IDREFs at this time. However neither solution ensures that the data at the other end of the link is valid or valuable, which is the larger issue. Killing off @longdesc simply shoots the better messenger first. JF [1] http://www.w3.org/TR/html5/editing.html#the-hidden-attribute [2] http://lists.w3.org/Archives/Public/public-html/2010Apr/1089.html [3] http://www.w3.org/TR/html5/obsolete.html#warnings-for-obsolete-but-conform ing-features [4] http://www.w3.org/TR/html5/tabular-data.html#attr-table-summary [5] http://www.cssquirrel.com/2010/08/16/comic-update-alone-in-the-pitch-black -dark/
Received on Monday, 23 August 2010 18:03:25 UTC