Should ARIA 2.0 have a role corresponding to every HTML element?

[richschwer]

We have heard that web components may want this. We need to know if that is in fact an actual requirement that has reached consensus from Web Components as it is a lot of work.

[domenic]

This is crucial for allowing custom elements to achieve the same accessibility capabilities as built-in elements. I don't think it's been discussed to the point where we'd say it's a "consensus requirement", but everyone recognizes that without having this, authors that use web components will likely produce pages with sub-par accessibility.

[annevk]

I'm not sure that every element needs a role, but all those with distinct UI do. However, doesn't ARIA already have more roles than HTML has elements?

[rniwa]

What new roles do we specifically need?

[LJWatson]

@domenic do you see the work you began in HTML as Custom Elements as a logical extension to this?

[LJWatson]

@rniwa I believe @slightlyoff has expressed the thought that having ARIA roles for the complete set of HTML elements would be a good thing.

[LJWatson]

@annevk yes, ARIA has roles that have no HTML equivalent (like tab, tablist and tabpanel for example).

ARIA was originally intended to provide semantics for the (then) emerging webapps that borrowed design patterns from software UIs (toolbars, tabpanels etc.). xHTML was the original host language, but the goal was to provide semantic information that was missing from HTML.

Many ARIA roles do map directly onto HTML elements now though - but not all, and I think that is what @slightlyoff has suggested might be a useful thing to have.

[domenic]

What new roles do we specifically need?

There are a bunch of them. If you go to https://w3c.github.io/aria/html-aam/html-aam.html#html-element-role-mappings, click "View as a single table", there are a bunch of rows with "No corresponding role". Here are the first few interesting ones (i.e. ones that seem to have interesting native correspondences with AT, as shown by the subsequent columns):

• audio
• blockquote
• br ("whitespace" role)
• canvas
• caption
• details

do you see the work you began in HTML as Custom Elements as a logical extension to this?

I'm not sure exactly what this means. The HTML as Custom Elements project was where I first encountered the problem, where if I wanted to do something very simple like create a <custom-p>, there was no way to get accessibility tech to treat my element as a paragraph (i.e. no way to get IA2_ROLE_PARAGRAPH / ATK_ROLE_PARAGRAPH). It certainly makes it clear that without these additional roles, custom elements cannot be said to "explain the platform", because the platform has the ability to tell AT that a given element is a paragraph, whereas author code does not.

[LJWatson]

@domenic "I'm not sure exactly what this means. The HTML as Custom Elements project was where I first encountered the problem, where if I wanted to do something
very simple like create a   , there was no way to get accessibility tech to treat my element as a paragraph (i.e. no way to get  IA2_ROLE_PARAGRAPH 
/  ATK_ROLE_PARAGRAPH ). It certainly makes it clear that without these additional roles, custom elements cannot be said to "explain the platform", because
the platform has the ability to tell AT that a given element is a paragraph, whereas author code does not."

If having a complete ARIA implementation of HTML roles would be useful, and assuming ARIA WG agrees to doing the work, would a logical next step be to bring people together to complete the HTML as Custom Elements as a reference?

[domenic]

If having a complete ARIA implementation of HTML roles would be useful, and assuming ARIA WG agrees to doing the work, would a logical next step be to bring people together to complete the HTML as Custom Elements as a reference?

It might be an interesting project, but it's a large one, and there are several other blockers to getting full parity (see domenic/html-as-custom-elements#27 and other issues under https://github.com/domenic/html-as-custom-elements/issues?q=is%3Aissue+is%3Aopen+label%3Aprimitive for just the things I discovered while working on a very small set of elements; others are summarized on https://domenic.github.io/html-as-custom-elements/, and https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md points out that we also need states, properties, accessible name and description, and some sort of manipulation ability, not just roles).

I'm not sure by what criteria it would be the next logical step---what are we stepping toward?

[richschwer]

@domenic The github.io URL has not been updated. Here is the latest editor's draft of the HTML-AAM: http://rawgit.com/w3c/aria/master/html-aam/html-aam.html

It is true that some elements are not mapped as they provide no value to assistive technologies.

[asurkov]

agree with @annevk. each role and each feature should be carefully considered, discussed, have a use case before it is added to the spec

[cookiecrook]

HTML 1:1 role parity was in the original scope of ARIA 1.1 for this reason. Note: We've pushed back on allowing ARIA to accept roles for functional elements like

[cookiecrook]

So if there is a way to do spec control & query behavior for functional all roles, I'm all for it. e.g.

• video/audio: playback methods, etc.
• input[type=range]: valuechange, query for min/max/step values, etc.

[asurkov]

Could you provide me with references to the native controls methods? I
still didn't catch why it would require ARIA to replicate each and every
HTML elements semantics.

On Mon, Sep 19, 2016 at 5:12 AM, James Craig notifications@github.com
wrote:

HTML 1:1 role parity was in the original scope of ARIA 1.1 for this
reason. Note: We've pushed back on allowing ARIA to accept roles for
functional elements like because there is no way to implement the native
control methods yet.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#552 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABdnqUCPISpUaAYxd4DmbGazJ1vsJ4z4ks5qrlIAgaJpZM4JrYoC
.

[annevk]

Per #729 this is now resolved.

[annevk]

(Well, maybe not fully resolved, but that has pointers to the next step issues for this.)