In bug 1507365, we introduced the ability of nested label children of toolbar buttons to provide the accessible name for a xul:toolbarbutton element. However, the XBL of xul:toolbarbutton causes the creation of a label accessible even if no xul:label child is present, and only the label attribute is being used. The nsIAccessibleText interface on such labels is, however, completely broken. This causes NVDA's mouse tracking, which always uses the deepest nested child, to fail. As a result, when hovering over Hamburger menu items, the announcement would be wrong, e. g., lag one behind the actual button the mouse is hovering over.
To fix this, we only accept xul:label children if they come from real XUL markup, not from the label attribute and the XBL creating the label. This means that some of the test changes from bug 1507365 have to be reverted to accommodate the new old behavior. But the new test for an actual label child still passes.
Differential Revision: https://phabricator.services.mozilla.com/D14469
--HG--
extra : moz-landing-system : lando
This prevents an infinite loop where we go into a child only to find the
nearest hypertext accessible being its parent.
Differential Revision: https://phabricator.services.mozilla.com/D13998
--HG--
extra : moz-landing-system : lando
Creates the HTML Caption accessible from the markup map, but only if it's the first caption. Other caption elements are ignored as before.
This also creates caption accessibles for those captions that have been collapsed to zero height and width via CSS.
Differential Revision: https://phabricator.services.mozilla.com/D12756
--HG--
extra : moz-landing-system : lando
Simply decouple the check for the checked attribute from the one for the type attribute.
Differential Revision: https://phabricator.services.mozilla.com/D12632
--HG--
extra : moz-landing-system : lando
Toolbar buttons in XUL can now have labels inside them to provide the actual caption for the button. Adjust the accessibility module to allow label elements as acceptable children for the toolbarbutton element so the algorithm can pick up their text for the button's name.
Differential Revision: https://phabricator.services.mozilla.com/D12527
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
--HG--
extra : source : 803b224d52a0940b4fb4b3b9cffc6a1fa6e5d4ee
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Made IsTableCell() only check the generic type, not the ARIA map entry that gets checked in HasGenericType. This prevents the crash and also fixes IsTableCell() and AsTableCell() not being in sync.
Differential Revision: https://phabricator.services.mozilla.com/D10713
--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
We already mapped aria-current to the correct attribute, but we did so unconditionally unless the value was false or undefined. However, if the value was an invalid token, it would not be mapped to "true" as per spec. Now, any bogus value for aria-current will be mapped as if the author had specified "true".
In addition, this patch adds aria-current to the known set of attributes with rules, which causes NSAccessibilityService::MustBeAccessible to make sure an accessible gets created if aria-current is set, even if that accessible is a html:span element. This fixes bug 1365904.
Differential Revision: https://phabricator.services.mozilla.com/D10331
--HG--
extra : moz-landing-system : lando
Depends on D10191
I would like to update browser-test.js to stop swallowing exceptions
when calling loadSubScript from head.js.
It looks like those head files are trying to load a layout.js helper
that I could not find in any revision. Can you check it can be
removed?
Differential Revision: https://phabricator.services.mozilla.com/D10193
--HG--
extra : moz-landing-system : lando
Bug 1210630 introduced a mapping of the html:section element to roles::LANDMARK, however roles::REGION is more appropriate since that is also used by the WAI-ARIA role mapping and contains specific mappings for regions, e. g. on Mac.
Differential Revision: https://phabricator.services.mozilla.com/D9651
--HG--
extra : moz-landing-system : lando
