Another proposal: aria-roledescription

[Dominic Mazzoni]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28317

I propose that we add a new attribute aria-roledescription.

The value of this attribute would be a localized string containing specific text that could be communicated to the user as a more specific description of the actual ARIA role of the element.

The use case this solves is when an application has a UI widget that doesn't fit any of the existing ARIA roles, and just calling it one of the existing ARIA roles without any additional explanation would be confusing.

A role description does not affect the semantics in any way. AT must not interpret the string, they should just present it in place of the usual text used to describe that role.

The use case is for controls that are obscure enough that they don't belong in ARIA, but are nevertheless useful for some applications that employ them.

* A drawer handle

* A listbox that wraps around

* A 4-way toggle button

* A backwards slider

[Alexander Surkov]

As we go aria-role should be fixed too since afaik it's not extensible, i.e. you cannot introduce a new role and thus there's nothing to localize.
It would be good to hear from AT developers how they will use it.

Thanks.

Alexander.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYzAUCL0q24PNYbB%3D9niFZPRkbxhSh6exo2TCqXw3diKuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Dominic Mazzoni]

I guess I don't really understand how we could allow authors to extend ARIA roles, because adding a new role requires everyone to agree on the semantics - the web developer, the browser, and the AT. If any one of them doesn't understand the role, nothing works.

Having a role description doesn't have any of those limitations. The semantics still come from whatever role you pick. The role description is simply a way to describe it in more detail to the user.

FWIW, NSAccessibility on Mac has AXRoleDescription and IAccessible2 has localizedExtendedRole, so we don't even need new native specs to start implementing this.

- Dominic

[David Bolter]

Yeah. I recall the idea of having a role description coming up before but I can't find the thread (or meeting notes)...

D

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYzPzWtTOjWqkTYAZ39KCZCPZ49fmdDWm8hMGtXW2XUDwA%40mail.gmail.com.

[Alexander Surkov]

On Mon, Mar 23, 2015 at 12:26 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

I guess I don't really understand how we could allow authors to extend ARIA roles, because adding a new role requires everyone to agree on the semantics - the web developer, the browser, and the AT. If any one of them doesn't understand the role, nothing works.

true, it has to be hard to make it working with no taxonomies

 

Having a role description doesn't have any of those limitations. The semantics still come from whatever role you pick. The role description is simply a way to describe it in more detail to the user.

then probably aria-roledescription is a bad name because one and same role may be have different descriptions which sounds like ambiguity, maybe aria-rolerefinement or similar?

 

FWIW, NSAccessibility on Mac has AXRoleDescription and IAccessible2 has localizedExtendedRole, so we don't even need new native specs to start implementing this.

I think these were introduced to describe new roles, but I guess they can be used for this case.

[Dominic Mazzoni]

On Mon, Mar 23, 2015 at 9:51 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

On Mon, Mar 23, 2015 at 12:26 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

I guess I don't really understand how we could allow authors to extend ARIA roles, because adding a new role requires everyone to agree on the semantics - the web developer, the browser, and the AT. If any one of them doesn't understand the role, nothing works.

true, it has to be hard to make it working with no taxonomies

I'm not opposed to the idea of taxonomies, I just think that custom taxonomies that the web developer can extend would be tricky and complicated, and aria-roledescription would be simple and solve a lot of the use cases.

Having a role description doesn't have any of those limitations. The semantics still come from whatever role you pick. The role description is simply a way to describe it in more detail to the user.

then probably aria-roledescription is a bad name because one and same role may be have different descriptions which sounds like ambiguity, maybe aria-rolerefinement or similar?

I'm not sure I like aria-rolerefinement. How about aria-roletext? It's kind of analogous to aria-valuenow and aria-valuetext. valuenow is the numerical value for semantics, and valuetext is the way it should be described to the user.

 

 

FWIW, NSAccessibility on Mac has AXRoleDescription and IAccessible2 has localizedExtendedRole, so we don't even need new native specs to start implementing this.

I think these were introduced to describe new roles, but I guess they can be used for this case.

This is kind of like new roles "lite" - you want to introduce a new role, but this is a way to do it in a way that's backwards-compatible.

[Alexander Surkov]

ad

On Mon, Mar 23, 2015 at 2:14 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

On Mon, Mar 23, 2015 at 9:51 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

On Mon, Mar 23, 2015 at 12:26 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

I guess I don't really understand how we could allow authors to extend ARIA roles, because adding a new role requires everyone to agree on the semantics - the web developer, the browser, and the AT. If any one of them doesn't understand the role, nothing works.

true, it has to be hard to make it working with no taxonomies

I'm not opposed to the idea of taxonomies, I just think that custom taxonomies that the web developer can extend would be tricky and complicated, and aria-roledescription would be simple and solve a lot of the use cases.

fair enough

 

Having a role description doesn't have any of those limitations. The semantics still come from whatever role you pick. The role description is simply a way to describe it in more detail to the user.

then probably aria-roledescription is a bad name because one and same role may be have different descriptions which sounds like ambiguity, maybe aria-rolerefinement or similar?

I'm not sure I like aria-rolerefinement. How about aria-roletext? It's kind of analogous to aria-valuenow and aria-valuetext. valuenow is the numerical value for semantics, and valuetext is the way it should be described to the user.

I thought about aria-roletext but it sounded a bit generic. It'd be good though to find some word to say that this property is about role adjustment or specializing.

 

 

 

FWIW, NSAccessibility on Mac has AXRoleDescription and IAccessible2 has localizedExtendedRole, so we don't even need new native specs to start implementing this.

I think these were introduced to describe new roles, but I guess they can be used for this case.

This is kind of like new roles "lite" - you want to introduce a new role, but this is a way to do it in a way that's backwards-compatible.

OS X API has concept of subroles which is sort of alternative or addition to your suggestion.

[Dominic Mazzoni]

On Mon, Mar 23, 2015 at 11:47 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

OS X API has concept of subroles which is sort of alternative or addition to your suggestion.

The difference is that a subrole still has to be understood by the AT in order for it to do anything. A role description is a hint to a screen reader to speak or braille a different localized string instead of saying "checkbox" or "button", and it allows for an application-specific role that never has to be standardized.

[Alexander Surkov]

If you introduce new semantics then it's ok to expect it being understood by AT, the advantage of subrole approach is it's backward compatible. I think there are cases that can be handled by role text but it has to be too simple to express semantics in full. Btw, how AT is supposed to use the new attribute?

 

[Dominic Mazzoni]

On Mon, Mar 23, 2015 at 2:24 PM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If you introduce new semantics then it's ok to expect it being understood by AT, the advantage of subrole approach is it's backward compatible. I think there are cases that can be handled by role text but it has to be too simple to express semantics in full. Btw, how AT is supposed to use the new attribute?

AT is just supposed to use it in place of the role name. If you have an object with role=listbox, a screen reader normally speaks "album picker, list box", then adding aria-roletext="carousel" would make it speak "album picker, carousel". In terms of semantics it would still behave like a listbox because that's its role.

[James Teh]

On 24/03/2015 1:50 AM, 'Dominic Mazzoni' via Browser Accessibility

Development wrote:
> I propose that we add a new attribute aria-roledescription.
> The value of this attribute would be a localized string containing
> specific text that could be communicated to the user as a more specific
> description of the actual ARIA role of the element.

I'm about to further my reputation of being
pedantic/resistant/difficult. :) Regardless, I've always been somewhat
dubious at best (downright opposed at worst) to this idea. IMO, this is
usually used as a hack to avoid defining new roles where new roles
really should be created.

> The use case this solves is when an application has a UI widget that
> doesn't fit any of the existing ARIA roles, and just calling it one of
> the existing ARIA roles without any additional explanation would be
> confusing.

If there is a need to change the text like this, that almost always
suggests there in fact *are* new semantics. Otherwise, there wouldn't be
a need to change the text in the first place.

> A role description does not affect the semantics in any way. AT must not
> interpret the string, they should just present it in place of the usual
> text used to describe that role.

* What if the AT would usually not speak role text at all? For example,
NVDA doesn't speak list item, table cell, menu item, etc.
* What if the role is communicated in some other way; e.g. a sound?
* What if there is an abbreviated version of the role for braille?
Braille users prefer abbreviated roles for efficiency reasons.

> * A drawer handle
What role would this be? Why is that role text confusing?

> * A listbox that wraps around

Would something like "wrap around list box" really make much sense to
most users? Is there a reasn that this actually needs to be communicated
anyway?

> * A 4-way toggle button
> * A backwards slider

I'd argue these all have additional semantics, particularly the last
one. That really needs to be communicated using some sort of orientation
property.

Other issues:
1. Unnecessary usage: While everything can be abused and this isn't in
itself a reason to block it, I think this one is particularly
problematic in this respect. I've seen usage examples like "buddy list
item", "buddy", etc. That just creates annoying verbosity for the user
and makes them think it is different in some way when it really isn't.
If this is adopted, these cases need to somehow be recommended against.
2. Expected behaviour: Aside from predefined semantics and widespread
usage, common roles also have the advantage that the user knows what to
expect when they're encountered. In contrast, when the role text is
changed, the user doesn't know what to expect. They can't assume
anything. Like everything else, they'll eventually learn, but because
this opens up the field to a literally infinite number of possibilities,
the problem is thus infinitely magnified.
3. Inconsistency: Similar to (2). Because the text is entirely author
defined, different authors might define different text for what is
essentially the same widget. This could confuse users even further.

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org

[aboxhall]

On Monday, March 23, 2015 at 11:47:43 AM UTC-7, Alexander Surkov wrote:

Having a role description doesn't have any of those limitations. The semantics still come from whatever role you pick. The role description is simply a way to describe it in more detail to the user.

then probably aria-roledescription is a bad name because one and same role may be have different descriptions which sounds like ambiguity, maybe aria-rolerefinement or similar?

I'm not sure I like aria-rolerefinement. How about aria-roletext? It's kind of analogous to aria-valuenow and aria-valuetext. valuenow is the numerical value for semantics, and valuetext is the way it should be described to the user.

I thought about aria-roletext but it sounded a bit generic. It'd be good though to find some word to say that this property is about role adjustment or specializing.

FWIW the relevant PF discussion is here (that was the last message in the thread): https://lists.w3.org/Archives/Public/public-pfwg/2014May/0034.html - @locrole was the last suggestion there.

[Dominic Mazzoni]

On Fri, Apr 3, 2015 at 3:12 PM, aboxhall <abox...@google.com> wrote:

FWIW the relevant PF discussion is here (that was the last message in the thread): https://lists.w3.org/Archives/Public/public-pfwg/2014May/0034.html - @locrole was the last suggestion there.

Thanks.

I'm not sure I have more to add to the discussion. I think Jamie makes some good points - authors would make up their own roles for things, it wouldn't be consistent across sites, and there are several corner cases (like where the role isn't normally spoken) where it isn't clear what the AT should do.

I guess my opinion is that we shouldn't be afraid to try adding an API just because authors might use it poorly, if the legitimate use case is strong enough. Since we don't have a consensus now or any really compelling use cases, I guess I'd like to set this aside and keep working on the ideas where we're closer to a consensus.