In today's Web applications, dialog boxes are as common as in desktop applications. We can easily display or hide an element with fewer JavaScript and CSS, but rarely consider the impact of dialog boxes on accessibility. In most cases, it is a disaster for accessibility. The input focus is not handled correctly and the screen reader is unable to perceive content changes. In fact, making the dialog accessible is not so difficult, you just need to understand the role of a few lines of code.
ARIA role
If you want screen reader users to perceive that a dialog box pops up, then you need to learn some aria role knowledge. ARIA role [1] provides additional semantics for HTML elements, allowing browsers to communicate with screen readers in a more descriptive way. Aria defines a number of roles that change the way a screen reader perceives different elements in a page. There are two roles associated with the dialog box: dialog and Alertdialog.
In most cases, we use dialog. Set the role property of an element to this value, and the browser will look at the element as a dialog box.
<id= "My-dialog" role= "dialog"> < Your Dialog code here--> </div >
When an element with the Role property value of dialog is visible, the browser informs the screen reader that a dialog box is open. This allows screen reader users to realize that they are not already in the regular stream of the page.
The dialog box should have a description label (label). You can use the Aria-label property to indicate the description text or use the Aria-labelledby property to indicate the ID of the element that contains the descriptive text. Examples are as follows:
<DivID= "My-dialog"role= "Dialog"Aria-label= "New Message"> <-- Your Dialog code here--></Div><DivID= "My-dialog"role= "Dialog"Aria-labelledby= "Dialog-title"> <H3ID= "Dialog-title">New Message</H3> <-- Your Dialog code here--></Div>
In the first example, the Aria-label property is used to specify a label that is used only for screen readers. You can use this method when the label of the dialog box does not need to be visible. In the second example, the Aria-labelledby property is used to specify the ID of the element that contains the dialog box label. Because the dialog box has a visible label, the correlation multiplexing ratio is repeated more appropriately. When the dialog box is displayed, the screen reader will read the label of the dialog box.
Alertdialog role is a special type of dialog that is designed to attract users ' attention. You can think of it as a confirmation dialog box (confirmation dialog) that pops up when you try to delete something. Alertdialog is less than the interaction. Its main purpose is to let the user perceive that an operation has been performed. In contrast, dialog may be an area for users to enter information, such as writing an e-mail or instant message.
When a alertdialog is displayed, the screen reader looks for descriptive text to read. We recommend that you use Aria-describedby to specify the text you want to read aloud. This property is similar to Aria-labelledby, whose value is the ID of the element that contains the content you want to read. If Aria-describedby is not specified, the screen reader will attempt to find the text that can be described, often selecting the first paragraph of text within the element. For example:
<DivID= "My-dialog"role= "Alertdialog"Aria-describedby= "Dialog-desc"> <PID= "Dialog-desc">Is sure you want to the delete this message?</P> <-- Your Dialog code here--></Div>
This example uses an element that contains the description text. Doing so ensures that the correct text is read when the dialog box is displayed.
Even if you do not set these additional properties, the accessibility of the app will be greatly improved by setting the appropriate role for the dialog box only.
Set the focus on the dialog box
The next step in creating a barrier-free dialog box is to manage focus. When a dialog box appears, the focus should be within the dialog box so that the user can continue browsing using the keyboard. The exact location of the focus set in the dialog box is largely dependent on the purpose of the dialog box itself. If there is a continue button and a Cancel button in the confirmation dialog box (Confirmation dialog), you can set the focus by default on the Cancel button. If the dialog box is for the user to enter text, you can set the focus to the text input box by default. If you really don't know where to focus, setting the focus on the element that can represent the dialog box is a good choice.
Because in most cases, we use the <div> element to represent a dialog box, you can set the focus by default on that <div>. You need to set the TabIndex property of the element to-1 so that the element can get the focus. This property value allows you to use JavaScript to set the focus to that element, but does not insert the element into the Normal tab order. This means that the user will not be able to press the TAB key to set the focus on the dialog box. Either set directly in HTML or through JavaScript settings. Set in HTML:
<DivID= "My-dialog"role= "Dialog"TabIndex= "-1"Aria-labelledby= "Dialog-title"> <H3ID= "Dialog-title">New Message</H3> <-- Your Dialog code here--></Div>
With JavaScript settings:
var div = document.getElementById ("my-dialog"=-1;d iv.focus ();
Once the TabIndex is set to-1, the element can call focus (), just like any other focusable element. This allows the user to press the TAB key to navigate through the dialog box.
Limit focus (trapping focus)
Another accessibility issue for the dialog box is to make sure that the focus does not jump out of the dialog box. In general, if the dialog box is modal, its focus should not escape the dialog box. When the dialog box is open, if you press the TAB key to set the focus to the page element behind the dialog box, it is quite difficult for the keyboard user to return the focus back to the dialog box. Therefore, we'd better use some JavaScript to prevent this from happening.
The basic idea is to use event capturing to listen for focus events, which are promoted by Peter-paul Koch[2] and are now widely used in JavaScript libraries. Because focus does not bubble (bubble), you cannot snap to it during the bubbling phase of the event stream. Instead, you can capture all the focus events on the page by using the event capture method. After that, you only need to determine if the element that gets the focus is in the dialog box. If not, the focus is set on the dialog box. The code is very simple:
function (event) { var dialog = document.getElementById ("My-dialog"); if (Dialogopen &&!) dialog.contains (Event.target)) { event.stoppropagation (); Dialog.focus (); true);
The code listens to the focus event of document to intercept all such events before the target element receives them. Assuming that the dialog box is open, the value of the variable Dialogopen is true. When the focus event occurs, the function intercepts the event, checks whether the dialog box is open, and, if so, checks whether the element that receives the focus is inside the dialog box. If all two conditions are met, the focus is reset on the dialog box. This way the focus loops at the end of the dialog box and at the beginning. This will not tab out the dialog box, the keyboard users can hardly lose their way.
If you use a JavaScript library, the Focus event delegate method can do the same thing. If you do not use JavaScript libraries and need to support Internet Explorer 8 and earlier versions, you can use the Focusin event instead (Translator Note: Focusin and focusout support event bubbling).
Restore Focus (Restoring focus)
The last focus of the dialog box: When the dialog box closes, the focus is returned to the body part of the page. The idea is simple: in order to open a dialog box, the user may have activated a link or a button. When the focus shifts to the dialog box, the user finishes some tasks, and then exits the dialog box. The focus should be reset back to the link or button that you clicked in order to open the dialog box so that you can continue browsing the page. This problem is often overlooked in Web applications, but the effect is vastly different.
As with other parts, a small amount of code can be achieved. All browsers support Document.activeelement, returning the element that currently has focus. You just have to get this value and then show the dialog box, and when you close the dialog box, return the focus to that element. For example:
var lastfocus = document.activeelement, = document.getElementById ("my-dialog"= "Show ";d Ialog.focus ();
The point of this code is that it records the final focus element. This way, when the dialog box is closed, the focus is set on it:
lastFocus.focus()
Overall, you can only add a few lines of code to your existing dialog box code.
Exit dialog box
The last question is to give the user a quick and easy way to exit the dialog box. The best way is to use the ESC key to close the dialog box. This is how the dialog box exits in the desktop application, so users are familiar with this approach. Just listen for the ESC key is pressed, and then exit the dialog box, such as:
function (event) { if (dialogopen && Event.keycode = =) { // Close the Dialog true);
The KeyCode value of the ESC key is 27, so you only need to find it in the KeyDown event. Once monitored, closes the dialog box and sets the focus back to the previous focus element.
Summarize
It is obvious from this article that creating a dialog box that can be easily accessed by screen readers and keyboard users does not require a lot of extra code. With just a few lines of code, what you bring to the user is no longer an endless frustration, but incredibly happy. There are many Web applications that use pop-up dialogs, but few of them can handle them correctly. Hopefully this article will inspire you to create your own barrier-free dialog box.
Reference documents
- Wai-aria (a)
- Focus and Blur event delegates by Peter-paul Koch (Quirksmode)
This article is translated from Nicholas C. Zakas's new work, "Making an accessible dialog box", "JavaScript advanced Programming" is his works.
Create a barrier-free dialog box (GO)