Re: Dialog behaviour and screen readers

A slight correction about behavior for dialog roles, in JAWS 12 and 13, this would act as NVDA did, and restrict keyboard interaction to the active element only. However in 14 and 15, this is no longer the case, and maintains the Virtual Buffer as a standard web page.
 
In contrast, the role of application in JAWS 12 and 13 did nothing, but in 14 and 15, causes Applications Mode to become activated when focus is set within.

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