Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dialog role should not be focused unless it is modal #9

Open
compulim opened this issue Apr 12, 2020 · 1 comment
Open

Dialog role should not be focused unless it is modal #9

compulim opened this issue Apr 12, 2020 · 1 comment

Comments

@compulim
Copy link

In the matrices:

When rendered, programmatic focus should then be set to an appropriate element within the Dialog, and scripting should be used to confine the forward and reverse tab order within the Dialog container if modal.

But according to WAI-ARIA practices, https://www.w3.org/TR/wai-aria-practices/#alert. Dialog should not interrupt user workflow and should not affect focus unless it is modal, which should be presented by alertdialog instead.

An alert is an element that displays a brief, important message in a way that attracts the user's attention without interrupting the user's task. Dynamically rendered alerts are automatically announced by most screen readers, and in some operating systems, they may trigger an alert sound. It is important to note that, at this time, screen readers do not inform users of alerts that are present on the page before page load completes.

Because alerts are intended to provide important and potentially time-sensitive information without interfering with the user's ability to continue working, it is crucial they do not affect keyboard focus. The alert dialog is designed for situations where interrupting work flow is necessary.

It is also important to avoid designing alerts that disappear automatically. An alert that disappears too quickly can lead to failure to meet WCAG 2.0 success criterion 2.2.3. Another critical design consideration is the frequency of interruption caused by alerts. Frequent interruptions inhibit usability for people with visual and cognitive disabilities, which makes meeting the requirements of WCAG 2.0 success criterion 2.2.4 more difficult.

@accdc
Copy link
Collaborator

accdc commented Apr 23, 2020

Hi,
Thank you for your patience, it's been hectic lately.

The difference is that an alert is not the same thing as an alertdialog, where an alertdialog is the same thing as a normal dialog but includes the ability to be announced at the same time. In all other respects however, it must be handled in the same way as a dialog where focus is moved within it when rendered.
http://whatsock.com/training/matrices/#alertdialog

This is important, because any dialog that is rendered, whether it is an alertdialog or a dialog, it is rendered as an individual object outside of the regular flow. This means that, if you run a page that opens a dialog or alertdialog when using NVDA in Firefox for example, all of the dialog content, including all active elements and textual content within it, will be undiscoverable if focus is not moved within the dialog. In such cases, this makes all dialog content totally inaccessible unless focus is handled appropriately when the dialog is rendered.

Within recent W3C meetings, the alertdialog role has been reclassed to map to role=dialog to make this association clearer in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants