E-mail List Archives

Re: Dialog semantics and aria?

for

From: Greg Kraus
Date: Apr 25, 2014 1:05PM


The reason role="document" was introduced in this scenario was to
allow NVDA users the ability to browse the entirety of the
role="dialog". With the latest version of NVDA this is a non-issue
now, so my initial thought is that role="document" is not needed any
more.

Greg

On Fri, Apr 25, 2014 at 3:02 PM, Don Mauck < <EMAIL REMOVED> > wrote:
> Yes, I'm aware of the back button, however, I thought your question was related to non-IOS deployment.
>
> -----Original Message-----
> From: Jesse Hausler [mailto: <EMAIL REMOVED> ]
> Sent: Friday, April 25, 2014 12:57 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Dialog semantics and aria?
>
> Don,
> Yes, escape always closes the panel on a desktop browser. In mobile cases, there isn't so much of an escape key as there is the usual back button in the top left.
>
> Greg,
> Are you suggesting that role=document is no longer needed (or as Bryan suggests, avoiding use of role=dialog)?
>
> Thanks,
> Jesse
>
>
> On Fri, Apr 25, 2014 at 11:34 AM, Don Mauck < <EMAIL REMOVED> > wrote:
>
>> I've no problem with that as long as there was an easy way to leave
>> the panel. Not only a close button but the escape key should close
>> the panel as well.
>>
>> -----Original Message-----
>> From: Jesse Hausler [mailto: <EMAIL REMOVED> ]
>> Sent: Friday, April 25, 2014 12:30 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Dialog semantics and aria?
>>
>> 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>
>>
> > > > >