Clever Geek Handbook

Hide all elements from screen except one div?

I have implemented a popup that is triggered by a button on my web page. This popup almost fills the entire screen and prevents users from interacting with anything on the web page until the popup is dismissed. This works well for sighted users, but when using VoiceOver on a Mac, you can navigate the main content of a web page, and a blind user would have no idea about the pop-up window.

How can I prevent VoiceOver from navigating through every element on the page except one div

(and every element in that div

)?

I know it can be used aria-hidden="true"

to hide it from screen readers, and I know it can be made to focus on an element, but I'm not sure how best to do this. Do I need to iterate over the entire DOM and essentially hide everything and then close everything around? Or is there a better approach, some ARIA property that defines the type of element that is presented, perhaps?

A website showing the desired behavior, Piazza . When you activate the Login button, it presents a pop-up modal dialog and requires focus, and you cannot move away from it until you release the pop-up.

+3


source to share


3 answers


Implementing accessible modal dialogs correctly has become one of the most difficult aspects of website accessibility, as there are only so many things to consider beyond the usual issues of screen renderer and browser and specification compliance. Here's a summary (!) Somewhat based on personal experience, this article from Smashing Magazine on Modal's available dialog boxes , WAI-ARIA 1.0 Best practice author and this is a slideshow on the same topic .

(Note that you will find some conflicting guidelines between the two: this is to some extent due to differences in behavior between browsers / browsers and the spec, and different authors have different positions on whether to stick to the spec or work with barcode readers which users actually use.)



  • Tell the stitchers a dialog: add role = "dialog" to the parent DIV and set aria-labelled to point to the header id.

    This makes the screen device recognize the part of the user interface as a dialog in the first place; when the user navigates to it, either by navigation or because focus moves to it, the screen reader will announce that the user is currently in the dialog and will probably announce the title as well. (In some screen / browser combinations, notably VoiceOver + Safari, this may also affect how the on-screen navigation works.) However, it does not "hide" any other user interface on the page.

  • Add basic keyboard support

    There are a lot of things here that are important for both screen ROM users and those who do not work on screen using keyboard users. The two key questions here are moving focus to where it needs to in the dialog when it initially appears, and when the dialog is rejected, bring focus back to where it was when the dialog appeared.

  • Make it modal for screen flash users and keyboard users

    Dialogs come in two flavors: modal, which prevent the user from interacting with any other user interface while they are present, and modeless, which allow the user to leave the dialog and come back later — examples are the Find Text dialogs in some text editors. role = "dialog" does not distinguish between the two, and using ARIA does not affect browser behavior, so if your dialog is modal you need to do some extra work yourself to make it behave like a modal. There are two aspects:

    • Just as modal dialogs use a gray canvas or blur effect to visually hide the inactive background from visible users, we also want to hide this content from screen firmware users: otherwise, they can still go from the dialog to the background or use others. hotkeys to display links or headers or other controls from the page and you will see both from the background of the page and the dialog box. Using aria-hidden = "true" is the best tool for this (and be sure to remove it when done). The simplest approach here, if your page structure allows it, is to have all of the master page content under one div, so you can only aria-hidden on one div;otherwise, you will have to apply it to all non-dialog top divs.

    • For both screen readers and non-screen readers, you also need to make the keyboard behavior modal: clicking a tab from the last item in a dialog should wrap to the beginning of the dialog, and the reverse should be for shift-tab. If you don't, keyboard and scrolling users - users can simply insert a tab directly from your dialog in the background of the page. There are different approaches for this, most of which involve tracking focus or similarity at the body level and forcing focus back into dialogue if it "slips away".

  • Other tweaks / fixes / hacks

    Windows based firmware such as NVDA and JAWS enter "application mode" when they enter a dialog: their web navigation hotkeys no longer work and they treat the contents of the dialog as a form rather than a rich web page. This is good because the content of the dialog is a classic form with only fields, labels and buttons, but not suitable for a dialog containing web content with text, hyperlinks, etc. In this case, you can put <div role="document">...</div>

    = "dialog" in your movie, but wrap the main content.

  • Making Dialogue Content Accessible

    Of course, but all of the above is considered for nothing if the content inside the dialog itself is not available.

  • The most important thing is to understand why you are making the dialogue available in the first place, and test it accordingly.

    Unfortunately, at the moment (January 2015!) There are still many changes in behavior between different programmers (depending on the browser used); it's almost like how browsers have been with CSS for a decade (!) or just as long. It's worth understanding why you want to make your user interface accessible, figuring out where most of your users will be, and testing accordingly with the firmware they'll be using. From the most recent WebAim Screenreader poll (January 2014), Windows readers - especially JAWS and NVDA - have the largest market share, with VoiceOver the third.

    One possible strategy can be considered here:

    • If you just want to do basic due diligence testing with VoiceOver can be great. The experience may not be as good on other screen readers, but if something works with VO it probably won't completely break for others.

    • The next level is to get a copy (free, but feel free to donate) NVDA window flasher and run that in a virtual machine on a Mac (if you're using a Mac here). NVDA and JAWS tend to be pretty close in behavior.

    • If availability is part of your job description, then it is likely that you or your company will need to get a copy of JAWS ($ 800 +!), As it appears to be a screen picker for government and education. (This is perhaps analogous to accessibility for testing with IE versions!)

+3


source


You must iterate over all top-level elements and set aria-hidden = true on those elements. This is an example:

<!doctype html>
<html>
    <head>
        <title>aria-hidden examples</title>
    </head>
    <body>
        <a aria-hidden="true" href="#">Link at top</a>
        <p aria-hidden="true">Lots of text content</p>
        <form aria-hidden="true">
            <label for="input">Label</label>
            <input id="input" type="text" />
            <button>Submit</button>
        </form>
        <div>
            <label for="dialogInput">Nother Label</label>
            <input id="dialogInput" type="text"/>
        </div>
        <form aria-hidden="true">
            <label for="input2">Label 2</label>
            <input id="input2" type="text" />
            <button>Submit 2</button>
        </form>
        <a aria-hidden="true" href="#">Link at bottom</a>
    </body>
</html>


The problem is that this will cause the declarations to remain in the "dialog", but if you press the tab key, the focus may go out of the dialog and not be declared. This means that if there are interactive elements in the dialog box, the user may interact with the wrong elements. Other browsers will do similar things.

Thus, you need to catch focus inside the dialog using a Javascript event handler to handle your TAB keys if your page contains other naturally customizable elements like the example above.

+1


source


WAI-ARIA provides dialog and alertdialog for defining dialogs. The dialog role is used when the user has to provide data, and the alertdialog role is used to advertise the contents of the dialog to the user.

Alert dialog

<div role="alertdialog"
     aria-labelledby="dlgtitle"
     aria-describedby="instructions">
  <h1 id="dlgtitle">Shutdown instructions</h1>
  <ol id="instructions">
    <li>Open timesheet</li>
    <li>Enter time for today</li>
    <li>Close all open applications</li>
    <li>Shut down system</li>
  </ol>
  <div>
    <input type="button" value="OK">
  </div>
</div>

Dialog

<div role="dialog" aria-labelledby="dlgtitle">
  <h1 id="dlgtitle">Sign up to Newsletter</h1>
  <ol id="instructions">
    <li>Enter email address</li>
    <li>Press the 'Sign up' button</li>
    <li>You're all signed up!</li>
  </ol>
  <div>
    <label for="email">Email: </label>
    <input type="text" 
           id="email"
           name="email"
           aria-describedby="instructions">
    <input type="button" value="Sign up">
  </div>
</div>

WAI-ARIA Template for authoring practice development for modal dialogue

0


source






More articles:


All Articles