Re: ISSUE-204: aria-hidden - Chairs Solicit Proposals (was: Chair review of "Keep Longdesc Deprecated")

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