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
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--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
Proper native "groupbox" styling depends on the structure of the XBL binding. By restyling the Page Info dialog, the native styling is now unused except for the Print Page Setup dialog on Windows. The native apperance is thus not applied by default anymore, and the "groupbox" element can just be used semantically for accessibility. The Print Page Setup dialog applies the native styling on its own in a way that still works on Windows.
The only other consumers of "groupbox" are the in-content Preferences pages and dialogs. These are updated to use simpler styles that don't depend on the binding structure.
Differential Revision: https://phabricator.services.mozilla.com/D8752
--HG--
extra : rebase_source : af36d911980517f9b53036f4cd4f800c5e20ad22
The issue was specific to content insertion directly under a shadow root, the
rest should work (see bug 1427825 for the fix for other similar occurrences).
The removal of the aContainer argument follows the same pattern as bug 1442207.
Differential Revision: https://phabricator.services.mozilla.com/D6431
Sometimes, when cells have display:block, and a different cell in the same row has a column span, our index methods did not take these into account. Also, when regular tables encounter such a cell, index calculation failed.
Differential Revision: https://phabricator.services.mozilla.com/D7867
--HG--
extra : moz-landing-system : lando
Disabled most jsunit tests temporarily in this patch. Will modify and bring them
back up in later patches, as stuff is reimplemented.
Disabled most jsat mochitests. Will have a followup for but reënabling or
porting, depending on the test.
Depends on D6681
Differential Revision: https://phabricator.services.mozilla.com/D6682
--HG--
extra : moz-landing-system : lando
Disabled most jsunit tests temporarily in this patch. Will modify and bring them
back up in later patches, as stuff is reimplemented.
Disabled most jsat mochitests. Will have a followup for but reënabling or
porting, depending on the test.
Depends on D6681
Differential Revision: https://phabricator.services.mozilla.com/D6682
--HG--
extra : moz-landing-system : lando
When checking for an accessible if it is a table row instead of a table cell, when retrieving the actual row at the given index, null check it to make sure we don't pass an invalid accessible to the TableAccessible::CellInRowAt method. I accidentally omitted that null check in the updated patch for bug 1486668.
Differential Revision: https://phabricator.services.mozilla.com/D7162
--HG--
extra : moz-landing-system : lando
Appearently with UA Widget the page loads quicker, so the tests must now
explicitly wait for the audio source to load to test on the video controls
UI in its stable state.
Depends on D3840
Differential Revision: https://phabricator.services.mozilla.com/D3841
--HG--
extra : moz-landing-system : lando
This can easily be reproduced if the ancestor being owned has role="presentation", but there are other cases as well.
If we don't prevent this, we end up with a loop.
Differential Revision: https://phabricator.services.mozilla.com/D4051
--HG--
extra : moz-landing-system : lando
When the user is editing the text in the URL bar (typing, backspace, etc.), the first suggestion is always selected.
Because accessibility clients require autocomplete items to be "focused", the code needs to differentiate between explicit selection (e.g. via down/up arrow) and auto selection (e.g. when typing).
Otherwise, the focus continually moves away from the text box while the user is typing, as was previously occurring.
This makes it very difficult for the user to edit text, particularly backspace/delete.
There was a previous attempt to handle this, but it was somewhat fragile and broke completely some time ago.
Now, rather than trying to handle this based on autocomplete events, it is handled in the input and key press events.
For input events, accessibility focus is forced back to the text box and further accessibility focus events are suppressed.
For down arrow, up arrow, etc. key presses, accessibility focus events for suggestions are enabled.
This makes it easier to understand and predict the user experience, rather than relying on underlying autocomplete implementation details.
This is tested using an accessibility browser test, which makes it easier to make assertions about accessibility focus.
This also means that if the underlying implementation details change (e.g. HTML + aria-activedescendant instead of XUL + DOMMenuItemActive events), this test should still be valid and allow us to catch regressions.
Differential Revision: https://phabricator.services.mozilla.com/D5987
--HG--
extra : moz-landing-system : lando
