Re: Dialog behaviour and screen readers

I believe we're still waiting for the results of the ARIA Hackathon from Saturday to be published.
 
Regarding web app behavior on Windows, specific to the use of role=dialog, it causes screen readers like JAWS and NVDA to activate Applications Mode when focus is set within. When JAWS exits AM, all of the background page content remains in the Virtual Buffer and can be interacted with as before, however when NVDA re-activates Browse Mode, it now confines Virtual Buffer navigation within the boundaries of the dialog region as you use the arrow keys to navigate.

On iOS, the dialog region is shown as content using VoiceOver, however the background content remains visible nevertheless.

Within desktop apps only focus is set to the active element that can receive focus, and there is no Virtual 
Buffer in the same manner as the web. Instead JAWS Mode is used in JAWS to navigate via the mouse pointer if you wish granular access to static content within OS dialog panes. This can be seen on standard JavaScript Alert prompts on the web. (alert('Test content goes here');) When an OS modal is opened, the background content cannot be interacted with.

None of these behavioral differences on the web are specifically documented in the spec, but are the interpretation of the UAIG and Roles Model documentation for the platform the AT is running within, so the interaction models are specific to the AT as interpreted within the spec. 

Currently the only way to hide background content for web modal layers across IE,FF, Chrome, and Safari is to use aria-hidden, which works in the latest versions of JAWS, NVDA, and VoiceOver.


  ----- Original Message ----- 
  From: Phill Jenkins 
  To: Ian Sharpe 
  Cc: 'WAI Interest Group' ; Shadi Abou-Zahra 
  Sent: Friday, March 28, 2014 2:25 PM
  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 

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

  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