According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
This removes the Dev Tools A11y Panel code which explicitly allowed unlabelled descendants of role="img" <svg> elements, since we don't create descendants if they don't have a label now anyway.
The associated tests had to be tweaked as well, since now we don't create unlabelled descendants.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
This adds both the role as well as calculation of the posinset, setsize, and level calculation if not provided by the author.
Differential Revision: https://phabricator.services.mozilla.com/D64590
--HG--
extra : moz-landing-system : lando
This means that for any other ARIA role, we will expose the DOCUMENT role on the DocAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D60632
--HG--
extra : moz-landing-system : lando
This change will bring us on par with what Chrome does. However, if the author makes an error in applying a landmark role to an interactive element, or other element where the landmark role is illegal, as defined in the [WAI-ARIA in HTML specification section 2](https://www.w3.org/TR/html-aria/#document-conformance-requirements-for-use-of-aria-attributes-in-html), the accessible properties will now be that of the landmark role, no longer that of the native host language element. This might make some elements less accessible due to author error than before, but we currently do not know of examples in the wild that actually expose this problem. This could only be solved by applying the rules from said table also in the user agents, but that is not specified anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D41923
--HG--
extra : moz-landing-system : lando
If html:form has a name given via ARIA, expose it as a landmark to platform APIS that require it. At the time of this submission, this is the case for ATK.
Differential Revision: https://phabricator.services.mozilla.com/D9552
--HG--
extra : moz-landing-system : lando
According to the HTML Accessibility API mappings spec, aside, footer, header, main and nav elements should be mapped to the WAI-ARIA landmark role exposure. For footer and header, this is only true if scoped to the body element.
This patch changes the exposed roles to the new landmark mapping for the various platforms.
Differential Revision: https://phabricator.services.mozilla.com/D9413
--HG--
extra : moz-landing-system : lando
* Create BLOCKQUOTE internal role (also needed for correct exposure of
blockquote element on ATK)
* Add new ARIA roles to internal ARIA map
* Add new roles to existing ARIA roles mochitest and update blockquote
element test to reflect mapping to the new internal role
* Create BLOCKQUOTE internal role (also needed for correct exposure of
blockquote element on ATK)
* Add new ARIA roles to internal ARIA map
* Add new roles to existing ARIA roles mochitest and update blockquote
element test to reflect mapping to the new internal role
Gecko has two document roles: roles::DOCUMENT_FRAME and roles::DOCUMENT.
However, the former was not being used at all; the latter was being used
for both ARIA documents and for the native document container. We can
therefore fix this issue by repurposing the unused internal role:
* Rename the role from roles::DOCUMENT_FRAME to roles::NON_NATIVE_DOCUMENT,
and add clarification to the doc strings in Role.h
* Ensure load events are still emitted for ARIA documents (bug 759833)
* Update the ARIA-document mochitests to reflect the above changes
* Change the ATK role mapping for roles::DOCUMENT (the native container)
from ATK_ROLE_DOCUMENT_FRAME TO ATK_ROLE_DOCUMENT_WEB.
* On IAccessible2, map roles::NON_NATIVE_DOCUMENT to ROLE_SYSTEM_DOCUMENT.
This should cause there to be no change in behavior for that platform.
* On macOS map roles::NON_NATIVE_DOCUMENT to NSAccessibilityGroupRole
with a subrole of AXDocument.
--HG--
extra : rebase_source : bb6bacfa08c0d22e4e52a25d309d15b2a913320d
Recognize the graphics-document, graphics-object, and graphics-symbol
ARIA roles, mapping them to the DOCUMENT, GROUPING, and GRAPHIC internal
roles respectively.
Create a new internal role EDITCOMBOBOX so that we can distinguish
comboboxes with a text input (which is the case for the ARIA role)
from those which consist of only a popup button and associated list
(which is the case for the select element with a size of 1). Also
change the type of ARIA combobox from kGenericAccType to eCombobox
so that IsCombobox() will return true for both EDITCOMBOBOX and
COMBOBOX. Lastly, call IsCombobox() rather than role() when assigning
internal roles to descendants of comboboxes and emitting accessibility
events.
--HG--
extra : rebase_source : 3e31f2e2423d6cc7697b03c9afb3b1f8c136675a
Create a new internal role EDITCOMBOBOX so that we can distinguish
comboboxes with a text input (which is the case for the ARIA role)
from those which consist of only a popup button and associated list
(which is the case for the select element with a size of 1). Also
change the type of ARIA combobox from kGenericAccType to eCombobox
so that IsCombobox() will return true for both EDITCOMBOBOX and
COMBOBOX. Lastly, call IsCombobox() rather than role() when assigning
internal roles to descendants of comboboxes.
Perform a sanity check in Accessible::ARIATransformRole() for the
internal REGION role: If there is no accessible name, transform
the ARIA role into the native host language role. Also perform
a sanity check when getting the AXSubrole in macOS: If the roleAtom
is nsGkAtoms::region, only return AXLandmarkRegion if the internal
role is REGION.
Create a new internal REGION role which maps to the generic landmark role
of each platform accessibility API. Update the internal mapping of region
from roles::PANE and kGenericAccType to roles::REGION and eLandmark. Also
change the AXSubrole of region from "AXDocumentRegion" to "AXLandmarkRegion",
the latter being what is specified in the Core AAM 1.1 and used in Safari.