E-mail List Archives
Thread: Info widgets with role="dialog"
Number of posts in this thread: 15 (In chronological order)
From: Detlev Fischer
Date: Tue, Jan 20 2015 2:50AM
Subject: Info widgets with role="dialog"
No previous message | Next message →
Hi,
I wonder whether there is consensus in the community, especially among screen reader users, whether modal pop-ups that contain non-form elements such as tab panels, data tables with information etc. should be marked up as dialog.
My understanding is that the dialog role pushes screen readers into a quasi-forms mode which means that content that is not focusable may not be read without the user manually switching back to reader mode.
This means that a widget that may be predominantly a form (e.g. with several text inputs, selects, checkboxes etc.) but ALSO contains some other elements (e.g. a text "Assign owner: [current owner]" followed by a link "change") may be missed when the widget is traversed in the default mode triggered by opening a widget with role=dialog. (Or here, "change" may be read but the context is not clear). I understand that the aria-labelledby and aria-describedby attributes do not work reliably on links so they cannot be used to render non-focusable content in a way that it will be read by default.
My three questions are:
1. When calling up a dialog, will screen reader users generally know / expect that they (may) have to switch to a reader mode to reach non-focusable content?
2. If 1 is answered in the negative, should info-widgets better NOT be given role=dialog unless all content can be tied to the element containing the dialog role or to focusable elements within the dialog via aria-labelledby or aria-describedby (or via accessibly hidden extra link text)?
3. Is adding tabindex=0 to ensure that usually non-focusable content is read a good practice to solve this particular problem?
Best,
Detlev
-
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg
Mobil +49 (0)1577 170 73 84
Tel +49 (0)40 439 10 68-3
Fax +49 (0)40 439 10 68-5
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
From: Steve Faulkner
Date: Tue, Jan 20 2015 2:58AM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
this article by gez is useful
http://juicystudio.com/article/custom-built_dialogs.php
I suggest in the case of dialogs with lots of text content you nest an
element with role=document , this indicates to the AT that they should
switch to reading mode.
--
Regards
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
On 20 January 2015 at 09:50, Detlev Fischer < = EMAIL ADDRESS REMOVED = >
wrote:
>
> Hi,
>
> I wonder whether there is consensus in the community, especially among
> screen reader users, whether modal pop-ups that contain non-form elements
> such as tab panels, data tables with information etc. should be marked up
> as dialog.
>
> My understanding is that the dialog role pushes screen readers into a
> quasi-forms mode which means that content that is not focusable may not be
> read without the user manually switching back to reader mode.
> This means that a widget that may be predominantly a form (e.g. with
> several text inputs, selects, checkboxes etc.) but ALSO contains some other
> elements (e.g. a text "Assign owner: [current owner]" followed by a link
> "change") may be missed when the widget is traversed in the default mode
> triggered by opening a widget with role=dialog. (Or here, "change" may be
> read but the context is not clear). I understand that the aria-labelledby
> and aria-describedby attributes do not work reliably on links so they
> cannot be used to render non-focusable content in a way that it will be
> read by default.
>
> My three questions are:
>
> 1. When calling up a dialog, will screen reader users generally know /
> expect that they (may) have to switch to a reader mode to reach
> non-focusable content?
> 2. If 1 is answered in the negative, should info-widgets better NOT be
> given role=dialog unless all content can be tied to the element containing
> the dialog role or to focusable elements within the dialog via
> aria-labelledby or aria-describedby (or via accessibly hidden extra link
> text)?
> 3. Is adding tabindex=0 to ensure that usually non-focusable content is
> read a good practice to solve this particular problem?
>
> Best,
> Detlev
> -
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
> > > >
From: Jared Smith
Date: Tue, Jan 20 2015 2:14PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
Detlev Fischer wrote:
> I wonder whether there is consensus in the community, especially among screen reader users, whether modal pop-ups that contain non-form elements such as tab panels, data tables with information etc. should be marked up as dialog.
Consensus? From the accessibility community? Ha, ha! :-)
The ARIA specification states: "A dialog is an application window that
is designed to interrupt the current processing of an application in
order to prompt the user to enter information or require a response."
The key here is that a dialog is an *application window*. This
generally means that the diaIog contains application elements -
primarily form controls for input. If the pop-up is instead a *content
dialog*, then it shouldn't be marked up as a dialog.
A problem is that all scripting libraries that support dialog roles do
not provide any differentiation - all pop-ups are marked up as
application dialogs regardless of their nature. I think it's possible
that the majority of dialogs on the web shouldn't be marked up as
dialogs at all.
> 1. When calling up a dialog, will screen reader users generally know / expect that they (may) have to switch to a reader mode to reach non-focusable content?
My experience has been that they very often do not know this. Many
users don't even know how to switch modes.
> 2. If 1 is answered in the negative, should info-widgets better NOT be given role=dialog
If the pop-up is an info-widget and not an application dialog (it
presents content, not application controls), then it should not be
given role=dialog.
But often a true dialog has a mix of application controls AND content.
In these cases, as Steve suggested, you should use role=document on
the non-application stuff. This, however, does not always mean the
user will readily be able to locate or read it because they will
generally be tabbing within the dialog and skipping over the
non-application stuff regardless.
> 3. Is adding tabindex=0 to ensure that usually non-focusable content is read a good practice to solve this particular problem?
Not good practice, but it may suffice. Tabable (I'm not sure that is
even a word) elements inherently indicate that they are actionable.
Allowing navigation focus to an element that cannot receive input or
activation can be confusing. With that said, it can be *more*
confusing if important content is bypassed. I have seen tabindex=0
used in places where there was no other reasonable method of providing
access to *important* non-actionable information (such as vital
instructions within a form) within a navigation flow.
Jared
From: Roger Hudson
Date: Tue, Jan 20 2015 2:40PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
Thanks Detlev and Jared for your concise and useful info about this problem
which I am seeing more and more.
Roger
From: Birkir R. Gunnarsson
Date: Wed, Jan 21 2015 9:37AM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
The ARIA authoring spec recommends role="document" on static text as
well as tabindex="0" to make sure infomration stays in focus order
http://www.w3.org/TR/wai-aria-practices/#alertdialog
Actually there is an NVDA bug, which I have to file, .. when the
message area of a dialog has role document, NVDA will disregard the
aria-describebby attribute that points to it .. simply removing
role="document" causes NVDA to automatically read the message again.
Cheers
On 1/20/15, Roger Hudson < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks Detlev and Jared for your concise and useful info about this problem
> which I am seeing more and more.
> Roger
>
>
From: Jared Smith
Date: Wed, Jan 21 2015 11:04AM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
Birkir R. Gunnarsson wrote:
> The ARIA authoring spec recommends role="document" on static text as
> well as tabindex="0" to make sure infomration stays in focus order
Interesting. I'm not quite sure I agree with the suggestion that a
simple message dialog be given the dialog role and the message itself
role=document and tabindex=0. It seems much easier and more intuitive
to simply NOT give the pop-up role="dialog" and allow the natural
reading process of the screenreader to access the text message.
Of course doing has the possibility that the user would hit Tab and
bypass the message altogether. On the other hand, using role="dialog"
and tabindex has the potential for confusion because of the
intermingling of the focusable message that isn't interactive and
other application elements that are.
Either approach has disadvantages and potential for confusion. Without
user data, I think I must (rather reluctantly) favor the documented
recommendations in the spec - role=dialog for all pop-ups and
role=document and tabindex on all non-application stuff within them.
Jared
From: Bryan Garaventa
Date: Wed, Jan 21 2015 12:21PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
There's an important note that I need to make, that describing the Authoring Guide at
http://www.w3.org/TR/wai-aria-practices/
as an "ARIA authoring spec" is actually incorrect, since this is not a spec, but just a best practices guide that we are in the
process of re-editing for better clarity and more comprehensive usage patterns. None of the patterns listed there are spec
requirements, and some have open bugs against them that we are currently addressing.
From: Birkir R. Gunnarsson
Date: Wed, Jan 21 2015 12:39PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
Sorry Bryan, bad wording on my part there.
Yes, myself, Bryan and others are hard at work revising the ARIA
authoring guidelines, so comments such as those made here will surely
make their way into those discussions and that process, so people's
feedback and concerns are always welcome and duely noted.
Jared, I totally see what you are saying, generally putting focus on
an html element that has no interactive functionality is confusing and
can do more harm than good.
To some extent, we should be more aggressive about help teaching users
how to switch between modes in screen readers that offer that
functionality.
Also make sure that screen readers that operate this way actually
switch to browse mode when focus lands on an element with role
document, .. not always the case today.
Cheers
-Birkir
On 1/21/15, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> There's an important note that I need to make, that describing the Authoring
> Guide at
> http://www.w3.org/TR/wai-aria-practices/
> as an "ARIA authoring spec" is actually incorrect, since this is not a spec,
> but just a best practices guide that we are in the
> process of re-editing for better clarity and more comprehensive usage
> patterns. None of the patterns listed there are spec
> requirements, and some have open bugs against them that we are currently
> addressing.
>
>
>
From: _mallory
Date: Wed, Jan 21 2015 2:28PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
Maybe serious thought should be made to the idea of a "popup".
Sighted users just know when they hit one and don't care if it's
got forms, text, links, or an annoying animated gif of a cat.
As far as they're concerned, a "popup" dialog is something that
forces their attention and prevents them from interacting with the
rest of the page until they close it.
It would be nice if "dialog" meant this, instead of "dialog but only
dialogs with forms in them". Not what web developers think when
one says "dialog" at all. They think "that thing browsers pop up
like javascript alerts or browser chrome stating something died".
Can this be, like, back-pedaled and rethought so it can go back
to something more practical? We merely want
-users to be interupted from the page
-forced to view with and deal with the popup
-after closing, be exactly back where they were
and not care what the content inside was.
_mallory
On Wed, Jan 21, 2015 at 02:39:37PM -0500, Birkir R. Gunnarsson wrote:
> Sorry Bryan, bad wording on my part there.
> Yes, myself, Bryan and others are hard at work revising the ARIA
> authoring guidelines, so comments such as those made here will surely
> make their way into those discussions and that process, so people's
> feedback and concerns are always welcome and duely noted.
> Jared, I totally see what you are saying, generally putting focus on
> an html element that has no interactive functionality is confusing and
> can do more harm than good.
> To some extent, we should be more aggressive about help teaching users
> how to switch between modes in screen readers that offer that
> functionality.
> Also make sure that screen readers that operate this way actually
> switch to browse mode when focus lands on an element with role
> document, .. not always the case today.
>
> Cheers
> -Birkir
>
From: Birkir R. Gunnarsson
Date: Wed, Jan 21 2015 2:12PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
Well, basically role alertdialog (plus making sure rest of content is
hidden and keyboard focus is trapped) serves this exact purpose.
On 1/21/15, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
> Maybe serious thought should be made to the idea of a "popup".
>
> Sighted users just know when they hit one and don't care if it's
> got forms, text, links, or an annoying animated gif of a cat.
>
> As far as they're concerned, a "popup" dialog is something that
> forces their attention and prevents them from interacting with the
> rest of the page until they close it.
>
> It would be nice if "dialog" meant this, instead of "dialog but only
> dialogs with forms in them". Not what web developers think when
> one says "dialog" at all. They think "that thing browsers pop up
> like javascript alerts or browser chrome stating something died".
>
> Can this be, like, back-pedaled and rethought so it can go back
> to something more practical? We merely want
> -users to be interupted from the page
> -forced to view with and deal with the popup
> -after closing, be exactly back where they were
>
> and not care what the content inside was.
>
> _mallory
>
> On Wed, Jan 21, 2015 at 02:39:37PM -0500, Birkir R. Gunnarsson wrote:
>> Sorry Bryan, bad wording on my part there.
>> Yes, myself, Bryan and others are hard at work revising the ARIA
>> authoring guidelines, so comments such as those made here will surely
>> make their way into those discussions and that process, so people's
>> feedback and concerns are always welcome and duely noted.
>> Jared, I totally see what you are saying, generally putting focus on
>> an html element that has no interactive functionality is confusing and
>> can do more harm than good.
>> To some extent, we should be more aggressive about help teaching users
>> how to switch between modes in screen readers that offer that
>> functionality.
>> Also make sure that screen readers that operate this way actually
>> switch to browse mode when focus lands on an element with role
>> document, .. not always the case today.
>>
>> Cheers
>> -Birkir
>>
> > > >
--
Work hard. Have fun. Make history.
From: Jonathan Avila
Date: Wed, Jan 21 2015 2:21PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
> making sure rest of content is
hidden
That's easier said then done because some dialogs appear inline and setting aria -hidden to true on the page but then aria-hidden false on the dialog is not supported by browsers- then all content is hidden. I suppose some query selected could be used to apply it to all other elements in the page but that is overkill
Jonathan
Sent from my iPhone
> On Jan 21, 2015, at 4:13 PM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> making sure rest of content is
> hidden
From: Jonathan Avila
Date: Wed, Jan 21 2015 2:28PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
There is also a difference between a popup and a modal. A modal requires your attention while a popup may not. Some sites use pop ups to alert you to chat but don't force your interaction I would support better ARIA semantics for these.
Jonathan
> On Jan 21, 2015, at 4:07 PM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
> Maybe serious thought should be made to the idea of a "popup".
>
> Sighted users just know when they hit one and don't care if it's
> got forms, text, links, or an annoying animated gif of a cat.
>
> As far as they're concerned, a "popup" dialog is something that
> forces their attention and prevents them from interacting with the
> rest of the page until they close it.
>
> It would be nice if "dialog" meant this, instead of "dialog but only
> dialogs with forms in them". Not what web developers think when
> one says "dialog" at all. They think "that thing browsers pop up
> like javascript alerts or browser chrome stating something died".
>
> Can this be, like, back-pedaled and rethought so it can go back
> to something more practical? We merely want
> -users to be interupted from the page
> -forced to view with and deal with the popup
> -after closing, be exactly back where they were
>
> and not care what the content inside was.
>
> _mallory
>
>> On Wed, Jan 21, 2015 at 02:39:37PM -0500, Birkir R. Gunnarsson wrote:
>> Sorry Bryan, bad wording on my part there.
>> Yes, myself, Bryan and others are hard at work revising the ARIA
>> authoring guidelines, so comments such as those made here will surely
>> make their way into those discussions and that process, so people's
>> feedback and concerns are always welcome and duely noted.
>> Jared, I totally see what you are saying, generally putting focus on
>> an html element that has no interactive functionality is confusing and
>> can do more harm than good.
>> To some extent, we should be more aggressive about help teaching users
>> how to switch between modes in screen readers that offer that
>> functionality.
>> Also make sure that screen readers that operate this way actually
>> switch to browse mode when focus lands on an element with role
>> document, .. not always the case today.
>>
>> Cheers
>> -Birkir
> > >
From: Birkir R. Gunnarsson
Date: Wed, Jan 21 2015 2:33PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
Yes, this is true.
Putting the dialog in a div separate from all othe content on the page
and using aria-hidden on that content when dialog pops ups is a bit of
a workaround and does not always work as expected.
Ultimately, we are hoping the html5 <dialog> tag will accessibly
emerge from the depths of the browser implementation phase, and
deligate the majority of the implementation complexities to the
browser.
On 1/21/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> making sure rest of content is
> hidden
>
> That's easier said then done because some dialogs appear inline and setting
> aria -hidden to true on the page but then aria-hidden false on the dialog is
> not supported by browsers- then all content is hidden. I suppose some
> query selected could be used to apply it to all other elements in the page
> but that is overkill
>
> Jonathan
>
> Sent from my iPhone
>
>> On Jan 21, 2015, at 4:13 PM, Birkir R. Gunnarsson
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> making sure rest of content is
>> hidden
> > > >
--
Work hard. Have fun. Make history.
From: Bryan Garaventa
Date: Wed, Jan 21 2015 3:31PM
Subject: Re: Info widgets with role="dialog"
← Previous message | Next message →
This is something I've already brought up
http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0095.html
So it's already on the radar.
From: _mallory
Date: Wed, Jan 21 2015 11:54PM
Subject: Re: Info widgets with role="dialog"
← Previous message | No next message
On Wed, Jan 21, 2015 at 09:28:29PM +0000, Jonathan Avila wrote:
> There is also a difference between a popup and a modal. A modal requires your attention while a popup may not. Some sites use pop ups to alert you to chat but don't force your interaction I would support better ARIA semantics for these.
>
> Jonathan
Mm I said popup but that's a bad word, hint text and in-page chat
applications count as popups but not modals.
_mallory