Re: Dialog behaviour and screen readers

Excellent :)
I see what you mean. This is actually quite simple to do for this particular 
implementation through content.

You can see where in the setup script for the modal at
http://whatsock.com/tsg/Coding%20Arena/Modals/Modal%20(Internal%20Content)/js/setup.js

E.G Changing the line
    role: 'Login',
to use the following instead
    role: 'Login Dialog',
Will change the beginning and boundary text accordingly.

This is also doable programmatically after instantiation via
    $A.reg.myModal.role = 'Whatever Dialog'; // In whatever language.
Please feel free to change the code however you like in the repo if you want 
to experiment with different options.
https://github.com/accdc/tsg

If you want to go the ARIA route instead, you can use role=dialog and 
aria-label on the container so that when focus is set within, the feedback 
of dialog as well as the label text will be announced. This of course comes 
with the before mentioned screen reader keyboard interaction differences to 
be aware of.

I chose not to in this case, because the modal content is variable and may 
have different requirements for different situations, and the standard SR 
web page interaction model was most reliable for dealing with unknown 
content.

Whichever you choose just depends on what you wish to convey and what type 
of content the dialog contains.

Since NVDA added support for toggling between Applications Mode and Browse 
Mode in the last release, many of the prior issues associated with using the 
dialog roles in practice have been negated.

----- Original Message ----- 
From: "Ian Sharpe" <themanxsharpy@gmail.com>
To: "'Bryan Garaventa'" <bryan.garaventa@whatsock.com>
Cc: <w3c-wai-ig@w3.org>
Sent: Monday, March 31, 2014 11:24 AM
Subject: RE: Dialog behaviour and screen readers


> 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?
>
> Cheers
> Ian
>
>
> -----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
> http://whatsock.com/tsg/Coding%20Arena/Modals/Modal%20(Internal%20Content)/d
> emo.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 Monday, 31 March 2014 22:06:53 UTC