WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Dialog semantics and aria?

for

From: Bryan Garaventa
Date: Apr 25, 2014 12:56PM

True, there are some other considerations to keep in mind as well though.

If you use role=dialog or role=alertdialog or role=application, any content
marked up as such will only appear on one line in the main document within
Browse Mode when using NVDA, which may not be desirable in all cases as a
general practice for providing easily readable content.

E.G You arrow down, and you hear "application", arrow down again, and you
are past the application region. You have to press enter on it to access the
content within the application region if you want to read its content. This
also means you can't quickly jump to form fields that are included within
such regions, because the quick navigation keys don't work. The same
behavior is true for the roles dialog and alertdialog, which then requires
careful focus handling to manage correctly as a result.



-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Greg Kraus
Sent: Friday, April 25, 2014 11:34 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Dialog semantics and aria?

The problem with role="dialog" and role="document" has to do with the
difference in how certain screen readers handle application mode.
Namely, older versions of NVDA would not let you use the virtual cursor at
all in role="dialog". In that case it became necessary to also use
role="document" to allow NVDA users to use their virtual cursor. The latest
version of NVDA (2014.1) does not have this problem.

You can read about the situation here.

http://accessibility.oit.ncsu.edu/blog/2014/01/02/incredible-accessible-moda
l-window-version-2/

Greg
--
Greg Kraus
University IT Accessibility Coordinator
NC State University
919.513.4087
<EMAIL REMOVED>
http://go.ncsu.edu/itaccess

On Fri, Apr 25, 2014 at 2:29 PM, Jesse Hausler < <EMAIL REMOVED> >
wrote:
> With regards to accessible semantics and aria, would you consider a
> panel that pops up and fills the entire screen, with say a form.. the
> same as a modal overlay? Once the panel is closed, focus goes back to
> the trigger page.
>
> We do this quite a bit for mobile apps. I see them as the same, but
> would like to hear other opinions.
>
> Jesse
>
>
>
>
> On Fri, Apr 25, 2014 at 11:06 AM, Jesse Hausler
< <EMAIL REMOVED> >wrote:
>
>> For the landmark-ness of it? :)
>>
>>
>> On Fri, Apr 25, 2014 at 11:02 AM, Bryan Garaventa <
>> <EMAIL REMOVED> > wrote:
>>
>>> >I got a tip from some folks at CSUN to embed a div with role="document"
>>> to
>>> address the issue with screen readers and application mode that you
>>> mention.
>>> Have you found luck with that method?
>>>
>>> It's true that the document role negates applications mode, but it
>>> then begs the question, why use the dialog role if you are only then
>>> negating it?
>>> :)
>>>
>>> -----Original Message-----
>>> From: <EMAIL REMOVED>
>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Jesse
>>> Hausler
>>> Sent: Friday, April 25, 2014 10:55 AM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Dialog semantics and aria?
>>>
>>> Thanks for your feedback Bryan.
>>>
>>> I'm not sure where I saw the tabindex=0. I agree with you that it
>>> should likely be -1.
>>>
>>> I got a tip from some folks at CSUN to embed a div with
>>> role="document" to address the issue with screen readers and
>>> application mode that you mention.
>>> Have you found luck with that method?
>>>
>>> Jesse
>>>
>>>
>>> On Fri, Apr 25, 2014 at 10:24 AM, Bryan Garaventa <
>>> <EMAIL REMOVED> > wrote:
>>>
>>> > I'd recommend the following instead.
>>> >
>>> > <div role="region" aria-labelledby="modal-title" tabindex="-1">
>>> >
>>> > <button>
>>> > <span aria-hidden="true">
>>> > X <!--- or equivalent icon font ---> </span> <span
>>> > class="assistiveText">Close Dialog</span> </button>
>>> >
>>> > <h2 id="modal-title"> <!--- Title of Modal goes here---> </h2>
>>> >
>>> > <div>
>>> >
>>> > <!--- contents of modal goes here--->
>>> >
>>> > </div>
>>> > </div>
>>> >
>>> > I assume tabindex=0 was set so you could set focus to the modal
>>> > when rendered, but this shouldn't be in the tab order, so -1
>>> > should be set instead.
>>> >
>>> > I don't recommend role=dialog due to the keyboard interaction
>>> > differences enforced by some screen readers, and adding it doesn't
>>> > actually increase accessibility for screen readers in any way. The
>>> > region role is a good compromise because it provides beginning and
>>> > ending boundary feedback with a defined label.
>>> >
>>> > >Would you add aria-live to the outer div?
>>> >
>>> > It probably wouldn't do anything unless you were writing the
>>> > content into the div after rendering it using innerHTML anyway.
>>> >
>>> > >Would a <section> be better than <div> for outer element?
>>> >
>>> > Not better or worse that I'm aware of, just different, so it's
>>> > worth playing with.
>>> >
>>> > -----Original Message-----
>>> > From: <EMAIL REMOVED>
>>> > [mailto: <EMAIL REMOVED> ] On Behalf Of Jesse
>>> > Hausler
>>> > Sent: Friday, April 25, 2014 10:06 AM
>>> > To: WebAIM Discussion List
>>> > Subject: [WebAIM] Dialog semantics and aria?
>>> >
>>> > Just looking to verify that these are good semantics and aria for
>>> > a dialog component.
>>> >
>>> > <div role="dialog" aria-labelledby="modal-title" tabindex="0">
>>> >
>>> > <span class="assistiveText">Start Dialog</span>
>>> >
>>> > <button>
>>> >
>>> > X <!--- or equivalent icon font --->
>>> >
>>> > <span class="assistiveText">Close Dialog</span>
>>> >
>>> > </button>
>>> >
>>> > <h2 id="modal-title"> <!--- Title of Modal goes here---> </h2>
>>> >
>>> > <div role="document">
>>> >
>>> > <!--- contents of modal goes here--->
>>> >
>>> > </div>
>>> > </div>
>>> >
>>> > Would you add aria-live to the outer div?
>>> > Would a <section> be better than <div> for outer element?
>>> >
>>> > I sometimes wish the WAI Aria Authoring practices guide would just
>>> > include recommended semantics for their widgets, as opposed to
>>> > giving links to differing examples.
>>> >
>>> > Thanks,
>>> > Jesse
>>> > >>> > >>> > list messages to <EMAIL REMOVED>
>>> >
>>> > >>> > >>> > list messages to <EMAIL REMOVED>
>>> >
>>> >>> >>> list messages to <EMAIL REMOVED>
>>>
>>> >>> >>> list messages to <EMAIL REMOVED>
>>>
>>
>>
> > > list messages to <EMAIL REMOVED>
messages to <EMAIL REMOVED>