RE: Dialog behaviour and screen readers

Hi Phil
When a native dialog opens on Windows, NVDA reads sequencially through the
dialog and places focus on the first focussable item as Brian stated. Using
a modifier key combination (NVDA+B) causes NVDA to speak the content from
the top of the dialog again. It is also possible to use a different
presentation model (screen review) to review the text while focussed on a
button for example.
My understanding is that screen review wouldn't work in this context but I'm
sure it would be possible for screen readers in general to map the same
hotkey for reading native dialogs in the context of an HTML / JS dialog.
Really, it should be possible to simply use browse mode to up and down arrow
through the content, but clearly the behaviour induced by role="dialog" is
preventing this functionality.
  _____  

The dojo dialogs I've just tried behave like the jQuery examples.
 Cheers
Ian From: Phill Jenkins [mailto:pjenkins@us.ibm.com] 
Sent: 28 March 2014 21:25
To: Ian Sharpe
Cc: 'WAI Interest Group'; Shadi Abou-Zahra
Subject: Re: Dialog behaviour and screen readers


Could you also share the desired, or perhaps more importantly, the current
behavior with desk-top Windows modal dialogs?   
        
Understanding how JAWS or NVDA (versions please) behaves with Windows (and
version please) desktop implementations can give us better insight into what
is the browser's responsibility, verses the web page (UI Toolkit)
responsibility, verses the screen reader's responsibility, verses the end
user's settings (or configuration). 

I thought I heard at CSUN 2014 from Shadi that there was an effort to
publish techniques with an ability to document behavior findings by
platform, browser, and AT.  Seems to me that a modal dialog would be a good
candidate for the effort, but I can't seem to find the effort on the
highlights archive: 
         <http://www.w3.org/WAI/highlights/archive>
http://www.w3.org/WAI/highlights/archive 

and any difference with DoJo's modal implementation? see
<http://livedocs.dojotoolkit.org/dijit/Dialog>
http://livedocs.dojotoolkit.org/dijit/Dialog 
____________________________________________
Regards,
Phill Jenkins, 
IBM Research - Human Ability & Accessibility Center
 <http://www.ibm.com/able> http://www.ibm.com/able
 <http://www.facebook.com/IBMAccessibility>
http://www.facebook.com/IBMAccessibility
 <http://twitter.com/IBMAccess> http://twitter.com/IBMAccess
 <http://www.linkedin.com/in/philljenkins>
http://www.linkedin.com/in/philljenkins 



From:        "Ian Sharpe" <themanxsharpy@gmail.com> 
To:        "'WAI Interest Group'" <w3c-wai-ig@w3.org>, 
Date:        03/28/2014 03:45 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> 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