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.

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.

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.

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.

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.

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.

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.

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.

No problem. The goal is for the same component to be available for both
mobile and desktop situations. So while we'll have the code in there for
esc to close for desktop situations...on mobile, we'll have to check to see
if pressing the esc key on a connected keyboard will close the dialog as
expected.

I see that this particular thread is talking about " Dialog Semantics
" and the solution that is coming out is that of inserting
"role="region"". I am sorry to disagree with the solution given by
Bryan . You see , as far as making modal windows accessible is
concerned Something similar issue came in one of the projects I've
handled. first of all , I've tested what the solution you've given
by inserting code using firebug , and let me tell you that
role="region" is working quite well with JAWS in both firefox / IE,
to that extent it is getting recognized as a landmark , which in my
opinion is not a good idea as far as WAI-ARIA landmark page role
taxonomy is concerned, since if role="region" is supposed to be a
landmark , then why is not recognized as such in w3c documents ?

My Second point is that role ="region" is simply overlooked by NVDA.
So, should we totally overlook Open Source products while suggesting
accessibility solutions to the developers or wait till eternity. Will
Open Source Products catch up fast ?

I guess this is just one instance of discrepancy among the people in
the field of accessibility. Only thing which seems to be common is
we all agree to disagree.

This I guess , is a sorry state of affairs. This is how I will
describe the situation.

<blockquote> Instead of crossing the ocean of Inaccessibility by
travelling in a huge ship of Accessibility under the strong
leadership of W3C, different User Agent Vendors , Corporations ,
Companies manufacturing Assistive Technologies like Screen Reders
etc. are travelling in their own small small boats. You can imagine
and smile at what is bound to happen. Will their be a day when
people industry wide are going to agree and collaborate on atleast
one thing and that is "Accessibility" ? </blockquote>

No worries, I didn't say that role=dialog should never be used, just that
there are keyboard interaction and feedback differences to be aware of,
since this often catches screen reader users off guard.

I recommended role=region because it is supposed to provide beginning and
ending boundary text information feedback for screen reader users, though I
agree, this currently isn't working for NVDA, which there is an open bug
about.

Regardless whether you use either method, it's the content that needs to be
accessible, and the method of rendering that is important here, so when the
dialog is rendered, the background content should be hidden properly, focus
should be set appropriately for keyboard users, the content must all be
accessible in an intuitive manner, the dialog must be closable from the
keyboard, and focus should return to the triggering element after it closes
if a triggering element is present.

I see that this particular thread is talking about " Dialog Semantics "
and the solution that is coming out is that of inserting "role="region"". I
am sorry to disagree with the solution given by Bryan . You see , as far as
making modal windows accessible is concerned Something similar issue came
in one of the projects I've handled. first of all , I've tested what the
solution you've given by inserting code using firebug , and let me tell
you that role="region" is working quite well with JAWS in both firefox /
IE, to that extent it is getting recognized as a landmark , which in my
opinion is not a good idea as far as WAI-ARIA landmark page role taxonomy
is concerned, since if role="region" is supposed to be a landmark , then
why is not recognized as such in w3c documents ?

My Second point is that role ="region" is simply overlooked by NVDA.
So, should we totally overlook Open Source products while suggesting
accessibility solutions to the developers or wait till eternity. Will
Open Source Products catch up fast ?

I guess this is just one instance of discrepancy among the people in the
field of accessibility. Only thing which seems to be common is we all
agree to disagree.

This I guess , is a sorry state of affairs. This is how I will describe the
situation.

<blockquote> Instead of crossing the ocean of Inaccessibility by
travelling in a huge ship of Accessibility under the strong leadership of
W3C, different User Agent Vendors , Corporations , Companies manufacturing
Assistive Technologies like Screen Reders etc. are travelling in their
own small small boats. You can imagine and smile at what is bound to
happen. Will their be a day when people industry wide are going to agree
and collaborate on atleast
one thing and that is "Accessibility" ? </blockquote>

> No worries, I didn't say that role=dialog should never be used, just that
> there are keyboard interaction and feedback differences to be aware of,
> since this often catches screen reader users off guard.
>
> I recommended role=region because it is supposed to provide beginning and
> ending boundary text information feedback for screen reader users, though I
> agree, this currently isn't working for NVDA, which there is an open bug
> about.
>
> Regardless whether you use either method, it's the content that needs to be
> accessible, and the method of rendering that is important here, so when the
> dialog is rendered, the background content should be hidden properly, focus
> should be set appropriately for keyboard users, the content must all be
> accessible in an intuitive manner, the dialog must be closable from the
> keyboard, and focus should return to the triggering element after it closes
> if a triggering element is present.
>
> The rest is just semantics.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ravindra Kumar
> Jain
> Sent: Monday, April 28, 2014 2:12 AM
> To: webaim-forum
> Subject: Re: [WebAIM] Dialog semantics and aria?
>
> Hi List,
>
> I see that this particular thread is talking about " Dialog Semantics "
> and the solution that is coming out is that of inserting "role="region"".
> I
> am sorry to disagree with the solution given by Bryan . You see , as far as
> making modal windows accessible is concerned Something similar issue
> came
> in one of the projects I've handled. first of all , I've tested what the
> solution you've given by inserting code using firebug , and let me tell
> you that role="region" is working quite well with JAWS in both firefox /
> IE, to that extent it is getting recognized as a landmark , which in my
> opinion is not a good idea as far as WAI-ARIA landmark page role taxonomy
> is concerned, since if role="region" is supposed to be a landmark , then
> why is not recognized as such in w3c documents ?
>
> My Second point is that role ="region" is simply overlooked by NVDA.
> So, should we totally overlook Open Source products while suggesting
> accessibility solutions to the developers or wait till eternity. Will
> Open Source Products catch up fast ?
>
> I guess this is just one instance of discrepancy among the people in the
> field of accessibility. Only thing which seems to be common is we all
> agree to disagree.
>
> This I guess , is a sorry state of affairs. This is how I will describe the
> situation.
>
> <blockquote> Instead of crossing the ocean of Inaccessibility by
> travelling in a huge ship of Accessibility under the strong leadership of
> W3C, different User Agent Vendors , Corporations , Companies
> manufacturing
> Assistive Technologies like Screen Reders etc. are travelling in their
> own small small boats. You can imagine and smile at what is bound to
> happen. Will their be a day when people industry wide are going to agree
> and collaborate on atleast
> one thing and that is "Accessibility" ? </blockquote>
>
> I think Mr. Tim Berners Lee will be more than happy that day.
>
> Thanks ,
>
> Ravindra Kumar Jain
> Accessibility Engineer
> http://www.onyadigital.com
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > >

This question would probably be good to ask on the public WAI list, since it
relates to W3C documentation. I suspect the tabindex=0 scenario was added to
account for a dialog that has no other active elements within it, but this
shouldn't be the case in practice for any situation I can think of.

> No worries, I didn't say that role=dialog should never be used, just
> that there are keyboard interaction and feedback differences to be
> aware of, since this often catches screen reader users off guard.
>
> I recommended role=region because it is supposed to provide beginning
> and ending boundary text information feedback for screen reader users,
> though I agree, this currently isn't working for NVDA, which there is
> an open bug about.
>
> Regardless whether you use either method, it's the content that needs
> to be accessible, and the method of rendering that is important here,
> so when the dialog is rendered, the background content should be
> hidden properly, focus should be set appropriately for keyboard users,
> the content must all be accessible in an intuitive manner, the dialog
> must be closable from the keyboard, and focus should return to the
> triggering element after it closes if a triggering element is present.
>
> The rest is just semantics.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ravindra
> Kumar Jain
> Sent: Monday, April 28, 2014 2:12 AM
> To: webaim-forum
> Subject: Re: [WebAIM] Dialog semantics and aria?
>
> Hi List,
>
> I see that this particular thread is talking about " Dialog Semantics "
> and the solution that is coming out is that of inserting "role="region"".
> I
> am sorry to disagree with the solution given by Bryan . You see , as
> far as making modal windows accessible is concerned Something
> similar issue came in one of the projects I've handled. first of all
> , I've tested what the solution you've given by inserting code using
> firebug , and let me tell you that role="region" is working quite well
> with JAWS in both firefox / IE, to that extent it is getting
> recognized as a landmark , which in my opinion is not a good idea as
> far as WAI-ARIA landmark page role taxonomy is concerned, since if
> role="region" is supposed to be a landmark , then why is not
> recognized as such in w3c documents ?
>
> My Second point is that role ="region" is simply overlooked by NVDA.
> So, should we totally overlook Open Source products while suggesting
> accessibility solutions to the developers or wait till eternity. Will
> Open Source Products catch up fast ?
>
> I guess this is just one instance of discrepancy among the people in
> the field of accessibility. Only thing which seems to be common is we
> all agree to disagree.
>
> This I guess , is a sorry state of affairs. This is how I will
> describe the situation.
>
> <blockquote> Instead of crossing the ocean of Inaccessibility by
> travelling in a huge ship of Accessibility under the strong
> leadership of W3C, different User Agent Vendors , Corporations ,
> Companies manufacturing Assistive Technologies like Screen Reders
> etc. are travelling in their own small small boats. You can imagine
> and smile at what is bound to happen. Will their be a day when people
> industry wide are going to agree and collaborate on atleast
> one thing and that is "Accessibility" ? </blockquote>
>
> I think Mr. Tim Berners Lee will be more than happy that day.
>
> Thanks ,
>
> Ravindra Kumar Jain
> Accessibility Engineer
> http://www.onyadigital.com
> > > list messages to = EMAIL ADDRESS REMOVED =
>
> > > list messages to = EMAIL ADDRESS REMOVED =
>
messages to = EMAIL ADDRESS REMOVED =