In the ARIA API mappings meetings everyone was concerned about having role="text" be applied to content other than text as people could put a link in the middle of say a span of text which would be a real problem. The group agreed that the role of "text" should be restricted by the host language to only be used on images for now.

Per the conversation Steve F. and I had please restrict the role of text to only being applied to

“global aria-* attributes and any aria-* attributes applicable to the allowed roles and the link role” or a similar line is seen a few times in the “Rules of ARIA attributes usage by HTML language feature” table.

Would it make sense to change that to something like:

“global aria-* attributes and any aria-* attributes applicable to the implicit or allowed roles”

It has the benefit of being a bit shorter and you don’t have to change it for every different role.

+@handcoding

In the document linked below, the tab role isn't in the list of "ARIA roles, states and properties which MAY be used" with the button "HTML language feature". There is no reason a tab widget can't be implemented accessibly with buttons as the tabs.

https://www.w3.org/TR/html-aria/#docconformance

e.g. should be required on a DIV or LI, but not required on a radio or checkbox where there is a native checked attribute.

Test https://jsfiddle.net/zr2v432h/4/

It seems that the context to create banner and contentinfo landmarks using header and footer elements is quite large.
It seems the only context that header and footer don't create landmarks is when they are a descendant t of an article or section element role=banner.

This leaves header in main, section and many other sectioning elements creating banner and contentinfo landmarks. I think the only time a header or footer element should create a banner or contentinfo landmark is when they are in the context of the body element.

Imported from : https://www.w3.org/Bugs/Public/show_bug.cgi?id=27433 via w3c/html#283

3.2.7.4 Implicit ARIA Semantics [1] currently limits the role attribute on the section element to the following values:

alert, alertdialog, application, contentinfo, dialog, document, log,
main, marquee, region, search, status or presentation

However, the section element [2] could conceivably be used to mark up tabpanel content in a tab widget:

The section element represents a generic section of a document or
application. A section, in this context, is a thematic grouping of content.
Each section should be identified, typically by including a heading
(h1-h6 element) as a child of the section element.

In fact, the non-normative example that follows explicitly makes note of this use case:

Examples of sections would be chapters, the various tabbed pages in a
tabbed dialog box, or the numbered sections of a thesis. A Web site's home
page could be split into sections for an introduction, news items, and
contact information.

Here is a simple example of this use case [3]. This example currently throws a validation error.

Recommend adding 'tabpanel' to list of roles allowed on the section element in 3.2.7.4 Implicit ARIA Semantics [1]

[1] http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics
[2] http://www.w3.org/html/wg/drafts/html/master/sections.html#the-section-element
[3] https://rawgit.com/clrux/html5-tabpanel-test/master/index.html

More of a question of which one should I trust.

Here I'm told the tr element has an implicit role of row and should not set the role.

In the HTML5.1 spec there is no mention of the implicit role (do not apply) on the tr element, implying I should add it to a tr in a grid widget.

This is causing confusion with testing tools like aXe core, which throws a critical error when role="row" is missing on a tr element.

Which is right?

The footer element is NOT be contentinfo landmark when a descendant of aside, article, main, nav and section elements

The header element is NOT be banner landmark when a descendant of aside, article, main, nav and section elements

Observed

On the Aria in HTML web page under section 4 > the Supported Properties column > no hyperlinks in this column redirect to a useful page, instead 404 page is displayed.

Expected

Links should send you to a page that provides more detail for that role.

Steps

1. Go to http://w3c.github.io/html-aria/#index-aria-global
2. Scroll down to section 4. "Allowed ARIA roles, states and properties"
3. Click any link under the Supported Properties column

For many (most?) of the entries in the "Rules of ARIA attributes usage by HTML language feature" table, it's expressly indicated that "global aria-* attributes and any aria-* attributes applicable to the [whatever] role" are permitted.

However, some entries, e.g. input type=text with no list attribute, indicate that only global aria-* attributes are allowed. They don't expressly say that any aria-* attributes applicable to the relevant role(s) are also permitted.

Suggest that all permitted aria-* attributes be expressly indicated for each element as applicable using the "...and any aria-* attributes applicable to the [name of role] role" pattern.

As per the document conformance table, it states:
menu type = context role=menu global aria-* attributes and any aria-* attributes applicable to the toolbar role
The html 5.1 spec states: [https://www.w3.org/TR/html/interactive-elements.html#the-menu-element]
Allowed ARIA role attribute values:
menu (default - do not set), directory, list, listbox, menubar, tablist, tabpanel or tree.
Allowed ARIA state and property attributes:
Please correct the conformance table to reflect the html5.1 spec.

from https://github.com/webspecs/html-aria/issues/23 (now dead)

moved from https://github.com/webspecs/html-aria/issues/13

Seems like option should be allowed on input type checkbox as option elements can be checked and that way you can build an ARIA combobox with checkable items out of native elements.

currently the th [element when being used a col or row header can be overidden by any role, suggest constraining roles when element has scope/headers/sorted/abbr attributes

According to the ARIA spec's section 7.5:

When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.

[...]

Therefore, to prevent providing conflicting states and properties to assistive technologies, host languages MUST explicitly declare where the use of WAI-ARIA attributes on each host language element conflicts with native attributes for that element.

I cannot find any declaration that aria-readonly is in direct semantic conflict with contenteditable. Thus given:

<p contenteditable aria-readonly="true">Edit me!</p>

The text quoted above would suggest user agents are not required to ignore aria-readonly.

Furthermore, at the top of that same section in the ARIA spec, it says:

Except for the cases outlined below, user agents MUST always use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, rather than using the host language semantics.

So unless my paragraph example above is a "case outlined below (in section 7.5)," user agents MUST tell ATs that something which is editable by virtue of the contenteditable attribute is readonly.

Taking a look, the only thing in the "cases outlined below" I'm finding that could be used to prevent user agents from being obligated to convey this conflicting/erroneous information is:

there are elements that are inappropriate to override with WAI-ARIA. This could be because identical host language semantics exist, so WAI-ARIA is not needed, or because semantics from WAI-ARIA directly conflict with host language semantics.

I think the example above falls under the heading of "inappropriate to override ... because semantics from WAI-ARIA directly conflict with host language semantics." But I'm not sure that everyone would agree. See, for instance, this WebKit Layout Test which includes these test cases:

8   <!-- These reflect the native writable state, but can be overridden by @aria-readonly. -->
[...]
10  <div contenteditable id="htmlEditableDiv2" aria-readonly="true" data-expectedwritable="false"></div>
[...]
13  <div role="group" contenteditable id="htmlEditableDiv5" aria-readonly="true" data-expectedwritable="false"></div>

It seems to me that explicitly declaring aria-readonly in direct conflict with contenteditable would ensure that user agents ignore the value of the former attribute for elements which have the latter.

This specification normatively references HTML 5.1:

[HTML51]

Steve Faulkner; Arron Eicholz; Travis Leithead; Alex Danilo. W3C. HTML 5.1. 3 May 2016. W3C Working Draft. URL: http://www.w3.org/TR/html51/

Most of the hyperlinks in this document especially those in Section 3 are directly into the HTML 5.1 specification. For example, "a element with a href" uses references of the http://www.w3.org/TR/html51/semantics.html#the-a-element which link are DIRECTLY to the HTML 5.1 specification.

But there are several occurrences in the document a references to "HTML elements" which use references of the form http://www.w3.org/TR/html/dom.html#elements. These only point to HTML 5.1 since http://www.w3.org/TR/html currently re-directs to HTML 5.1.

Should all the references in this specification point DIRECTLY to HTML 5.1?

moved from https://github.com/webspecs/html-aria/issues/22

ARIA: select and option should allow role overrides of menu and menuitem
moved from https://www.w3.org/Bugs/Public/show_bug.cgi?id=23085

moved from https://github.com/webspecs/html-aria/issues/18

jnurthen commented on 4 Jun

It is very common to base toggle buttons (role=button with aria-pressed set to true/false) and role=switch on an HTML checkbox. This spec forbids this common practice and it should not.
@stevefaulkner
Owner
stevefaulkner commented on 5 Jun

@jnurthen do you have examples you can point me to of the use of checkbox as described?
@jnurthen
jnurthen commented on 5 Jun

As usual not in public space no. Sorry.

https://www.w3.org/TR/html-aria/#input-text

In the section Web developer requirements for use of ARIA in HTML,

http://www.w3.org/TR/html/infrastructure.html#strong-native-semantics
http://www.w3.org/TR/html/infrastructure.html#default-implicit-aria-semantics

these id fragments are missing.

headings are not allowed to be nested in HTML, nor should ARIA equivalents. Their use causes issues with screen readers:
http://www.powermapper.com/tests/screen-readers/headings/aria-role-heading-nested/

https://www.w3.org/TR/wai-aria-1.1/#tablist

https://www.w3.org/TR/html-aria/#docconformance does not list radiogroup as an option for <ul>, nor radio as an option for <li>. Is this an oversight, or deliberate? If the latter, what is the reasoning?

Craig Francis 2015-09-14 10:53:32 UTC

This may have already been discussed (cannot find), but after trying a markup solution by Mike West:

https://mikewest.org/2010/02/an-accessible-pagination-pattern

I received an error that said the

was invalid:

validator/validator#157

Considering that several websites have also used <ul>'s just for navigation, should we support this role on the <ul>?

That said, I realise the <li> inherits a default role of "listitem", and that cannot really be a child of "navigation"... where menubar / menuitem might be more appropriate?

Or adding a wrapping <nav> (which inherits the role="navigation") might be a better solution, as it would allow other lists to be added, and the UA to continue to provide separate landmark and list navigation.

As an aside, I'm going on holiday tomorrow, so might not be able to reply for a couple of weeks.

[tag] [reply] [−] Comment 1 steve faulkner 2015-09-14 11:26:00 UTC

(In reply to Craig Francis from comment #0)

This may have already been discussed (cannot find), but after trying a
markup solution by Mike West:

https://mikewest.org/2010/02/an-accessible-pagination-pattern

I received an error that said the <ul role="navigation"> was invalid:

validator/validator#157

Considering that several websites have also used <ul>'s just for navigation,
should we support this role on the <ul>?

That said, I realise the <li> inherits a default role of "listitem", and
that cannot really be a child of "navigation"... where menubar / menuitem
might be more appropriate?

Or adding a wrapping <nav> (which inherits the role="navigation") might be a
better solution, as it would allow other lists to be added, and the UA to
continue to provide separate landmark and list navigation.

As an aside, I'm going on holiday tomorrow, so might not be able to reply
for a couple of weeks.

Hi Craig,

role=navigation is not allowed (and has never been allowed) on a UL as navigation cannot have listitems as direct children and listitems must have a list or group parent. ARIA roles override the native role semantics. The advice is to wrap a list in <nav> if it is a list of navigation items. It does not work correctly across browsers or AT. In order for this to work interoperably it would require changes to the definitions and implementation requirements of role=navigation and the HTML <nav> element.

In table: "Rules of Accessible Rich Internet Applications attributes usage by HTML language feature"

For row: "a element with a href"
The allowed roles are: button, checkbox, menuitem, menuitemcheckbox, menuitemradio, radio, tab, switch, or treeitem

Is role option intentionally left out? If so, why?

It's not clear from the spec what happens if any of the following are specified

<img alt=“A vital image” role=“presentation” src=“1.png” />
<img alt=“” arial-label=“A vital image” src=“1.png” />
<img aria-label=“A vital image” role=“presentation” src=“1.png” />
<img alt=“” title=“A vital image” src=“1.png” />

Author intent is unclear in this markup since it's both presentational and has an accessible name. About 50% of AT combos treat it this as presentational and ignore it, the other 50% read the accessible name.

There is no issue with adding role=search on

See w3c/wcag#113

Bug 25980
Summary: WAI-ARIA: Default implied semantic table indicates role of radio cannot be used with anchor
Product: HTML WG Reporter: Jonathan Avila [email protected]
Component: HTML5 spec Assignee: steve faulkner [email protected]
Status: NEW --- QA Contact: HTML WG Bugzilla archive list [email protected]
Severity: normal

Priority: P2 CC: [email protected], [email protected], [email protected], [email protected], [email protected]
Version: unspecified Keywords: a11y
Target Milestone: ---

Hardware: PC

OS: Windows NT

Whiteboard:

Description Jonathan Avila 2014-06-04 18:46:06 UTC

The nightly build http://www.w3.org/html/wg/drafts/html/master/dom.html#wai-aria indicates in the default implied semantics table that the ARIA radio role can't be used with the anchor element. Checkbox and menuitemradio as well as menuitemcheckbox are included so I believe this was an accidental omission.

Comment 1 steve faulkner 2014-06-04 18:57:55 UTC

have moved to html spec as that is where the mappings are defined

Comment 2 Jonathan Avila 2014-06-04 19:01:50 UTC

Role of option also seems like a good candidate for mapping to the anchor element.

categorise roles in relation to HTML content https://w3c.github.io/html/dom.html#kinds-of-content so nesting of some elements not allowed:

example this is not allowed in HTML:

<a href="#">
<a href="#"></a>
</a>

so don't allow

<span role="link">
<span role="link"></span>
</span>

• define kinds of content for each role - started abdf1ad
• define new kind of content "document region" for HTML5
• define descendant content restrictions for roles

If there are outstanding bugs in Bugzilla for this module, it would be good to close Bugzilla to new bugs and migrate the rest over here.

Currently the document indicates you can have a button with type menu (which indicates a menu is present) on controls like a checkbox and radio button. This seems problematic because there are two actions associated with the control -- change the checked state and activate the menu.

@stevefaulkner mentioned on twitter that he believes <input type=checkbox checked aria-checked=false /> should output a checkbox[checked=true] in the accessibility tree.

The argument is rooted in the following three pieces of text from wai-aria:

Except for the cases outlined below, user agents MUST always use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, rather than using the host language semantics.

and

Host languages MAY document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics").

or

When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.

As far as I can tell, none of two exceptions apply in this case, however.

As we can see in the following table from HTML-ARIA, aria-checked is allowed on a checkbox (second column lists implied things, the third list the other allowed things):

And there is no host attribute that share the same semantic as aria-checked. The "checked" attribute means "defaultChecked" which is the value of the checkbox is the user never interacted with it. Click on the textbox once (or set its value via javascript) and the checked attribute can now be added, removed, changed without any impact on the checkbox. As a result, it is not a candidate for the "prefer html attribute over aria if they are identical" exception.

So, we are left with aria-checked > intrinsic semantics, which is what Edge is doing.

Please note that this does not apply to other attributes like "readonly" which does have an aria exception stated in the spec. There is also an exception for "required" but I think the spec is unintentionally misleading in this case.

What do you think?
@cyns?

moved from https://github.com/webspecs/html-aria/issues/2

For each element in the first table in the #docconformance section, each element/row listed should have an anchor so that each can be referenced directly; e.g.:
https://specs.webplatform.org/html-aria/webspecs/master/#a-href-element or https://specs.webplatform.org/html-aria/webspecs/master/#picture-element etc.

For each element in the second table in the #docconformance section, each role/row listed should have an anchor so that each can be referenced directly; e.g.:
https://specs.webplatform.org/html-aria/webspecs/master/#alert-role or https://specs.webplatform.org/html-aria/webspecs/master/#grid-role etc.

Also, I propose that we:

Retitle the first section "Per-element document-conformance requirements"
Make that "Per-element" section contain only the first table.
Move the second table to its own section, titled "Per-role document-conformance requirements"
Make it clear the second table is actually normative (which as far as I can see it is, even though it's restating normative requirements from ARIA).

For the "Per-element" section, add an in introductory paragraph like:

The following table provides normative per-element document-conformance requirements for the use of ARIA markup in HTML documents.

For the "Per-role" section, add an in introductory paragraph something like:

To provide convenient access for readers of this specification to all relevant ARIA requirements, the following table re-states specific normative per-role document-conformance requirements from [wai-aria] for the use of states and properties in ARIA markup.

Further I suggest considering that the markup of both tables be done in such a way that the per-element and per-role lists appear in the spec's table of contents; for example:

1. Table of Contents
   …
2. Per-element document-conformance requirements
   2.1 All elements
   2.2. a element with a href
   2.3 address
   …
3. Per-element document-conformance requirements
   3.1 Any role
   3.2 alert
   3.3 alterdialog
   …

If buttons can be come menuitems seems like the could also be option elements.

Could we put all of the inline CSS into a .css file? Just to clean up the <head> a bit.

Section 2 talks about the following table. Then there is a note. Then section 3, which talks about the following table. It looks to me like the two sections are really one, talking about the same table, but in any event it is extremely confusing.

need to add

From ARIA issue 451 raised by @fstorr.

meter has semantics distinct from the progress element or progressbar role. The HTML-AAM specifies no corresponding role for meter.

https://w3c.github.io/html-aria/#docconformance

In the "a element with a href" row, the 3rd column lists the following:
Roles: button, checkbox, menuitem, menuitemcheckbox, menuitemradio, radio, tab, switch - (new)or treeitem

Switch should come after radio and before tab. :)

The current entry for combobox should be updated to align with whats in ARIA 1.1, where combobox has aria-controls and aria-expanded as required properties, and aria-autocomplete, aria-readonly, and aria-required as supported properties.

I noticed this problem when working on Axe. Elements with a role of combobox are required to own two elements: listbox and textbox. (https://www.w3.org/TR/wai-aria-1.1/#combobox). Though if you look at the example of the combobox, there is no element with a textbox role. Instead a type=text input element is given the role=combobox. How exactly should this be implemented? Should the example in this case also contain a textbox?

The HTML 5 spec does not allow a required attribute on a fieldset element.

The HTML 5 spec allows a required attribute on a input of type radio

The ARIA spec does not allow aria-required="true" on a radio role

The ARIA spec does allow aria-required on a group role

This makes it difficult for developers to grok the mapping between HTML and ARIA.

With the understanding that ARIA is intended to be bigger than just HTML, is there any good reason for this discrepancy?

Assuming there needs to be, is there a test harness for this module yet?

original bug:https://www.w3.org/Bugs/Public/show_bug.cgi?id=24272

Please reconsider the possible ARIA roles for area elements that forms hyperlinks.

Area elements that create hyperlinks are currently placed in the strong native ARIA semantics table and is thereby only allowed to have a single role - the link role.

By contrast, anchor elements that create hyperlinks are placed in the table over the weak native ARIA semantics table and can take a number of roles: “If specified, role must be one of the following: link, button, checkbox, menuitem, menuitemcheckbox,menuitemradio, tab, or treeitem”.

However, as a matter of fact, an area elements area always linked to graphics of some sort. So e.g. they can for instance be attached to an area of an image that has the shape of a button.

So at the very least, it should be able to take the button role as well. But please consider if it may take even more role. E.g. a button may occur in navigation menus, so perhaps menuitem role should be considered as well. Tab role also seems like a possibility. And perhaps others.

Currently it specifies it as "no corresponding role", but this is inaccurate

https://www.w3.org/TR/html-aria/#span

Based on discussion in the ARIA working group on 12/8//2016 and 12/15/2016 we would like to see the mapping for the DT element changed from LISTITEM to TERM.

NOTE: ARIA 1.2 will address the roles TERM and DEFINITION being part of a definition list.

The whole point of aria-invalid is to allow authors to specify that elements are not valid to accessibility APIs. The ARIA in HTML document seems to disallow this usage.

Custom validation logic often requires things that we either cannot do in HTML5, or where browser behaviour in HTML5 is not consistent. UX designers often require consistent behaviour across browsers.