Re: aria-current concerns from Apple

Does the concern come from assistive technology developers? If so then you
can make browsers to take care of handy a11y API mapping. After all it
looks that the proposal is makes life of a web developer a little bit
tricky than the existing aria-current version.

On Fri, Sep 11, 2015 at 3:22 AM, James Craig <jcraig@apple.com> wrote:

> Forwarding some concerns on @aria-current from some of the engineers
> working on implementation. Note: that the "indicatortype" name was my
> suggestion, but we're definitely not married to the name. It's also
> possible the aria-current implementation would be strong enough as just an
> IDREF pointer without supporting the new token types.
>
>
> Comments from Apple Accessibility Engineering:
>
> > We have a concern with the aria-current proposal in its current form.
> >
> > From an implementation perspective, the specification makes it difficult
> to do things like announcing the current element in a list when you first
> navigate to the beginning of that list. This is because aria-current is
> only exposed on the object that is current, rather than the containing
> element. A deep traversal is possible, but computationally expensive on
> initial rendering and when maintaining the model as descendant elements
> change.
> >
> > The current modal can also lead to author errors if aria-current is
> modified on all other objects when choosing a new aria-current. For
> example, what is the expectation when a list has two elements that both
> claim to be "current"?
> >
> > New proposal:
> >
> > aria-indicatortype="TOKEN( page | date | ... )" on the leaf element.
> >       remains the token based list of options
> >
> > aria-current="IDREF" on the container element
> >       its value should be the ID of the object that is current, which
> must be a descendant of the container.
> >
> > Thanks for considering.
>
>
>
>
>