- From: John Foliot <john@foliot.ca>
- Date: Thu, 9 Feb 2012 00:16:04 -0800
- To: "'Jonas Sicking'" <jonas@sicking.cc>, "'Sam Ruby'" <rubys@intertwingly.net>
- Cc: <public-html@w3.org>
Jonas Sicking wrote: > > I agree we have two somewhat independent issues: > > 1. Should ARIA attributes be allowed to point to @hidden elements. ARIA attributes technically can point to hidden elements today - that is not the issue (even though, as I have discovered via limited testing, what is being pointed to is returned back as null content to in the screen readers I tested, which is currently correct behavior) - the point being it is not specifically disallowed as far as I can see. What is at issue is what happens to content not visible on screen: the Accessibility APIs flatten the content to string text, as none of the APIs were designed to support structured (marked-up) content. This point has been brought forward numerous times to this Working Group, and no-one has been able to show that this is not the case. It's not a browser issue, it's not an HTML5 issue, it's an OS/API issue - and an issue out of scope for the HTML WG. Hidden content, whether referenced by ARIA attributes or not, cannot (should not) support focusable content, as this throws of the long-held, WAI-required need to maintain visible tab focus for sighted, keyboard-only users (not just blind users, but any user unable to use a mouse): 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A) 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA) source: http://www.w3.org/TR/WCAG/ Failing to provide support to these requirements in a W3C Recommendation would be a willful violation of WCAG 2 - which is a very large discussion that would be fraught with numerous pain-points. (Do we really want to even go there?) However, at the same time it seems quite uncontroversial to suggest that longer textual descriptions of complex images require (would significantly benefit from) structured, marked-up text: anchors, headings, lists, tables, etc. I have not heard or seen anyone dispute this point. Content referenced via aria-describedby, aria-label, and aria-labelledby also lacks the 'user-choice' of consuming or not consuming the longer textual descriptions: the nature of those attributes is that they map to the Accessible Name or Accessible Description, which are directly conveyed to the Screen Readers for navigation and interaction purposes. ARIA attributes and values are not being exposed to any user-group outside of Screen Readers today - because only Screen Readers are availing themselves to the properties of the Accessibility APIs. This could change if browsers allowed sighted users the ability to 'discover' content 'tagged' by ARIA attributes. Arguments by the "obsolete @longdesc" advocates have repeatedly stated that longer textual descriptions should be available to all users (agreed), yet referencing longer textual descriptions *ONLY* via ARIA directly and completely shuts out those very (sighted) users argued as also needing/wanting longer textual descriptions. This is a Browser problem, not an HTML issue. Currently this is a "hoped-for" solution that creates as many potential problems as it seeks to solve. What continually gets passed over in this protracted discussion is the role that the browsers must play in delivering discoverable, user-choice-based, structured content. The mechanism of how that content is marked-up, programmatically linked, etc. is not the real issue - it is the user interaction model that needs to be delivered on. You could call the attribute "Duck Soup" for all it really matters, without browser support it's a moot point for any user outside of screen reader users. For those users, @longdesc today will work in many of the major screen readers today, and delivers on the 3 key user requirements. > 2. Should @longdesc be marked as obsolete. No. * The HTML5 principle of backward compatibility suggest it should not. * The current support in many Screen Readers to deliver the required functionality of discoverabilty, user-choice and support of HTML rich content today suggest it should not. * The emergence of "properly" coded @longdesc by actors such as the Canadian Government (who seem to be producing a lot more @longdesc content these days) suggest it should remain. * The willingness of commercial content producers, such as the recent support voiced by educational publishers (for example) suggest that well-coded @longdesc content will continue to emerge and grow. * Authoring tools currently part of the production tool-chain have made adding @longdesc to images in WYSIWYG interfaces almost "idiot-proof" (http://john.foliot.ca/wysiwyg_longdesc/) * Alternative techniques ALONE should not be a reason to obsolete an element or attribute from HTML5 - and here we have precedence: the <u> element (underlined text can be achieved via CSS), <b> (bold text can be achieved via CSS) and <i> (italicized text can be achieved via CSS). Arguments stating that new semantics have been added to these elements that make them valid is hollow: browser support for @longdesc would improve that attribute significantly as well. > > However it seems like issue 2 depends on issue 1. I.e. the case for > marking longdesc as obsolete is stronger if ARIA is allowed to point > to hidden elements. > > Would it be possible to ensure that we decide on 1 before we poll on 2? I really think that this is putting the cart before the horse. Deal with @longdesc now (restore it to HTML5), and then let's get the browser vendors, the ARIA folk and other vested stake-holders together and work out a longer-term ARIA solution that DOES deliver on discoverability, user-choice and HTML-rich content support. There is already talk of minting a new ARIA attribute for ARIA 1.1 that could do just that, but rushing towards an ARIA solution (by promoting a broken and ill-conceived solution with current ARIA attributes) today simply to satisfy a WHATWG desire to bury @longdesc is the wrong way to address this contentious issue. (Chairs, by way of that last statement, I too would support a splitting of Issue 30 to a new HTML issue if it is to improve ARIA and does not include obsoleting or "deprecating" longdesc from HTML5.) JF
Received on Thursday, 9 February 2012 08:17:04 UTC