- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 11 Mar 2012 11:36:00 +0000
- To: Matthew Turvey <mcturvey@gmail.com>
- Cc: Paul Cotton <Paul.Cotton@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, Sam Ruby <rubys@intertwingly.net>, "public-html@w3.org LIST" <public-html@w3.org>
On Sat, Mar 10, 2012 at 10:56 PM, Matthew Turvey <mcturvey@gmail.com> wrote: > On 14 February 2012 19:24, Paul Cotton <Paul.Cotton@microsoft.com> wrote: >>> If no Change Proposals are written by February 28th, 2012, this issue will be closed without prejudice and DEFERRED. >> and >>> Could I get until march 10th or so to write up a change proposal? >> >> The Chairs agree to this request and the due date for Change Proposals for ISSUE-204 is now March 10th, 2012. > > Please find below an updated change proposal, to allow ARIA attributes > to reference hidden elements, for ISSUE-204: > > http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc Some feedback. "One use case that has been brought up is the ability to provide a description to AT users, while still not affecting the design for non-AT users." Citation required. For example, the a11y TF longdesc CP says longdesc provides descriptions for people with cognitive or visual impairments and people with images off: http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/UseCases But that's a superset of people who use AT on top of a mainstream browser. "One simple way for page authors to provide such AT-specific content is to put it inside an element and add a hidden attribute to that element. As the specification is written today that is required to work and so authors are likely to do this even though the specification says it is invalid use of HTML." Citation required for the relevant requirements in the specification, plus an elaboration of what exactly "work" means here. Is it the sort of efficacy casual authors are likely to notice, or does it involve the use of specialised tools like NVDA or an accessibility inspector? "It doesn't for example negatively impact the usability or searchability of the page." Please explain in the CP how it does not reduce the usability for non-AT users who might benefit from either a visible long description or a mechanism for making it visible, such as people who are colorblind, people who are elderly with poorer sight, people browsing with images off. Also, please explain in the CP what you mean by searchability here. Are you speculating that search engines will/will not index such long descriptions and extract them in search result pages? Are you saying that browsers will not allow users to find text inside the long description? If you are an AT user to whom the text is presented as part of the page but your browser's search function fails to find text inside the description, isn't that a negative? Or maybe, you are saying that browsers will allow users to find text inside the long description? If so, isn't that a negative for users who cannot view the text in question? "We shouldn't deprecate longdesc until we have something better." This is not an argument against allowing aria-describedby to point to hidden content, so I don't understand why this is in the section "Rebutting counter arguments". "AT software doesn't need to be changed at all in order to implement this change proposal. AT software generally interacts with browsers by the browser exposing a dedicated accessibility tree. This means that if the browser exposes an accessibility tree even for elements that are hidden, the rich content inside the hidden element is exposed to the AT user in a fully accessible way, with no change to the AT software." The idea that "rich content is exposed … in a fully accessible way" assumes that AT is written to use the relation fields rather than the (string) description field in the relevant accessibility API, that it moves the content focus to the description content and that it allows users to navigate rich content like tables inside that description, trigger interactive content like links, search inside the content, and use a mechanism to return to the original content focus (the image) when they are done with the description. >From the lack of detail, I'm guessing what you're saying here is speculation. If so, please mark it as such. Otherwise, please document your test procedure, software, and results. "As currently implemented aria-describedby forces the user to listen to the description whether they want to hear it or not. … So far no vendor has indicated a refusal to fix this problem." Most of the key vendors (Freedom Scientific, GW-Micro, Dolphin, NVDA, Gnome a11y) are not involved in the WG. "As the relationship between the elements is programmatically determinable UAs and AT can make use of the linked description in whatever way is most effective for users. For example, a browser setting or plugin could expose hidden elements to sighted users via a special activation technique like a context menu item or popup widget" Ah ha. Finally some mention of consumption of long descriptions by people who aren't using AT. In theory, what you say is true. In practice, mainstream browsers are not likely to do that. The editor and browser developers have repeatedly expressed a viewpoint that ARIA markup is an annotation layer for communicating to accessibility APIs, not the basis for browser user interface. See for example: https://www.w3.org/Bugs/Public/show_bug.cgi?id=6496#c1 https://bugzilla.mozilla.org/show_bug.cgi?id=705829#c3 So, in practice, users who would benefit from hidden long descriptions but are not using AT are unlikely to be able to access them with future mainstream browsers. That's a problem as images need to be accessible at point of use (e.g. kiosks, public libraries). In so far as you're arguing this is an improvement over @longdesc, Opera has already implemented UI for opening long descriptions and the relevant bugs for Firefox and WebKit are open not WONTFIX. Providing @longdesc UI would not be a layering violation, but more comparable to providing UI for @cite (as recommended by the spec). So this part of your CP is wishful spec lawyering that goes against the declared intentions of vendors. Your proposed changes should include verbiage along the lines of "user agents should allow users to view hidden ARIA descriptions", comparable to the existing verbiage for @cite: http://dev.w3.org/html5/spec/the-blockquote-element.html#attr-blockquote-cite That way it will be clear that this proposal depends on a bleed-through from ARIA annotations to mainstream browser UI. "Describing a logo … There is no forced visual encumbrance. … JavaScript could be used on the page to display a clickable widget to toggle the referenced element's hidden on/off so it can be accessed by everyone." That would be a visual encumbrance, so that wouldn't meet the use case. "Describing Screenshots … This use case does not require the long description link to be hidden, so aria-describedby pointing to a normal link displayed on the page satisifes this use case without requiring the hidden attribute." "Describing a Chart … This use case does not require the long description link to be hidden, so aria-describedby pointing to a normal link displayed on the page satisifes this use case without requiring the hidden attribute." "Describing a Photograph … This use case does not require the long description link to be hidden, so aria-describedby pointing to a normal link displayed on the page satisifes this use case without requiring the hidden attribute." These use case discussions do not seem relevant to allowing @aria-describedby to reference @hidden content. Why are they cluttering the proposal? "The specific use cases and functional requirements for the DIAGRAM project, and digital talking books (DTB) and e-books (EPUB) generally, are unclear, but seem to require hiding content from non-AT users." If by "hiding content" you mean hiding content without providing a native mechanism for viewing the content, that's definitely not the case. The second email you cite says: "features developed to help people with specific disabilities also assist other users, and this is true for long image descriptions. Today, for example, Firefox and Opera allow the user to open a context menu over an image and choose to see the long description on the screen, if @longdesc is included with the image. This is an excellent tool for assisting sighted students with learning disabilities who need textual reinforcement when deciphering the contents of a complicated image. Also, as image descriptions become more widely used, it is expected that search engines can take advantage of descriptions in locating relevant images." http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html "it seems clear - longdesc will be obsoleted either in HTML5 or HTML6." That's not clear at all. "Using aria-describedby with hidden is a better solution than longdesc in this scenario because aria-describedby can be used with multiple languages used in EPUB like SVG and MathML, in addition to HTML5." SVG has a native mechanism for descriptions: http://www.w3.org/TR/SVG/struct.html#DescElement MathML accessibility is better met through a solution like the one used by MathPlayer: https://developer.mozilla.org/En/Accessibility/AT-APIs/Web_Specifications#MathML "People with cognitive disabilities, visual impairments, etc also benefit from long descriptions as noted in WCAG2 … By using aria-describedby to point to an element set to hidden, UAs can toggle visibility of the referenced element to make links with descriptive link text, and/or in-page descriptions using structured markup, available to all users." More wishful spec lawyering, I'm afraid. "Describing a Newspaper Image … This use case does not require the long description link to be hidden." Again, what's the relevance to this Change Proposal? "Details … Revert the change made at the request of the HTMLWG Chairs in http://html5.org/r/6980 to make the W3C version of the spec consistent with the WHATWG version of the spec." The text you propose to restore encourages authors to use this technique for hidden long descriptions. Your Change Proposal elsewhere makes it clear that using @aria-describedby with @hidden is only suitable if mainstream user agents provide mechanisms for viewing hidden descriptions. I therefore would expect to see such a mechanism should be a "SHOULD"-level requirement or feature in the Rendering section. "Makes the HTML5 specification have a simpler and more consistent message for how to deliver descriptions for elements. I.e. use aria-describedby everywhere." Hardly. <desc>, <title>, @title, <figcaption>, <caption>, etc. "Makes it possible to write simpler tutorials for how to enhance accessibility in HTML5 - use normal markup enhanced with ARIA where a programmatic association is required, and set to hidden where content is only for AT users." The fact that even a CP proposing this change is consistently confused about whether this content is for "AT users" or all users rather undermines the claim that tutorials will be simpler… "Provides a consistent way for UAs to hide content from non-AT users while exposing it to AT users, while also allowing hidden content be toggled visible if this is required. This is an advantage over traditional ways of hiding AT-specific content using CSS to position content offscreen." Not really, since that technique is often used with content that is not a description for an element. "Allows tools to be simpler since they can use a single mechanism for providing descriptions for elements, across multiple host languages." Not really, since as I described earlier there are still lots of specific description mechanisms. "Allows browsers and other HTML 5 implementations to focus their continued efforts on making aria-describedby great, rather than dividing their time between longdesc and aria-describedby, when longdesc is going to end up being obsoleted anyway." Again, there's no guarantee that longdesc will be obsoleted. "Encourages authors to make the description available both to AT and non-AT users, making collaboration easier." How does allowing @aria-describedby to reference @hidden content do that? "Makes the harmless and likely common usage pattern of putting AT specific content inside a hidden element valid." Harmless? Questionable. "aria-describedby could be rejected by implementations. However so far implementations have not given any indication that they are unwilling to implement aria-describedby. On the contrary aria has seen a vastly faster adoption in implementations than longdesc did." We have seen that implementors are unwilling to implement browser UI based on ARIA, so this statement seems false. I'd likely support either a textual change based on harmonising HTML with ARIA or a change based on marking a wilful violation of ARIA, as I think some sort of clarity is required. I'd likely formally object to a textual change that actively encourages authors to use a long description mechanism without text reflecting an intention of mainstream browsers to implement UI for accessing that long description. Image descriptions need to be part of the One Web. -- Benjamin Hawkes-Lewis
Received on Sunday, 11 March 2012 11:36:48 UTC