Dialogs in web pages in Firefox and Chrome now get browseMode if the parent document also has browseMode #7433
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…a sub or super class to turn off automatic focusing of the first focusable descendant, by setting a special attribute.
…parent document has a treeInterceptor.
|
Will this break dialogs which (kindly) focus some item in them, which are most important? also, what if there's a document within the dialog? |
jcsteh
requested changes
Jul 31, 2017
| class WebDialog(Document): | ||
| """ | ||
| A dialog that will use a treeInterceptor if its parent currently does. | ||
| """ |
There was a problem hiding this comment.
It might be good to explain the practical impact in real world terms; i.e. that web dialogs should use browse mode by default unless they're inside an ARIA application.
| # For dialogs that will get browseMode and are focusable themselves (have a tabindex): | ||
| # Allow setting focus to the dialog directly, rather than its first focusable descendant | ||
| def _get__alwaysFocusFirstfocusableDescendant(self): | ||
| return not self.shouldCreateTreeInterceptor |
There was a problem hiding this comment.
As discussed, unless I'm missing something, I don't think the changes related to FocusableUnfocusableContainer are necessary. That behavior should only get used if the container is not focusable itself.
| @@ -46,6 +46,21 @@ def _get_shouldCreateTreeInterceptor(self): | |||
| class Application(Document): | |||
| shouldCreateTreeInterceptor = False | |||
|
|
|||
| class WebDialog(Document): | |||
| """ | |||
There was a problem hiding this comment.
Consider moving this into behaviors, as it might be useful for Edge and/or MSHTML.
…heir label when embedded in a document, we should not do this when the dialog or application is the root of the buffer as we lose all the content if this particular application or dialog gets browse mode itself.
…et browseMode by default themselves.
jcsteh
approved these changes
Aug 1, 2017
…should not be reported as a marker if they themselves are the root of the content.
jcsteh
approved these changes
Aug 2, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Fixes #4493
Summary of the issue:
The web accessibility community has requested that dialogs be navigable the same way any normal web document is (I.e. has NVDA browseMode by default), unless they are embedded in an application. Currently NVDA treats dialogs similar to applications in that browseMode is not available by default.
Description of how this pull request fixes the issue:
Dialogs in Firefox and Chrome will now get browseMode by default if the parent document has a treeInterceptor.
This involved creating a new WebDialog NVDAObject class in ia2web and using this for dialogs in place of Application.
Also, a change was made to FocusableUnfocusableContainer behavior to allow a sub or super class to choose to allow setFocus to fallback to setting focus to the object itself rather than the first focusable descendant, if the object itself definitely is focusable. Many dialogs on the web do ahve a tabindex of -1 and the UX is better if we can set focus to the dialog not the descendant when providing browseMode on first activation so it reads from the top.
Testing performed:
A div with role=dialog in a standard web document, and also role=dialog inside an div with role=application in a web document.
Tested in both Chrome and Firefox.
Known issues with pull request:
This does not change Internet Explorer as we are no longer supporting new features, and Edge currently has limitations in its text patterns which make this impossible (namely there is no specific text pattern for each dialog to bound browseMode).
Change log entry:
Section: Changes