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

Dominic,

First (to all) this discussion belongs on the public PF list.

Second, any specification can make suggestions via MAY that a user agent
could adopt that will help the user experience. I agree that the ARIA
specification should not make normative requirements on the UI for the
browser. This particular requirement came in from George Kerscher who is
the president of IDPF and who asked for aria-desribedat be in the ARIA
spec. for 1.1 to allow for crowd sourced descriptions as part of Diagram
project for education. See: http://diagramcenter.org/about.html


They wanted to create a digital repository for image descriptions that
could be reused in books to allow book authors to retrieve descriptions
that could be used on images. EPUB is supported by the Android Book Reader,
Google Books, and IBooks, and IPages, IBookAuthor import, etc.

The first release of the ARIA 1.1 Public Working draft simply had
aria-describedat in the spec. and you also voted to publish it:
http://lists.w3.org/Archives/Public/public-pfwg/2013Sep/0060.html


If I had to take a position on who should determine where the use of
aria-describedat MUST change the UI appearance that should be left up to
the host language.

I hope this recaps things. The ARIA task force has not taken a stand either
way as to whether aria-describedat is at risk. I am fairly certain that the
ARIA task force would not reach consensus a normative MUST how
aria-describedat would rendered in the UI itself. UP to now we have had the
position that we would not dictate browser UI features. If a browser wants
to do that that would be up to the user agent. It is likely that EPUB
readers like Readium will likely produce a visual indication that there is
an aria-describedat in the content should it proceed to recommendation.

Rich


Rich Schwerdtfeger



From: Dominic Mazzoni <dmazzoni@google.com>
To: John Foliot <john@foliot.ca>
Cc: James Craig <jcraig@apple.com>, WAI XTech <wai-xtech@w3.org>,
            Alexander Surkov <surkov.alexander@gmail.com>, "Michael[tm]
            Smith" <mike@w3.org>, Daniel Weck <daniel.weck@gmail.com>, "Ted
            O'Connor" <eoconnor@apple.com>, Janina Sajka
            <janina@rednote.net>
Date: 12/08/2014 01:57 PM
Subject: Re: @aria-describedat at-risk in ARIA 1.1 heartbeat draft



  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.


Whether or not this is what was originally intended, I think David Bolter's
argument is very clear here. Part of the success of ARIA is due to the fact
that web authors can trust that ARIA does not affect the behavior of their
UI. The spec is not clear in this regard, but it has never explicitly
required a browser UI behavior change in the past and I think it'd be a
mistake to do so.

I see no reason why a browser couldn't provide additional, optional
functionality to allow a user to take advantage of ARIA on the page by
adding *new* keyboard shortcuts. If a browser took an existing feature and
modified it to behave differently depending on ARIA, I think that'd be a
mistake.
  …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?


Yes, I agree with this.

For example, HTML table cells can have a rowspan or colspan. I think ARIA
grids need to be extended to support this too.

- Dominic