core-aam
core-aam copied to clipboard
Support ARIA 1.3's aria-description property
The precedence order is: aria-describedby aria-description
Pull request for aria-description in ARIA spec: https://github.com/w3c/aria/pull/1137
@joanmarie is it time to review these CORE-AAM changes?
This is merged already in Core-AAM. @aleventhal is there anything else we need to do before closing this issue?
There is one remaining issue regarding the AX API mappings being incorrect/incomplete. I filed https://github.com/w3c/core-aam/issues/104 and assigned to @cookiecrook.
This one can be closed.
Actually, there are 2 remaining things to do for ATK/IA2:
- The description object attribute, which should only be exposed when aria-description is used.
- The description-from object attribute. Chrome implements it but Firefox does not yet. In this case it should have a value of "aria-description". We should also update the aria-describedby mapping for IA2.
In general, "description-from" has one one the following values:
- "aria-description"
- "aria-describedby"
- "ruby-annotation"
- "summary"
- "table-caption"
- "tooltip" (either via @title or aria-describedby + role="tooltip")
- "button-label" (when the name came from other markup such as aria-label)
FWIW, here's the Firefox issue to implement this: https://bugzilla.mozilla.org/show_bug.cgi?id=1726087
* "button-label" (when the name came from other markup such as aria-label)
What is this for? How can the description come from aria-label and why is it specific to buttons?
How can the description come from aria-label and why is it specific to buttons?
If the name of a button come from aria-label oder aria-labelledby, then the value of the button is the description: https://www.w3.org/TR/html-aam-1.0/#input-type-button-input-type-submit-and-input-type-reset-accessible-description-computation
That's correct. What @JAWS-test is saying is where Chrome is using kButtonLabel.
@spectranaut does this have tests?
I added a test: https://github.com/web-platform-tests/wpt/pull/34758
And here is a link to the webkit tracking issue (so they are all in one place): https://bugs.webkit.org/show_bug.cgi?id=206253#c18