Blocked on the mappings being sorted out and landed in HTML-AAM.
w3c/html-aam#141

The General rules for exposing WAI-ARIA semantics section lists steps for creating the accessibility tree.

For the following in step 5:

In instances where the host language elements support CSS display:none, the element is not focusable even if it has tabindex="0" since there is nothing rendered on screen to focus, and users cannot interact with the element. The tabindex attribute is ignored, and the element is excluded.

Should this also include HTML hidden (and possibly CSS visibility: hidden) and not just CSS display: none?

Contrary to what the ARIA spec used to suggest, platform accessibility APIs may indeed have a vehicle to notify assistive technologies that a role has changed. For instance, in ATK there are property-change signals. And one of the properties which can change happens to be accessible-role.

Core AAM already has a bunch of tables outlining platform-specific events/notifications which should be emitted when something changes. For some reason, role isn't there. It should be.

During today's face-to-face meeting we discussed the possibility of placing aria-expanded on the text input rather than on the object with role combobox. Text inputs are not traditionally expandable themselves so assistive technologies may need to adjust where they look for this state.

An additional change may be needed for UIA because unlike other platforms, "expandable" is not a state that can be applied to any object; there is an ExpandCollapse ControlPattern whose documentation states the following:

Aggregate controls—built with child objects that provide the UI with expand/collapse functionality—must support the ExpandCollapsePattern control pattern whereas their child elements do not. For example, a combo box control is built with a combination of list box, button, and edit controls, but it is only the parent combo box that must support the ExpandCollapsePattern.

Note

An exception is the menu control, which is an aggregate of individual MenuItem objects. The MenuItem objects can support the ExpandCollapsePattern control pattern, but the parent Menu control cannot. A similar exception applies to the Tree and Tree Item controls.

In other words, as I understand it, if authors place aria-expanded on the text input, the expandable nature and state will be lost for UIA implementations.

That said, I believe it will be easy for implementations (including Blink) to catch this condition, ascend the accessibility tree and/or check for aria-owns, and if they find an element with role combobox, expose aria-expanded on that ancestor/owner of the text input.

Assuming I am correct, we will need to do two things:

1. Update Core-AAM to reflect the need for implementations to do this work
2. File bugs against implementations and make the change

@melanierichards: I'm going to assign this to you to check with your colleagues about my theory and, assuming I'm indeed correct, to provide a pull request with the appropriate language for your platform. Thanks in advance!

We currently have the scenario in which one user agent (Safari) is following what's in the Core-AAM, e.g. for deletion:

AXRole: AXGroup
AXSubrole: AXDeleteStyleGroup
AXRoleDescription: 'group'

And another (Chrome) is following it for AXRole and AXSubrole, but providing a more specific AXRoleDescription:

AXRole: AXGroup
AXSubrole: AXDeleteStyleGroup
AXRoleDescription: 'deletion'

I've been discussing this matter with Apple and Google. A resolution is in progress. Once the resolution has been finalized, we'll need to update Core-AAM accordingly.

Section https://w3c.github.io/core-aam/#mapping_additional_position States

"Otherwise, if the role supports aria-posinset and aria-setsize, process the parent (DOM parent or parent defined by aria-owns), counting items that have the same role."

This is not correct. A menu should count all the menu items no matter the type (menuitem, menuitemcheckbox, menuitemradio) not just items of the same role

The DOM tree as implemented in the latest browsers is considerably more complex than it was a few years ago.

The Core-AAM guidelines on constructing the accessibility tree should be written to clarify that they operate on the "flattened tree" (a term which seems to be no longer defined in the WHATWG DOM standard, but meaning the hierarchy of elements that are used as the input to rendering, regardless of their official DOM parent-child relationships).

A more complicated issue is how to handle IDREFs in ARIA attributes. IDs are not unique across shadow trees, and you can't easily query shadow tree IDs from the main document.

The SVG-AAM currently contains the following guidelines about ARIA IDREFs in the context of SVG use shadow trees:

SVG user agents MUST process the element instances generated for the use-element shadow tree as if those elements were children of the use element itself, with the following conditions:

• When processing WAI-ARIA attributes on elements within a shadow tree, the user agent MUST first attempt to match any IDREF values against other elements in the same shadow tree, before searching for a match in the host's node tree. If shadow trees are nested, the user agent MUST recursively search from the current shadow tree to the tree containing its host use element, until the document tree is reached.

• In all other cases, when matching IDREF values in WAI-ARIA attributes, the user agent MUST NOT consider elements in the shadow tree of a use element.

I would prefer to harmonize this guidance with general rules for ARIA and shadow DOM (and there is an issue in the SVG-AAM to that effect).

https://w3c.github.io/core-aam/#accessible-names-and-descriptions

Update "How these the relevant properties are implemented and what they are called vary depending on the API"

to

"How these relevant properties are implemented and what they are called vary depending on the API"

https://w3c.github.io/core-aam/#roleMappingGeneralRules is largely independent of platform accessibility APIs. We should move the platform-agnostic content to the ARIA spec.

While working on the implementation in Chrome(ium), we discovered an oddity which suggests the mapping for MSAA for subscript and superscript wasn't quite right, namely: You wind up with ROLE_SYSTEM_TEXT (the subscript/superscript role) containing a child of ROLE_SYSTEM_TEXT (the static text). For example:

<h1>This text is <span role="subscript">lowered</span>.</h1>

ROLE_SYSTEM_HEADING
   ROLE_SYSTEM_TEXT "This text is "
   ROLE_SYSTEM_TEXT (subscript)
     ROLE_SYSTEM_TEXT "lowered"
   ROLE_SYSTEM_TEXT "."

Dominic Mazzoni stated that when they are used as ARIA roles they're always going to be on a grouping element and therefore wonders if the GROUPING role might make more sense.

I therefore followed up with @jcsteh. Here's what he stated:

TL;DR: There's no "good" answer for the MSAA role. I guess ROLE_SYSTEM_GROUPING will do. IA2_ROLE_TEXT_FRAME should stay as is. I think it makes sense for the HTML and Core AAMs to be consistent on this.

From what I can see, Chrome uses ROLE_SYSTEM_STATICTEXT (not ROLE_SYSTEM_TEXT) for text leaf accessibles. Even so, I'd rather we didn't use ROLE_SYSTEM_TEXT for anything other than editable text, as MSAA (kinda) suggests this is for navigable text:

The object represents selectable text that allows edits or is designated as read-only.

(Firefox still uses ROLE_SYSTEM_TEXT for text leaf accessibles, but that's somewhat of a historical wart.)

I don't really consider divs and spans to be semantic groupings; i.e. they're not semantically useful like role="group". I've always felt ROLE_SYSTEM_GROUPING was more for semantic groupings.

That said, there isn't really a generic role that fits here. ROLE_SYSTEM_STATICTEXT suggests a text leaf, which is not ideal. So I guess ROLE_SYSTEM_GROUPING will do.

At the end of the day, anyone doing anything serious with a web browser will use IA2 (not just MSAA), in which case the IA2 role overrides. So I don't really care very much about the MSAA role. :)

Therefore, we're going to make this change.

Add mark, comment, suggestion.
For comment, support comment level, setsize, posinset.

The Introduction talks about UAIG and refers to this spec as a "guide." It also mentions content (like error handling) that have since been moved to ARIA. It needs a rewrite and some pruning.

The precedence order is:
aria-describedby
aria-description

The ARIA Editor's Draft now contains roles for:

• associationlist (corresponds to HTML dl)
• associationlistitemkey (corresponds to HTML dt)
• associationlistitemvalue (corresponds to HTML dd)

Looking at the HTML-AAM, it currently has the following mappings:

• dl - No corresponding role. Do the dl mappings make sense for associationlist?
• dt - term ARIA role. It's my assumption that this will change in HTML-AAM. What should the platform mappings be for Core-AAM?
• dd - definition ARIA role. It's my assumption that this too will change in the HTML-AAM. What should the platform mappings be for Core-AAM?

From https://www.w3.org/WAI/ARIA/track/issues/481

Section 5.8.2 of the UAIG includes the following paragraph with a SHOULD. Consider changing to MUST.

User agents SHOULD ensure that an assistive technology, running in process can receive notification of a node being removed prior to removal. This allows an assistive technology, such as a screen reader, to refer back to the corresponding DOM node being deleted. This is important for live regions where removals are important. For example, a screen reader would want to notify a user that another user has left a chat room. The event in MSAA would be EVENT_OBJECT_HIDE. For ATK/AT-SPI this would be children_changed::remove. And in Mac OS X, the event is AXLiveRegionChanged. This also requires the user agent to provide a unique ID in the accessibility API notification identifying the unique node being removed.

reverese relations section refers to not existing aria-described property [1], should be aria-describedby

[1] https://w3c.github.io/core-aam/#mapping_additional_relations_reverse_relations

I think users should be able to get a combined view of mapping between APIs, WAI-ARIA, and HTML.

Should Section 5.4.2 Role Mapping Table include the HTML element mapping similar to Section 4.4 Mappings of HTML elements to platform accessibility APIs table?

A much larger and extensive effort could be to map the support provided by user agents and AT vendors for those elements.

Then there is just one big (filterable) table that everyone can refer to for latest 'official' updates.

IA2 provides specific roles for banner and contentinfo role, i.e. IA2_ROLE_HEADER and IA2_ROLE_FOOTER correspondingly, which should be used instead more generic IA2_ROLE_LANDMARK.

See issue w3c/html-aam#133 for details.

w3c/aria#761 added blockquote, caption, and paragraph roles as part of role parity with HTML. We need mappings.

There is a proposal to add a specific role to IA2 for blockquotes. See LinuxA11y/IAccessible2#6. When this is in place, we'll want to update the relevant mappings in Core AAM.

The "ID Reference Error Processing" section states:

If the same element is specified multiple times in a single WAI-ARIA relation, user agents SHOULD return multiple pointers to the same object.

Why? As a screen-reader developer, I can see no benefit to having multiple targets in an accessible relation pointing to the same object. Anyone else think this is a good idea? If not, I propose we remove this statement.

@asurkov, @melanierichards, @cookiecrook, @aleventhal: Thoughts?

Something has gone wrong with the script that generates the role mapping table/accordion section, so that all the id values are being set to undefined.

This breaks all links in to the document that point to a specific role entry, which is a problem when we're trying to republish SVG-AAM (w3c/svg-aam#3).

Is anyone able to look at this?

In my opinion there should be no different role for buttons with aria-haspopup (currently MSAA + IAccessible2: "ROLE_SYSTEM_BUTTONMENU" instead of "ROLE_SYSTEM_PUSHBUTTON").

reasons:

1. aria-haspopup can also be located on other elements (e.g. links) and does not cause any other role.
2. aria-haspopup at button does not automatically mean that it is a button with menu (listbox, tree, grid, dialog)
3. in the screenreader (e.g. JAWS, version 13 - 2019) the specification leads to an erroneous output as "button menu" with various consequential errors (e.g. in IE 11: no output of aria-roledescription, aria-expanded, change to form mode, no output as "menu", if aria-pressed at button etc.; the problems also occur partially with Chrome and Firefox, only Edge ignores the specification and always outputs buttons correctly as buttons), see: FreedomScientific/standards-support#211

In a bug filed on the JAWS tracker: JAWS treats menu items after a separator as a different menu group It was reported that use of a separator in a menu resulted in JAWS (and NVDA) treating the menu items before and after the separator as separate sets. in investigating this I found that it was not an issue with JAWS, but an effect that use of separator has in Firefox (posinset and setsize properties indicate 2 sets of 4 in the test case). This is not reflected in the Chrome implementation or reportedly in Safari.

Is the Firefox behaviour correct?

https://w3c.github.io/core-aam/#features-deprecated-in-wai-aria

Consider the sentence "The WAI-ARIA specification lists some features as deprecated..." -- Should the target page contain the list of deprecated features?

These are the ARIA changes. Need to determine what needs to change in Core AAM.

For issue #797, allow empty spin buttons by:

• Changing aria-valuenow to supported from required property.
• Changing prose to author SHOULD from author MUST specify value for aria-valuenow.
• Adding aria-valuetext as supported property.

For issue #642, allow min and max to be undefined:

• Change aria-valuemin and aria-valuemax from required to supported properties.
• Revise prose of paragraph with normative statements.

For issue #812:

• Change description to clearly state that a text field with sibling buttons outside the spinbutton is permitted.
• Related editorial change to consolidate keyboard requirements into a single paragraph.
• Other related editorial revisions for clarity.

The current mapping for aria-hidden=false is "not mapped" and I mistakenly assumed that not mapped was equal to no effect in this case, up until recently; when I became aware of the chrome behavior whereby if an element has CSS display:none set and also has aria-hidden=false then the element is exposed to screen reader users and if interactive can be operated. I created a test case and filed a bug on chrome as its behavior is different from Firefox (which does not expose the element in this case) and I thought that it was decided by implementors previously that aria-hidden=false should have no effect.
Whatever is decided it would be good to have clarity over what aria-hidden=false does and how it should therefore be implemented.

In looking at the particular test case I found that using it on interactive elements in this way (visibly hidden but enabled/available to SR users) causes a number of potential issues that map to WCAG criteria:

• 1.3.1 Info and Relationships
• 2.4.7 Focus Visible

And if so we need to think about whether we want to enshrine WCAG failures in the implementation of this attribute.

https://w3c.github.io/core-aam/#mapping_general

In addtion, some host markup langauges elements have no semantics and are excluded from the accessibility tree.

to

"In addition, some host markup languages elements have no semantics and are excluded from the accessibility tree."

https://www.w3.org/TR/core-aam-1.1/#intro -- para 6.

It is not clear what 'User Agent Implementation Guide' refers to.

"For an introduction to WAI-ARIA, see the WAI-ARIA Overview. The User Agent Implementation Guide describes how WAI-ARIA roles, states, and ..."

The following table reflects the event mapping currently in the Core AAM for UIA. I noticed some inconsistencies in how things are written and would like a review of the current values and corrections if needed.

My questions:

1. Several of the ARIA state/properties are mapped to "PropertyChangedEvent". Should the specific property be included in the mapping? As an example from ATK/AT-SPI2: if aria-busy changes, the event is object:state-changed:busy but if aria-checked changes, the event is object:state-changed:checked.
2. aria-checked and aria-valuenow are written as $PROPERTY property change as part of $PATTERN pattern. Are these property change events the same thing as PropertyChangedEvent, but written differently? Or are they totally different API?
3. aria-expanded mentions "expand/collapse pattern events". Should we specify these by name/type?
4. Are all the "No event" instances correct?

From @joanmarie on July 25, 2017 10:46

The Core AAM currently states the following for objects which have selection amongst their properties (e.g. grid):

Implement Methods IAccessible::accSelect() and IAccessible::get_accSelection()

The problem (imho) with that statement is with the first method to be implemented. According to the documentation I've found:

The IAccessible::accSelect method modifies the selection or moves the keyboard focus of the specified object. All objects that support selection or receive the keyboard focus must support this method.

But we've not stated how to implement it. And how to do so is not (necessarily) as obvious as implementing the getter methods of an interface:

1. If the user agent modifies the value of aria-selected in response to a call to IAccessible::accSelect():
   1. It will not reliably modify the selection as expected because the author of the ARIA 1.x web app has no obligation to be watching for property changes made by the user agent and updating the web app's selection accordingly. That is anticipated to change in ARIA 2.x with the addition of support for setting properties via platform accessibility APIs, but that is not currently in place.
   2. It may result in the platform AT reporting invalid information to the user. For instance, a reasonable way to implement support for the platform's accessibility API to get the current selection would be to return the elements for which the value of aria-selected is true. If the user agent has modified the value of that property, the results returned would not jive with the web app's state.
2. Because focus can be independent of selection, we don't want user agents implementing support via grabbing focus on the element(s) in question.

Looking at the aforementioned documentation, it says the following about the return value:

Type: HRESULT
If successful, returns S_OK.
If not successful, returns one of the values in the table that follows, or another standard COM error code.

S_FALSE: The specified object is not selected.

E_INVALIDARG: An argument is not valid. This return value means that the specified SELFLAG combination is not valid, or that the SELFLAG value does not make sense for the specified object. For example, the following flags are not allowed on a single-selection list box: SELFLAG_EXTENDSELECTION, SELFLAG_ADDSELECTION, and SELFLAG_REMOVESELECTION.

DISP_E_MEMBERNOTFOUND: The object does not support this method.

Given those choices, I would think the desired return value would be S_FALSE. I don't think it makes much sense to ask user agents to sanity check arguments for validity given the expected implementation is (currently) a no-op. And the third value could be interpreted to mean that the grid (or whatever) element in the web app doesn't support selection, which isn't the case: What is not (currently) supported is changing the selection via IAccessible::accSelect().

If everyone agrees, then perhaps what is called for is a note similar to what we have for ATK:

ATK:

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents must return false for all Selection methods that provide a means to modify the selection.

Proposal for MSAA/IA2:

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents must return S_FALSE for IAccessible::accSelect()

Comments?

Copied from original issue: w3c/aria#612

Refer to the following sentence in 3rd para, section 1.1

To interact with static Web content, assistive technologies, such as screen readers, have tended to rely on the DOM provided by the user agent.

With static web content, do modern screen readers (JAWS 18 / 2018 / NVDA 2018 etc.) still tend to rely on the DOM provided by the user agent?

The rules regarding tree inclusion and exclusion are platform independent and have nothing to do with accessibility API mappings. Furthermore, we wouldn't want those rules, which are important, missed because they are not in the ARIA spec. If w3c/aria#792 is approved, we should remove the redundant content from Core AAM

The CORE-AAM section on Relations requires that assistive technologies SHOULD provide a method to navigate to (and within) structured content referenced by aria-describedby.

Note that aria-describedby may reference structured or interactive information where users would want to be able to navigate to different sections of content. User agents MAY provide a way for the user to navigate to structured information referenced by aria-describedby and assistive technology SHOULD provide such a method.

What happens when the element referenced by aria-describedby is hidden? In that case, the user agent is supposed to compile the hidden element's plain text as part of the referencing element's accessible description, but the hidden element is not directly included in the accessibility tree. So there is nothing for assistive tech to navigate to.

Is that acceptable? If so, the quoted passage above should be qualified to say "if the referenced element is not hidden" or "if the referenced element is included in the accessibility tree".

If we instead want to support access to structured descriptions even if they are hidden, then the rules for including elements in the accessibility tree need to change.

(I'm converting SVG-AAM spec issues into GitHub issues, and this was one of them, because SVG <desc> is a hidden description that we don't currently include in the accessibility tree.)

The Core AAM currently has the following non-normative, non-mapping content in its introduction:

• An introduction to what accessibility APIs are. If you don't know the answer to that, you are not the intended audience of the Core AAM.
• A paragraph on the Accessibility Tree versus the DOM Tree. Again, if you don't know the difference, you are not the intended audience of the Core AAM.
• A comparison of accessibility APIs. Interesting stuff, but as an implementor your primary concern is doing the implementations. I would argue that you can happily do so from the normative content (and mainly the tables) without ever having to read that section.
• An introduction to accessible names and descriptions. More interesting stuff, but why (for instance) does a user agent implementor of ATK need to know that the way Linux ATs such as Orca get the name and description is via atspi_accessible_get_name() and atspi_accessible_get_description() respectively? User agents aren't doing that work. And screen reader developers aren't reading the Core AAM to figure out how to get properties. They have API docs for that. Plus, even if the web didn't exist, they'd still have to get name, description, states, properties, roles, and the like.

I don't want to delete this content as it is informative and it is clear that multiple people worked hard to produce it. By the same token, I think it adds noise to the Core AAM. Making the Core AAM leaner so that its intended audience can quickly and easily locate what they need to know and do strikes me as beneficial to all stakeholders. So where can we put it? I privately tossed out the possibility of a Note-track document. Michael responded that perhaps an Explainer would be appropriate. I'm good with the latter.

Thoughts?

The content related to supporting keyboard navigation is platform independent and has nothing to do with accessibility API mappings. Furthermore, we wouldn't want that content missed because it is not in the ARIA spec. If w3c/aria#793 is approved, we should remove the redundant content from Core AAM.

General rules for exposing WAI-ARIA semantics lists (e.g., controller-for) in the following:

A DOM element is included if it has semantic significance. As a first approximation, it is significant if it has an explicit or implicit WAI-ARIA role, state, or property, is focusable or interactive, or bears a relationship with some other element (e.g., controller-for).

Reasons I think controller-for is a poor example:

1. The controller-for/controlled-by relationship is an old concept and seems to be gone from the documentation, so it would be unfamiliar to new authors, and RELATION_CONTROLLER_FOR / RELATION_CONTROLLED_BY is used by some, but not all, platform accessibility UIs.
2. The element that is a controller-for is quite likely to be interactive already. It is the controlled-by element that might need to be added to the accessibility tree based only on the relationship giving it semantic significance.

I think a more understandable example would be:

(e.g., the element referenced by aria-controls)

According to the gridcell's specs,

A gridcell may be [...] selectable.

For single-selection containers, the ARIA specification about aria-selected says:

The selection normally follows the focus [...].

With the current implementation in Chromium, the selection follows the focus for a gridcell by default. However, in Firefox and Edge (the legacy one), the implementation makes no such assumption about a link unifying the two states.

I believe that Chromium engineers interpreted the a gridcell may be selectable as a a gridcell has an implicit aria-selected value of true or false, i.e. is always selected when they initially implemented the feature. My opinion is that the selection should not follow the focus for a gridcell and, even more, a gridcell should not have an implicit aria-selected value of true or false.

After discussing it with @aleventhal on a CL removing this behavior from Chromium, we concluded:

1. Chromium should do like Firefox and the legacy Edge on this matter.
2. The specs should be updated to reflect that we cannot and should not assume an implicit value of the aria-selected state for a gridcell. Also, we could update the specs of aria-selected to mention that the selection should only follow the focus on elements/roles that have an implicit aria-selected value of true or false.

What are your thoughts?

From @asurkov on February 2, 2017 15:4

Reported by Jamie [1]:

Note that the ARIA mapping guide says ROLE_SYSTEM_LIST without read-only:
https://www.w3.org/TR/wai-aria-implementation/#mapping_role_table
However, I'd argue this is a bug in the guide given that it's a subclass of list, not listbox.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1335734#c2

Copied from original issue: w3c/aria#520

Safari on MacOS seems to work well with indeterminate progress bars. Chrome does not seem to work so well (reads a value of 0%)

Looking at the mapping exposed by the browser it seems that safari is exposing
AXMaxValue of 0 for an indeterminate progress bar despite what the spec says. This seems to make voiceover read as indeterminate.

Suggest we check with @cookiecrook and maybe update Core-AAM with this information so Chrome can do the same

From @joanmarie on June 29, 2017 15:49

The Core AAM 1.1 and 1.0 both state that the mapping of aria-activedescendant on AX API is:

array AXSelectedRows contains pointer to active descendant node

But the ARIA Spec 1.1 and 1.0 both state that aria-activedescendant is supported on roles which might lack rows (e.g. tablist and toolbar).

Question 1: Is this really the correct mapping?
Question 2: Is it unconditional, or is it only for accessible elements which have rows?

With respect to Question 2, a quick grep through the WebKit accessibility code seems to suggest that not every role which supports aria-activedescendant exposes the active descendant node via AXSelectedRows. So I'm guessing the answer to Question 2 is "no."

Unless the answer to Question 1 is "no," what should implementors do when the active descendant is a descendant of a row? For instance what if the active descendant is a single cell within a grid? Should the user agent point to the parent row (because the property is called AXSelectedRows)? Or to the cell that is the active descendant (so VoiceOver doesn't have to examine the entire row looking for the appropriate cell)?

This mapping strikes me as one in need of clarifying language and/or correction.

James: Assigning this one to you. Please and thank you in advance!

Copied from original issue: w3c/aria#598

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29215

With regard to "5. For forward compatibility with new WAI-ARIA properties in future versions, user agents should expose all properties not in the table below as a text string, removing the "aria-" prefix from the name, if the API supports it. For example, aria-foo="bar" would be exposed with a text string foo=bar in UIA Express, since aria-foo is not a currently known WAI-ARIA property".

Comment: Why should user agents make such an assumption and present the aria-foo attribute without 'aria-' ...itmay lead to validation errors and is something best brought to the author's attention for correction. The foo="bar" should not trip up future AT unless they are made to ignore attributes that do not appear to make sense. User agents should simply ignore aria-foo and such.
Developers do have access to Nu Html Checker which flags incorrect use of role and ARIA attributes too I believe.

With regard to "6. Some WAI-ARIA properties are not global, and are only supported on certain roles. If a non-global WAI-ARIA state or property is used where it is not supported, user agents should not map the given WAI-ARIA property to the platform accessibility API. For example, if aria-checked="true" is specified on

, it should not be exposed in MSAA implementations as STATE_SYSTEM_CHECKED. User agents may expose non-relevant attributes as a text string if the API supports it as described above".

Comment:
What is the benefit of user agents exposing a given ARIA property as a text string when it cannot be mapped to the platform API?
It may trip up AT and confuse users.

Perhaps the above mapping rule# 5 and 6 are inconsistent with the goal stated in the abstract?:
"This helps users with disabilities to obtain and interact with information using assistive technologies. ... and helps to ensure that this information appears in a manner consistent with author intent".

As part of role parity, we added new roles for code, emphasis, and strong. The reason the Working Group added these roles, rather than using the to-be-created generic role, is that the HTML spec suggests that the code, em, and strong elements have associated semantic information. This semantic information makes them different in nature from pre, i, and b which will be mapped to the generic role and have the text formatting exposed via platform text interface/control support.

We need to figure out the mappings for the code, emphasis, and strong roles. I see two possible approaches:

1. Expose a dedicated accessible object for these, and platform role information (the "xml-roles" object attribute; the localized control type; the role description) can be used by ATs to identify what type of accessible object it is.
2. Do not expose a dedicated accessible object for these, and platform text attribute information can be used. Note that in this case, we'll presumably need to identify new attributes so that we can distinguish something that is, for instance, bold due to the strong role versus something that is bold due to purely stylistic reasons (the use of CSS; the use of the b element).

Some thoughts:

The former approach will make it possible for ATs to more quickly identify these objects. The latter approach will require ATs to check each parent container in a document just in case this role was applied.

In addition, if an author were to make an element with one of these new roles focusable, we'd need to know the platform-specific roles to use. Thus, really, even if we go with the second approach, we'll still need platform owners to provide an "if mapped as an accessible object" role.

Platform mappings are needed for https://w3c.github.io/aria/#aria-rowindextext and https://w3c.github.io/aria/#aria-colindextext.

• For ATK/AT-SPI2 (my platform), it should be the usual object attribute
• For IA2, I assume it should also be the usual object attribute (@jcsteh please confirm or correct)
• For UIA we need @melanierichards to chime in
• For AXAPI we need @cookiecrook to chime in

Thanks all!

In the Abstract, the passage “This document updates and supercedes the guidance” appears. “supersede” is generally considered the standard spelling of the word “supercede”.

Hi all,

I'm working with @alice and @tkent-google on allowing custom elements to specify their own default roles/states/properties. We think we have a rough plan, but need help in one regard. I will use role as the example, but the same reasoning should hold for states/properties, I think.

Right now, to our understanding, implementation behavior for an element's role is:

1. If the role="" attribute is set, use that, then map to native platforms using https://w3c.github.io/core-aam/.
2. Otherwise, map to native platforms using https://w3c.github.io/html-aam/#html-element-role-mappings

(side note: I can't find how to apply step 2 for custom elements; that is, I wasn't able to find a part of HTML-AAM that states how unknown tags map.)

We want to modify this to be something like:

1. If the role="" attribute is set, use that, then map to native platforms using https://w3c.github.io/core-aam/.
2. If the element is a custom element, and the custom element author has set a default ARIA role, then use that, mapping to native platforms using core-aam.
3. Otherwise, map to native platforms using https://w3c.github.io/html-aam/#html-element-role-mappings

However, I can't find where this 2-step algorithm might be defined today in specifications, so that we can properly insert this new step in the middle. Could folks help use locate that?

Thanks!

From @matatk on January 24, 2017 19:7

This is a spin-off from #513 which resolves that region landmarks should only be considered as such if they are named (via aria-labelledby or aria-label).

Background: I have been researching how screen-readers expose landmarks to users, because I work on a WebExtension that does the same. This issue has been filed as a spin-off from issues filed in other W3C specs (linked below).

This issue proposes that the same approach be applied to form regions, for the reasons mentioned in that thread, and in the related HTML-AAM issue #82 but repeated here for convenience:

1. There are instances in the wild of <form> elements wrapping whole pages [1,2,3] - these are not really valid landmarks, so considering them as such would add noise and confusion.
2. When a <form> is 'genuine': if it lacks a label, there's not really any useful landmark information there (it's easy enough to navigate to the form/first form control for most users anyway), so adding all unlabelled forms would add too much noise to the landmark navigation.

Related issues:

• Related remote issue: w3c/html-aam#82
• Analagous issue in this repo, relating to region: #513

Copied from original issue: w3c/aria#514

In Core AAM 5.4.1 General Rules (for role mapping)
point 4. says:

When an explicit or inherited role of none or presentation is applied to an element, the user agent MUST implement the rules for the none or the presentation role defined in Accessible Rich Internet Applications (WAI-ARIA) 1.0 [WAI-ARIA].

The "Accessible Rich Internet Applications (WAI-ARIA) 1.0" link should probably point to 1.1, and it's link text should say 1.1 instead of 1.0. (Note that the biblio link for [WAI-ARIA] is correct).