RE: FORMAL OBJECTION (was RE: Working Group Decision on ISSUE-204 aria-hidden)

Benjamin Hawkes-Lewis wrote:
> 
> On Wed, Aug 15, 2012 at 11:18 PM, John Foliot <john@foliot.ca> wrote:
> > How do *you* think a Deaf person might access such descriptions that
> are @hidden but "conforming"?
> 
> If they wanted to access them, I'd expect them to use a user agent
> with a mechanism for exposing them.
> 
> The challenge of universal access to hidden descriptions is not
> specific to descriptions that have structure or interactivity. Yet
> ARIA blesses hidden descriptions and accordingly so do both CPs.

See, right there, this is where I believe you are misunderstanding ARIA. 

ARIA "blesses" nothing, but rather has an affordance that allows web-based UI's to express equivalencies of GUI controls in a non-visual way. 

aria-describedby is to map to the following:
 
 MSAA + UIA Express: Use in calculating the accessible Description as described in Name Computation. Expose in accDescription property. 
----------------

 MSAA + IAccessible2: Use in calculating the accessible Description as described in Name Computation. Expose in accDescription property.

  IAccessible2:

      * If the object is in the accessibility tree, expose pointer to the accessible object in IA2_RELATION_DESCRIBED_BY
      * Expose reverse relations as described in Relations.
----------------
 
 UIA: Use in calculating the accessible Description as described in Name Computation.
----------------

 ATK/AT-SPI: Expose pointer to the accessible object in DescribedBy property.
 Use in calculating the accessible Description as described in Name Computation550. Expose pointer to the accessible object in RELATION_DESCRIBED_BY. Expose reverse relations as described in Relations.
----------------

 Mac OS X: Use in calculating the accessible Description as described in Name Computation. Expose in string AXDescription (reserved for non-visible accessible name or calculated description)


GUI widgets, especially complex ones, require both an accessible name and an accessible description, which is then used by the Accessibility APIs to communicate information about [visual thing] to tools that avail themselves to those APIs for practical user reasons (such as being a screen reader).

Neither the APIs nor aria-description were designed to be outputting complex structured data, nor the concept that it be used to actually output multi-sentences worth of human readable text, and neither "blesses" their usage in this way. It is this new CP that seeks this "blessing", which the Chairs and this Working Group believe to be their right to bestow (Rich Schwerdtfeger for one may disagree).

In the CP that I was a part of authoring, we recognize that in reality, aria-describedby *could* be used to output more than just a few words of "description", and that a relatively meaningful, human consumable description could be delivered that way. It would not be our first choice, it was certainly not seen as a viable replacement for @longdesc, but it *was* an admission and documentation of what was already in practice today. If you believe that the "losing" CP was advocating for, or endorsing more than simply that, then you have read more into it than was authored into it - I know, because I was there when we talked about it face-to-face, and I helped write it.

JF

Received on Wednesday, 15 August 2012 23:39:02 UTC