Re: Issue 204 and accessibility APIs

On Thu, Apr 19, 2012 at 12:24 PM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
> If you have specific verbiage that you would like to propose to be included
> that would enable you to support the details section of the CP please do elaborate.

I was pointing out one implication that's been repeated in a few
different contexts that doesn't make sense to me based on my
understanding of the APIs involved.

With respect to the CP as a whole …

Your CP suggests we change the W3C HTML snapshot to make
@aria-describedby referencing @hidden a "may" not a "should not".
Maybe that's a good idea, but I'm not sure what rationale your CP
offers for that change.

ARIA vaguely defines algorithms for the calculation of accessible
names and descriptions, but it does clearly state that calculated
accessible names and descriptions are exposed as plain text.

@aria-describedby may contribute to accessible names and descriptions.
Therefore it would be bad practice to use @aria-describedby to point
to elements which, when reduced to plain text by these algorithms, do
not produce a good accessible name or description. It makes sense for
this to be reflected in an author conformance requirement. But whether
the referent elements are @hidden makes no difference to how they are
reduced to plain text. Therefore it does not make sense to add this to
the definition of HTML @hidden as though @hidden were the problem with
reduction of markup to plain text:

    "This technique [referencing @hidden content with
@aria-describedby] should not be used for longer content that have
structured text (e.g., headings, anchors, list markup, table markup,
etc.), as rich text is stripped to string text, resulting in all
semantic structure being lost."

ARIA should define what an accessible description is and set an author
conformance requirement that accessible names and descriptions
calculated according to its algorithm must be appropriate, giving some
examples and explanations of good and bad usage.

As far as I can tell from ARIA's normative requirements, HTML5 is free
to define @hidden so that its elements have an effective label of the
empty string in ARIA's algorithms if we wanted to prevent @hidden
content ever being exposed as accessible names and descriptions. I
think Jonas's suggestion that authors will use @aria-describedby to
point to @hidden content whatever our specs say is a plausible
argument against doing so.

Even so, HTML5 is also free to say authors must not use
@aria-describedby to @hidden content, regardless of how such markup is
processed when they do. For example, we might want to forbid providing
text alternatives for images using this technique, on the basis text
alternatives should also be available in text-mode clients, when
images are disabled, when images fail to load due to network failures,
etc. but it's not clear how text alternatives referenced in this way
should be incorporated into the view tree for user agents implementing
the standardized rendering.

If ARIA included a technique for creating a description-for
relationship between two nodes in the tree that did not imply the
reduction of the description node to plain text then it would be
appropriate to forbid that technique to point to @hidden content on
the basis that it's not clear how descriptions under @hidden could be
made visible for user navigation and interaction for example with a
screen magnifier. But ARIA does not have such a technique (yet) so
this objection to referencing @hidden is not especially important.

(Yes, the ARIA implementation guide suggests mapping @aria-describedby
to a description-for relationship - available in IAccessible2, ATK,
and UI Automation - and allowing users to navigate to that content.
But as ARIA proper also requires user agents to expose
@aria-describedby in accessible name and description calculation, best
practice continues to dictate that users author under the assumption
@aria-describedby will be exposed to the user as plain text.)

--
Benjamin Hawkes-Lewis

Received on Thursday, 19 April 2012 22:53:04 UTC