RE: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

Hi Dominic,

 

So I fear that some of this may come off as condescending, and that is not my intent, so if you are left with that impression I apologize in advance. 

 

Starting with http://www.w3.org/WAI/intro/aria it states:

 

      "More specifically, WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state. WAI-ARIA describes new navigation techniques to mark regions and common Web structures as menus, primary content, secondary content, banner information, and other types of Web structures. For example, with WAI-ARIA, developers can identify regions of pages and enable keyboard users to easily move among regions, rather than having to press Tab many times.

 

      WAI-ARIA also includes technologies to map controls, Ajax live regions, and events to accessibility application programming interfaces (APIs), including custom controls used for rich Internet applications."

 

Q: When you enable users to navigate a page with a means other than just tabbing, have you not created a new UI pattern? Also, I see nothing there that states that ARIA *MUST* only work with Assistive Technology, although I will agree it is strongly hinted as such.

 

Equally important however, the WAI 1.0 Recommendation states:

 

      "This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications."

 

Q: If ARIA was never intended to augment UI behaviors, why does it say this in the Recommendation? While I note that today no browser provides users the ability to do page-level keyboard navigation using ARIA roles (or landmark elements for that matter AFAIK), this doesn't mean that a) browsers couldn't provide this feature natively, nor b) that this must always be a function/feature of a helper application such as AT software. 

 

 

 

More specific to your question however, ARIA is intended to be language agnostic - it can applied to any markup language, for example SVG:


<svg xmlns=http://www.w3.org/2000/svg role="img" aria-labelledby="title  desc">

   <title id="title">Circle</title>

   <desc id="desc">Large red circle with a black border</desc>

   <circle role="presentation" cy="60" r="55" stroke="black" stroke-width="2" 

   fill="red" />

</svg>

(source: http://www.paciellogroup.com/blog/2013/12/using-aria-enhance-svg-accessibility/ - and please note the current support for ARIA and SVG in that article) 



…and so my question is, if there is a native behavior in HTML that provides accessibility support, should we not ensure that it is also abstracted to ARIA, so that same support can be extended to other markup languages? I'm not stating it MUST at this time, but rather ask if that isn't a reasonable position/assumption to make?

 

 

I believe it is also worth mentioning that we've heard in the past the need to apply a @longdesc-type feature to other complex containers (<table>?), which the current @longdesc Recommendation does not allow, so even in native HTML, we'll need @longdesc-type interaction/functionality moving forward. Why limit this to only users of Assistive Technology? (I am sure as well that you know this has been the topic of more than one pub-discussion; whether or not ARIA should be restricted to only AT, or whether we might see more uptake if it delivered more native features/functionality?)

 

 

Dominic, if you are not already aware of some earlier conversation, might I suggest the thread that starts here:

http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0241.html 

 

and of particular note:

http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0247.html 



(see the comments regarding NVDA's philosophy regarding defining a user-interaction, but rather the desire to map to a pre-defined interaction 'native' to the browser.)

 

Finally, it is worth also pointing out that efforts such as ePub (yes, built upon HTML5, but with some differences) also need/want a similar mechanism:
http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0254.html 
http://www.idpf.org/accessibility/guidelines/content/script/aria.php 

 

JF

 

 

 

 

 

From: Dominic Mazzoni [mailto:dmazzoni@google.com] 

Sent: Monday, December 8, 2014 10:40 AM

To: John Foliot

Cc: James Craig; WAI XTech; Alexander Surkov; Michael[tm] Smith; Daniel Weck; Ted O'Connor; Janina Sajka

Subject: Re: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

 

"do you believe that native HTML accessibility support constructs should be available to all markup languages? That ARIA is, by design, markup language agnostic and so if an accessibility feature is available in HTML, it should also be abstracted and available to other markup languages via ARIA?"

 

I'm not sure I quite understand the question. Could you give an example or two, even hypothetical?

 

 

JF

 

 

From: Dominic Mazzoni [mailto:dmazzoni@google.com] 

Sent: Monday, December 8, 2014 9:16 AM

To: John Foliot

Cc: James Craig; WAI XTech; Alexander Surkov; Michael[tm] Smith; Daniel Weck; Ted O'Connor; Janina Sajka

Subject: Re: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

 

On Mon, Dec 8, 2014 at 9:04 AM, John Foliot <john@foliot.ca> wrote:

I think as well that your characterization of "dissent" w.r.t. Gecko and Blink

is, shall I say, somewhat exaggerated, but (again) I think we should ask these

actors directly, and neither you nor I assume anything.

 

Just to be clear, then, I officially object/dissent to the language "User agents should provide a device-independent mechanism to allow a user to..." used anywhere in the ARIA spec, because I feel the user agent directly providing to all users a user-level feature based on an ARIA attribute is a radical departure from the rest of the ARIA spec.

 

Resolutions I would be happy with include:

* Change the language so that aria-describedat is mapped to native accessibility APIs only, like the rest of ARIA

* Or, make it part of HTML5 and take ARIA out of the name