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

Rich Schwerdtfeger

James Craig <jcraig@apple.com> wrote on 04/02/2014 01:25:31 PM:

> From: James Craig <jcraig@apple.com>
> To: Joanmarie Diggs <jdiggs@igalia.com>
> Cc: W3C WAI Protocols & Formats <public-pfwg@w3.org>, Alex Piñeiro
> <apinheiro@igalia.com>
> Date: 04/02/2014 01:26 PM
> Subject: Re: ISSUE-636 ACTION-1398 Provide spec. text for
aria-roledescription
>
> On Apr 2, 2014, at 4:01 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote:
>
> > On 04/02/2014 03:25 AM, James Craig wrote:
> >
> > Having said that, it admittedly does absolutely nothing for the other
> > platforms. So I'm thinking the best way forward might be to solve this
> > by a combination of localized role descriptions (target == not-ATK) and
> > UAIG mappings (for ATK).
>
> That's fine. One of the requirements for CR is at least two platform
> mappings, so it's not required that you implement them. That said,
> we know of at least 3 mappings for this in other APIs, so I hope
> you'll come around.
>
> > In some cases I think it should JustWork(tm). Taking your earlier
example,
> >
> >>>> 1. <video> in HTML might default to <video role="group"
> > aria-roledescription="video">
> >
> > For ATK, the role="group" should not be used for the mapping,
preferring
> > instead the more specific ATK_ROLE_VIDEO based on the HTML tag.
>
> That's fair. When there is not a 1:1 role mapping with the host
> language attribute, authors SHOULD NOT specify the role attribute.
>
> > Taking another example you had mentioned:
> >
> >  3. SVG could use <g role="group" aria-roledescription="chart">
> >
> > For ATK, hopefully we could have implementors map it to ATK_ROLE_CHART.
> >
> > If no one objects to that approach, I'm happy to do what needs to be
> > done w.r.t. coming up with a list of ATK-only role mappings we'd find
> > preferable to role descriptions.
>
> <g> is the generic group container in SVG, like <div>. You should
> not give <g> any specific role mapping like this. The approach will
> be to wait for the graphics-related roles that are currently being
> discussed with the SVG group. "chart" will almost certainly be one
> of those, but that list may or may not make it in time for ARIA 1.1.
>
One tweak to this <g> becomes role "group" in SVG but I agree with
everything else you say here.


> > BUT that still leaves at least one noticeable/unmappable area: What
> > happens when there is no non-generic tag AND there is no ARIA role;
just
> > the localized description? Consider this modification of your original
> > video example:
> >
> >    <div role="group" aria-roledescription="video">
> >
> > ATK still wants that mapped as ATK_ROLE_VIDEO, but there's no
> > programmatic way for the user agents to get there from here. Ideas?
>
> ATK should map this as ATK_ROLE_GROUP, not ATK_ROLE_VIDEO.
>
> No platform role mapping should change based on a localized role
> description string. That will need to be a normative requirement in
> the spec. User Agents MUST NOT modify the role mapping based on the
Agreed. this would be unreliable. That would be like reverse engineering.

> localized @aria-roledescription.
> >>> Given an object the screen reader knows is a slide, if the bounds of
a
> >>> focused object on that slide have suddenly changed, this event is
> >>> probably worth passing along to the end user. But, at least in my
> >>> experience, the slide situation is the exception and not the rule:
> >>> Bounds change often but those changes are often of no interest to the
> >>> user and should thus be filtered out by the screen reader.
> >>
> >> I agree that sounds useful, though slightly off-topic.
> >
> > Thank you re useful. :) I don't think it is off-topic. At least for ATK
> > we have existing API through which Orca could:
> >
> > 1. present "slide" as the role AND
> > 2. speak the "hey, you just moved your layout area down 20 pixels"
> >
> > The first it could accomplish by falling back on a localized role
> > description. But the second is not something localized role
descriptions
> > provide. And if you are a user who is blind actively editing slides in
a
> > web app, how useful is it to hear "slide" (which you probably already
> > knew)? In contrast, how useful would it be to hear, "your layout area
is
> > no longer where you want it to be?"
> >
> > Maybe we cannot codify the entire role taxonomy, but perhaps if we have
> > some important usecases we are failing to address now, we can try to
> > turn those into proper ARIA roles for 1.1. That wouldn't mean we
> > couldn't also have localized role descriptions.
>
> No disagreement here. There are lots of missing roles that we need
> to add. I'm just trying to come up with a flexible structure that
> allows accessibility-conscious authors to provide a more
> "understandable" experience (WCAG Guideline 3) when specific roles
> are not provided, or even not *yet* provided. Many of those roles
> will eventually be included in the ARIA spec (some in the 1.1
> version) but some will never be, and in both cases, the ability to
> add a localized role description can help.
>
> James
>
>