The overlay features a main heading "Terms and conditions", plain text describing terms and conditions, two buttons ('Agree' and 'Decline'), and a 'Close' button at the top. Example of a lightbox containing plain text and buttons. For example, let’s have a look at the following dialog content: Figure 2. The first one is to ensure that screen readers will automatically read out the non-focusable information in a dialog when it opens. There are two solutions which can be considered to address this issue. However, this is often not the case even dialogs with forms usually provide some instruction in plain text (which in application mode will be ignored). This is not a problem if the element with role=”dialog” contains only form fields, labels and buttons. Since role=”dialog” was created for windows which 'prompt users to enter information or require a response' (see ARIA spec above), the document mode in those overlays should be disabled for the users to be able to enter input rather than trigger keyboard shortcuts to move the virtual cursor around the page. This behaviour is triggered by role=”dialog” causing screen readers to switch from document mode to application mode in which all shortcut keys, which are normally used to control the virtual cursor, are disabled. However, it may not be possible to access any non-interactive elements, as using arrow keys and other shortcut keys controlling the virtual cursor (such as 'H' for headings, or 'T' for tables) do not necessarily work. When the user moves around the overlay using the Tab key, the focus moves from one focusable element to another, link phrases, button texts and form field labels are read out. There is a catch though – some screen readers will only acknowledge the focusable elements in the overlay with role=”dialog”, ignoring all other content. This overlay is displayed on top of the main page content which is dimmed.Īpplying role="dialog" on that overlay conveys boundaries of the overlay to screen readers and disables the main page content, identifying the dialog content as being separate from the rest of the page. Example of a lightbox - an overlay window with a main heading "Subscribe to our newsletter", containing two input fields ('Email address' and 'Region'), and two buttons ('Subscribe' button at the bottom and 'Close' button at the top). Therefore this role is very useful for overlay windows containing forms, such as the "Subscribe to our newsletter" dialog shown in Figure 1. According to ARIA spec, " a dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response". This role was created specifically for modal windows. Luckily, there are some ARIA roles and attributes which can help to make interacting with overlay windows easier for people using screen readers. Apart from these issues, dialogs can be tricky to use for screen reader users for few other reasons. In the first part of this article, I've discussed keyboard accessibility issues which are often found in overlay windows, and which affect both sighted keyboard users and screen reader users.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |