RE: aria-current concerns from Apple

> For example, what is the expectation when a list has two elements that both claim to be "current"?

Authoring error. Is so, last one wins.

- Stefan



-----Original Message-----
From: Léonie Watson [mailto:lwatson@paciellogroup.com] 
Sent: Freitag, 11. September 2015 11:32
To: 'James Craig'; 'PF'
Subject: RE: aria-current concerns from Apple

> From: James Craig [mailto:jcraig@apple.com]
> Sent: 11 September 2015 08:22
> 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.
> >

How do you see this working from an AT user's perspective? Using your
example, would a screen reader announce something like "List of N items, X
is current TokenType"? For example, "List of 5 items, Home is current page".

> > 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.

This proposal makes sense to me. It would reduce the chances of duplication
through author error, and would actually make author implementation much
easier by having only one attribute to update as circumstances changed.

Unless it's possible to derive the same information through other means, I
think the token types are worth keeping. They make useful information
available about the type of thing that is current. This may be particularly
useful where there are multiple current elements within the same page (the
current page in a navigation block, and the current date in a date-picker
for example).

It might be worth associating the two attribute names though? This for
author usability as much as anything. Perhaps -current and -currenttype?

If this proposal gets consensus, I'm happy to revisit the -current
definition, and write-up the new attribute spec text if helpful.

Léonie.

-- 
Senior accessibility engineer @PacielloGroup @LeonieWatson

Received on Friday, 11 September 2015 09:35:41 UTC