Re: [w3c/aria] SVG-AAM: Identify elements which support aria-roledescription without an explicit or implicit role (#599)

Well it‘s all about how the roledescription mapping will be done in the API‘s. If it overrides the default role string than this will be a problem, I agree.

If it will be just supplementary and be mapped using a role string concatenation I don‘t see a big issue. It would be a major design flaw if the ARIA APG only allows for first option when using aria-roledescription which seems not to be the case across platforms currently.

Looking at APG, for MSAA we have

Method: localizedExtendedRole(): <value>

To query for extended role whereas UIAutomation directly maps to Localized Control Type with unclear outcome if result will be a concatenation or just overrides base role string.

Regards, Stefan



Von meinem iPad gesendet

Am 31.01.2018 um 18:28 schrieb Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>:

Sounds good to me too.

It concerns me that many of these examples are being used to represent a supplementary description of a role, where this is not actually what the attribute does according to the spec. This attribute is supposed to replace the role and suppress it and use the aria-roledescription value in place of the role, not to convey both the role and the aria-roledescription at the same time.

This confusion is going to lead to major accessibility issues down the road with common usage patterns.


Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Wednesday, January 31, 2018 12:41 AM
To: Joanmarie Diggs (jdiggs@igalia.com<mailto:jdiggs@igalia.com>) <jdiggs@igalia.com<mailto:jdiggs@igalia.com>>; ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: [w3c/aria] SVG-AAM: Identify elements which support aria-roledescription without an explicit or implicit role (#599)

@Joanie: I’d like to have this on the agenda for one of the next group meetings.

>>> Authors SHOULD limit use of aria-roledescription to clarifying the purpose of non-interactive container roles like group or region, or to providing a more specific description of a widget.
I want to elaborate on the allowed space of concrete examples using standard ARIA and host roles for that in ARIA 1.2.  SVG is just one possible extension scenario.

The original formulation was born as result of fears having code like

<span role=”button” aria-roledescription=”my fancy stuff trigger”>..

which may bomb the native “button” speak of screen readers. This was maybe based on the assumption that authors will do wired things with the roledescription. But these authoring errors are always possible, even for role assignments. (You can perfectly declare a label called “Button” etc.).

I do see still great usage in specialization descriptions for that property. For example, we have in the same UI a slider role but also a rating indicator role which is an editable, interactive slider but comes with an entirely different visualization. Code like

<div role=”slider” >..
..
<div role=”slider” aria-roledescription=”Rating Indicator”>..

Would make the difference clear without additional need for aria labelling (or describing) which isn’t originally intended at all to describe specialized roles. Aria-roledescription IS THAT and should be therefore allowed to be used like this and the examples in the 1.2 spec should reflect this.

Another example is the presence of a tokenizer in an input that contains multiple tokens that represent entire separate objects (like the “To:” field in outlook)

Syntax like

<input type=”text” aria-roledescription=”Contains Tokens”>

will inform potential users that this is not an ordinary input. Different keyboard navigation and subtoken focusing inside awaits the user and the roledescription informs him that this is going to happen.

Another example (there are really MANY in real life apps) there is

<h2 id="idProducts"> Products </h2>

<ul role="listbox" aria-labelledby="idProducts">

  <li role="option" aria-roledescription=”Full Product Info” aria-setsize="16" aria-posinset="5"> …

Where the content of the li with role option is not just a small toy code string but a full monty of images, status indicators, custom flag indicators etc. etc. and the roledescription just says that.

We should also deliver “forbidden” examples (as part of the APG) to make crystal clear what the group considers to be an authoring error. We should not leave this field entirely to the HTML validators documentation.


  *   Stefan


From: Amelia Bellamy-Royds [mailto:notifications@github.com]
Sent: Wednesday, January 31, 2018 1:44 AM
To: w3c/aria <aria@noreply.github.com<mailto:aria@noreply.github.com>>
Cc: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Comment <comment@noreply.github.com<mailto:comment@noreply.github.com>>
Subject: Re: [w3c/aria] SVG-AAM: Identify elements which support aria-roledescription without an explicit or implicit role (#599)


@accdc<https://github.com/accdc>

That seems to be a separate issue from the concern Joanie raised, and should be dealt with in the core ARIA spec. For reference, the current definition of aria-roledescription in that spec<http://w3c.github.io/aria/#aria-roledescription> says:

Authors SHOULD limit use of aria-roledescription to clarifying the purpose of non-interactive container roles like group or region, or to providing a more specific description of a widget.

But to answer your question: You can add interactive roles to SVG elements, but the only element with a native interactive role is the link.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/w3c/aria/issues/599#issuecomment-361784672>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AZep7v3QNJHvkuXpW6oc3xgH23SWQkL5ks5tP7dfgaJpZM4OOkWT>.<image001.jpg>