E-mail List Archives

Search E-mail List Archives for

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

-----Original Message-----
From: Jared Smith [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, 21 January 2015 8:14 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Info widgets with role="dialog"

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
messages to = EMAIL ADDRESS REMOVED =

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
>
> -----Original Message-----
> From: Jared Smith [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, 21 January 2015 8:14 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Info widgets with role="dialog"
>
> 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
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > >


--
Work hard. Have fun. Make history.

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.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: Wednesday, January 21, 2015 10:04 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Info widgets with role="dialog"

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: 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.
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
> Sent: Wednesday, January 21, 2015 10:04 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Info widgets with role="dialog"
>
> 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
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > >


--
Work hard. Have fun. Make history.

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.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of _mallory
Sent: Wednesday, January 21, 2015 1:29 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Info widgets with role="dialog"

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: _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