W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2014

Re: Dialog behaviour and screen readers

From: Bryan Garaventa <bryan.garaventa@whatsock.com>
Date: Mon, 31 Mar 2014 15:13:07 -0700
Message-ID: <13F49B0A0D7C43DD8EB45E25E879CAAF@WAMPAS>
To: "Mike Elledge" <melledge@yahoo.com>
Cc: <w3c-wai-ig@w3.org>, "Ian Sharpe" <themanxsharpy@gmail.com>
Thanks :)

If properly programmed, they both work well with modals. E.G When the content loads move focus to the beginning of the content, identify beginning and ending boundaries, ensure that the modal can be closed from the keyboard and includes a triggering element for this purpose with a valid textual equivalent, hide the background content appropriately, return focus to the triggering element after the modal closes if applicable.

  There are a variety of ways to do all of these things, but when done effectively you can have modals that are very accessible and easy to use.

  ----- Original Message ----- 
  From: Mike Elledge 
  To: 'Bryan Garaventa' 
  Cc: w3c-wai-ig@w3.org ; Ian Sharpe 
  Sent: Monday, March 31, 2014 12:11 PM
  Subject: Re: Dialog behaviour and screen readers

  Hi Bryan--

  I enjoyed your presentation Friday afternoon at CSUN. A quick question for clarification: in your opinion, does JAWS 14/15 or NVDA behave most logically for modal dialogs? I wasn't sure...


  On Monday, March 31, 2014 2:24 PM, Ian Sharpe <themanxsharpy@gmail.com> wrote:

  Cheers Brian. That works perfectly now under my setup. The only minor point
  I'd make is that it may not always be apparent a dialog has been displayed
  to the user. How would you suggest modifying either the content, or the
  configuration of the widget, to read the title of the dialog for example,
  followed by "dialog" or maybe prefix the dialog with "alert" if that makes
  more sense in a given context?


  -----Original Message-----
  From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com] 
  Sent: 29 March 2014 21:04
  To: Ian Sharpe
  Cc: w3c-wai-ig@w3.org
  Subject: Re: Dialog behaviour and screen readers

  Hi Ian,
  I've enabled the auto announcement of web based dialog content when first
  rendered by setting "announce:true" within the setup file, so it should now
  be working correctly.

  This can be seen at the same location

  After activating the Login button, it will open the modal, and focus will be
  set to the beginning of the modal content and the content will be announced
  automatically. That was a good idea, and thank you for pointing it out. 
  Tabbing forward and backward within the modal will cause circular tabbing to
  move only within the boundary of the modal.

  The reason why auto announcement doesn't work on jQuery UI or on the Dojo
  Digits demo, is because the role of dialog does not enable this
  functionality, and it's not actually specified in the UAIG spec to fire a
  relevant event for this. The role of alertdialog is supposed to represent
  this type of functionality, but it's not equally supported across screen

  ----- Original Message -----
  From: "Ian Sharpe" <themanxsharpy@gmail.com>
  To: "'Bryan Garaventa'" <bryan.garaventa@whatsock.com>
  Sent: Saturday, March 29, 2014 10:07 AM
  Subject: RE: Dialog behaviour and screen readers

  > Hey Brian
  > I think I may have given you a bum steer. When I opened up the link you 
  > sent
  > in my browser, I was presented with the login controls. I assumed that 
  > this
  > is all that was on the page. When I clicked OK, I was presented with what 
  > I
  > now believe is the native alert dialog displayed by FF displaying a
  > validation warning - "Woopse! You seem to have forgotten to enter your
  > password" or something like that. My comments were with respect to this
  > dialog. How funny.
  > Anyway, having realised my mistake, I've looked again at the login dialog
  > which works fine and does allow me to use browse mode to access the 
  > content
  > of the dialog. My only criticism in comparison with the jQuery dialog, is
  > that under my setup, NVDA does not read anything automatically when I 
  > click
  > the "login" button to display the dialog. I hear nothing. I've tested the
  > jQuery dialog and this reads through the content as soon as the dialog is
  > displayed. Is the dialog read out automatically for you?
  > Apologies for the confusion.
  > Cheers
  > Ian
  > -----Original Message-----
  > From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
  > Sent: 29 March 2014 01:17
  > To: Ian Sharpe; w3c-wai-ig@w3.org
  > Subject: Re: Dialog behaviour and screen readers
  > Thanks for the feedback, that's strange about insert+space in NVDA, which
  > version are you running? The new release of NVDA came out a couple of 
  > weeks
  > ago, and is 2014.1.
  > I understand your point about the WhatSock sample not announcing the 
  > content
  > when focus moves within, however there is no role=dialog, so you can use
  > Browse Mode to arrow down the page, and the background content is hidden 
  > via
  > aria-hidden=true, so you will never encounter the obscured content on the
  > page.
  > Is Browse Mode not activating? Is this in Firefox?
  > Thanks,
  > Bryan
  > ----- Original Message -----
  > From: "Ian Sharpe" <themanxsharpy@gmail.com>
  > To: "'Bryan Garaventa'" <bryan.garaventa@whatsock.com>; 
  > <w3c-wai-ig@w3.org>
  > Sent: Friday, March 28, 2014 5:12 PM
  > Subject: RE: Dialog behaviour and screen readers
  >> Hi Brian
  >> I've just taken a look at your dialog which also works well, albeit a
  >> little
  >> differently from the jQuery dialog sited. Your dialog doesn't prevent the
  >> user from tabbing out of the dialog, allowing the user to tab between
  >> toolbars before returning back to the web page. And when focus does 
  >> return
  >> to the web page, it is returned to the dialog which is spoken again.
  >> Personally I feel this is a better user experience in the context of a
  >> browser (as opposed to in the context of a native application) but
  >> retaining
  >> focus in the dialog when it is opened also has merrit. Or at least it
  >> would
  >> if there was a way to have the dialog spoken again, which isn't happening
  >> for me.
  >> The one issue I have with your dialog is that although the dialog is
  >> spoken
  >> again when you tab back into it from the toolbar for example, SHIT+TAB
  >> from
  >> the OK button just says "label", that's it. So the only way to hear the
  >> dialog again is to tab away from the dialog, round the toolbars and back
  >> to
  >> the browser window.
  >> I'm using NVDA 2013.3, Win 7 x64 and FF 27.0.1 and your suggestion of
  >> using
  >> insert/NVDA modifier key + space has no affect.
  >> Cheers
  >> Ian
  >> -----Original Message-----
  >> From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
  >> Sent: 28 March 2014 21:03
  >> To: w3c-wai-ig@w3.org
  >> Subject: Re: Dialog behaviour and screen readers
  >> If I may ask, can you tell me which issues you've noticed with the modal
  >> at
  >> emo.htm
  >> I'm always looking to improve the widgets.
  >> ----- Original Message -----
  >> From: "Ian Sharpe" <themanxsharpy@gmail.com>
  >> To: "'WAI Interest Group'" <w3c-wai-ig@w3.org>
  >> Sent: Friday, March 28, 2014 1:40 PM
  >> Subject: Dialog behaviour and screen readers
  >>> Hi
  >>> Dialogs have always been, and continue to be, an issue when using a
  >>> screen
  >>> reader, with many implementations across the wide variety of widget
  >>> toolkits
  >>> of varying quality.
  >>> The best implementation I've seen so far is the Jquery UI dialog at:
  >>> https://jqueryui.com/dialog/#modal
  >>> This works very well for the most part, reading the dialog text and only
  >>> allowing navigation within the dialog using NVDA with FF. However, if I
  >>> interrupt speech before NVDA has read all the text, or if I want to
  >>> listen
  >>> to the content again once the content has been read, there doesn't seem
  >>> to
  >>> be any way for me to access the content again, short of cancelling the
  >>> dialog and triggering it again that is.
  >>> Is there a reference implementation for this problem anywhere?
  >>> Is it simply a case of adding tabindex="0" to the title and content of
  >>> the
  >>> dialog sited above to enable the content to be accessed again?
  >>> Cheers
  >>> Ian
Received on Monday, 31 March 2014 22:13:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:47 UTC