w3c / html-aria Goto Github PK
View Code? Open in Web Editor NEWARIA in HTML
Home Page: https://w3c.github.io/html-aria/
License: Other
ARIA in HTML
Home Page: https://w3c.github.io/html-aria/
License: Other
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.
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
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: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.
Could we put all of the inline CSS into a .css file? Just to clean up the <head>
a bit.
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
.
@stevefaulkner mentioned on twitter that he believes <input type=checkbox checked aria-checked=false />
should output a checkbox[checked=true]
in the accessibility tree.
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 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.
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?
from https://github.com/webspecs/html-aria/issues/23 (now dead)
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.
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
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. :)
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/
Assuming there needs to be, is there a test harness for this module yet?
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?
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?
need to add
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.
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.
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.
Links should send you to a page that provides more detail for that role.
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>
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
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.
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.
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.
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.
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
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.
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:
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.
If buttons can be come menuitems seems like the could also be option elements.
Currently it specifies it as "no corresponding role", but this is inaccurate
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?
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?
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.
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.
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
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.
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.
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.
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.
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.
“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.
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?
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
There is no issue with adding role=search on
elements. Form has no semantics for accessibility so adding a search on it seems entirely natural. The ARIA group seems to agree with this.See w3c/wcag#113
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.