- From: Léonie Watson <lwatson@paciellogroup.com>
- Date: Fri, 11 Sep 2015 10:31:59 +0100
- To: "'James Craig'" <jcraig@apple.com>, "'PF'" <public-pfwg@w3.org>
> 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:32:23 UTC