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
http://whatsock.com/tsg/Coding%20Arena/Modals/Modal%20(Internal%20Content)/demo.htm

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 
readers.





----- 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
>>
> http://whatsock.com/tsg/Coding%20Arena/Modals/Modal%20(Internal%20Content)/d
>> 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 Saturday, 29 March 2014 21:04:30 UTC