1
votes

If I have a 3 buttons on a page, and choosing one causes them to be hidden, and then show another div containing some form elements, I want to correctly notify the new content added shown. My understanding is dynamic content changes such as showing a region need to be handled properly in terms of WCAG. Is there a standard way to handle this in terms of aria/html?

I've tried aria-live, since it's often suggested for this scenario, on the outer div of the new region, but even with aria-live="polite" I get undesirable side affects. Let's say the region shown contains a small form. When focus moves to a text field, and I begin typing, I got the odd behavior that JAWS will repeatedly start reading the label again and again for each single keystroke as the user types characters in the input. If I remove the aria-live attribute on the parent div, then tab through the form the label is only read once on field focus, and is not read again as the user is typing.

I.e. it seems the parent having an aria-live is causing child elements like labels to get read more aggressively, even though the region being shown is a one time change, and there's no dynamic changes after that point.

This odd behavior seems to imply that aria-live is better suited for small isolated elements such as errors/alerts being added to the page, rather than large regions.

Should I be using a role instead?

<form role="form" action="/submit" method="post">
    <div hidden id="section1" aria-live="polite">
        <h2>Form Header</h2>        
        <div>
            <label for="RequestNumber">Request Number*</label>
            <input id="RequestNumber" name="RequestNumber" type="text" />           
        </div>
    </div>
</form>
2

2 Answers

2
votes

The golden rule - don't use ARIA unless all other options have been exhausted.

What you actually want to do here is simply manage focus.

When you click one of the 3 buttons I assume a different form is shown. 99% of Screen Readers can handle this no problem (and for the ones that can't they are used with no JavaScript so make sure your website works without it if possible.)

When you click the buttons, hide them (if you have an animation then use aria-hidden, otherwise just display:none will do) and then when the new form is shown simply focus the form using JavaScript.

The screen reader will take care of the rest.

It may be advisable to add some visually hidden text on the buttons to inform the user that the buttons disappear and a form appears - just make sure you provide a way for them to go back to the buttons in case they made the wrong choice.

Visually Hidden Class For Reference

Use the below CSS to hide an inline span within the button if you feel it is appropriate information a screen reader may need.

.visually-hidden { 
    position: absolute !important;
    height: 1px; 
    width: 1px;
    overflow: hidden;
    clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
    clip: rect(1px, 1px, 1px, 1px);
    white-space: nowrap; /* added line */
}
1
votes

This sounds like a case of simple progressive disclosure. What JAWS is doing is not a bug, but exactly how aria-live works. Aria-live creates a sensitive region of the DOM that triggers an utterance by Assistive Tech whenever that region is changed. This is why wrapping a form in aria-live would be unwise.

If this is truly a progressive disclosure situation where the form is building itself ahead of the user based on their selections, aria-live notifications are not necessary. As long as the user's focus moves logically through the form elements as they are pertaining to their current task and content behind the user isn't changing, no alerts should be necessary.

In your example, you're wrapping the form fields and labels as well. You might want to just add the H2 into an aria-live region which will restrict the announcment to just that element.

(Apologies if I misunderstand the situation, but if selecting one of the buttons causes the button set to disappear and a div to be added, then the real question is where does focus land?)