New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 627823 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

Expose all unrecognized aria attributes

Project Member Reported by nek...@chromium.org, Jul 13 2016

Issue description

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, since aria-foo is not a currently known WAI-ARIA property. The following list specifies the accessibility APIs for exposing properties as text strings.
◦MSAA:
not supported
  ◦IAccessible2: expose as an object attribute pair ( property:string) 
  ◦UIA: expose an object attribute pair in AriaProperties (property=string) 
  ◦ATK/AT-SPI: expose as an object attribute pair (property:string) "

 

Comment 1 by nek...@chromium.org, Nov 14 2016

Status: Available (was: Asigned)
Labels: NewComponent-Accessibility-Blink
Labels: NewComponent-Accessibility
Components: Blink>Accessibility
Components: -UI>Accessibility
Labels: -newcomponent-accessibility-blink -newcomponent-accessibility
Labels: triage-aaron
This is only a "nice-to-have". Chrome updates so frequently, and across users, that it's easy to expose new parts of ARIA as they come along. It would make it easier to experiment, but I wouldn't want to sacrifice any performance for that. I'm concerned that going through all the attributes for each element looking for the "aria-" prefix would hurt performance.
Labels: -triage-aaron
Status: WontFix (was: Available)
Also, this is only a "SHOULD" in the spec.

Sign in to add a comment