Re: ISSUE-636 CTION-1398 Provide spec. text for aria-roledescription

Hi all,

DavidB and I just chatted about this. We are both very much for
aria-roledescription, but like David, I am concerned about growing
complexity. To repeat some of what David wrote in his message to this list:

> As usual I'm worried about complexity. We would present web devs with
> these ways of describing an object:
>
> alt
> title
> aria-describedby
> aria-label
> aria-labelledby
> aria-roledescription
>
> Also note possible additional complexity with the naming and reporting
> algorithms. If this attribute is only for role group and region does it
> really meet the bar? Why wouldn't aria-label work?

We already have so many ways of naming an object in ARIA plus HTML that
it will be hard to explain this even to people who are loosely involved
with web accessibility, much less those who are just getting started
with it. After all, we want people to *use* WAI-ARIA, not be scared off
by its complexity. Or do we? :-)

As a starting point for how complex this already is, let me go back to
James Craig's example:

> > <div role="epub-chapter group" aria-roledescription="chapter"
> id="intro" aria-labelledby="c1h1">
> >         <h1 id="c1h1">Introduction</h1>
> >         <!-- remaining chapter contents -->
> > </div>

VoiceOver on OS X would probably handle this like a grouping of role
"chapter" with the contents of h1 being its title/name. Once you start
interacting with it, you land on the heading itself, then the remaining
chapter content. So already here, you'll hear the label twice: Once as
the label for the chapter grouping, once as the text for the heading.

On Windows, documents like epub would most likely be rendered in some
form of virtual buffer/browse mode document, which has some spoken
semantics embedded. If NVDA, for example, supported aria-roledescription
and would use the string role of chapter and use the label, what I'd
hear is:

"Chapter Introduction" "Heading level 1 Introduction"

So, while I can definitely see the huge benefit of better describing
complex widgets via a custom role description, even this example shows
that the user experience can become less optimal just by having this
chunk of repeated text thrown at you. For cases like Microsoft's ribbon
bars, for example, or complex widgets I've seen in Google Apps, I can
very well imagine this being hugely useful. But those would probably
also be cases where the label would not be immediately repeated.

Again, I think this extension is a great enhancement. But even our own
examples show that the intended improved user experience can be easily
hampered by repeated text. And believe me, as a screen reader user,
repeating text is a huge annoyance. the computer babbles in my ear all
day long anyway, and it then doing so with repeated text is very unpleasant.

And we should also definitely think about failsafe mechanisms. For
example, a role description does not really make sense without an
accompanying role attribute. So if a web developer puts in an
aria-roledescription but no role, aria-roledescription should be ignored.

These my current thoughts on this subject.

--
Marco