Re: [orca-list] Firefox, orca and aria dialogs
- From: Joanmarie Diggs <jdiggs igalia com>
- To: Peter Vágner <pvdeejay gmail com>
- Cc: Nolan Darilek <nolan thewordnerd info>, orca-list <orca-list gnome org>
- Subject: Re: [orca-list] Firefox, orca and aria dialogs
- Date: Fri, 1 Dec 2017 18:32:01 -0500
Hey Peter.
I just added a hackaround to Orca master for the issue in which Nolan's
example case isn't fully presented subsequent times the dialog appears.
I am hoping that it also solves your other problems. I'll try to look at
them this weekend -- unless I don't have to because they are solved.
<smile> Mind re-testing?
On a different note, something else wrong with Firefox's JavaScript
alerts: https://bugzilla.mozilla.org/show_bug.cgi?id=1422424
--joanie
On 12/01/2017 01:16 PM, Peter Vágner wrote:
Hello,
Now I have realized I need to explain this in more details with steps to
reproduce.
There are several possible implementations. People tend to workaround
screen vs AT issues by placing focus on the container dialog element. This
is a sort of thing I'm trying to avoid.
Please load this in firefox and follow along
https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html
- Locate Add delivery address and activate it either by pressing spacebar
or an enter key.
- There is no description associated with this dialog (no aria-describedby
on the container element with role=dialog) and focus is placed into the
entry text labelled as streed. This dialog is working fine and does not
exhibit the issue I'm having.
- Keep pressing the tab key repeatedly until you land on Verify address and
press the space bar to activate
- The dialog pops up and the context is reported. However this also does
not exhibit my issue as the author placed focus to the container dialog
element. Yes they are explaining that they are placing focus to the dialog
not to first focusable element because of scrolling issues so they have a
valid use case but again it's different to mine.
- Close this second dialog by pressing the esc key. You will land on the
verify address button again.
- Now press the tab key to move on to the Add button and activate it with
the enter key or the space bar key.
- Now things start to be interesting as this dialog is very similar in
nature to what I'm trying to do. The dialog has a label and a description
associated via corresponding aria tags and the focus is moved to the OK
button as the dialog shows up. When this dialog appears for the first time
orca presents its label followed by the presentation of the OK button. When
this dialog is inwoked for the second, third or even more times no label
and no description is presented. OK button is presented only.
Now load this other page:
http://davidtheclark.github.io/react-aria-modal/demo/
Examples 1, 2, 4, 6 are similar to what I am expecting and they are failing
in the same way as I have just described.
Examples 3 and 5 are focusing the container dialog and they are not working
the way I'm expecting here.
The example proposed by Nolan at
https://gdkraus.github.io/accessible-modal-dialog/ is exhibiting the issue
the way I have described. When activating the dialog for the first time it
works correctly. When activating it multiple times second and other popups
only report the button failing to report the dialog title and the dialog
description.
Thanks and greetings
Peter
2017-12-01 18:02 GMT+01:00 Joanmarie Diggs <jdiggs igalia com>:
Hi Nolan.
When you say works just fine, do you mean with Orca? Or that it works
just fine with NVDA but not with Orca? (I ask because you replied to my
email asking for dialogs which work with NVDA but not Orca.)
--joanie
On 12/01/2017 11:42 AM, Nolan Darilek wrote:
Here's a good accessible modal/dialog that at first glance seems to work
just fine:
https://gdkraus.github.io/accessible-modal-dialog/
On 12/01/2017 10:00 AM, Joanmarie Diggs wrote:
Hi Peter.
I'll look into the alert issue as that surprises me. If you have a
concrete test case which works as expected with NVDA and not with Orca,
please provide it with a list of steps to reproduce the problem.
Thanks!
--joanie
On 12/01/2017 10:25 AM, Peter Vágner wrote:
Hello,
I have spent some two days trying to create a working accessible dialog
using React JS for the riot.im web based matrix client.
I would like this dialog to:
- Have title, description, one or more buttons.
- move focus to the primary button when it shows
- be fully reported when used with a screen reader.
To be fully reported when used with a screen reader means that its
title
and its description should be announced via text to speech and / or
presented in braille as appropriate.
The dialog is created as a div element within a DOM subtree. The
container
element has aria-labelledby and aria-describedby pointing to other
nodes
where there is the dialog label and a description inside. These nodes
are
another divs with some text inside.
When the dialog is created focus is automatically placed to the
appropriate
button by calling the focus() method on a corresponding DOM node.
This is created using React so visibility is not manipulated nor
aria-hidden is used. It is loaded asynchronously using webpack and then
rendered into the DOM the way Reac does its magic.
Results: the dialog title (content that is associated with a dialog
element
via aria-labelledby) is read correctly. However the description is not.
Originally I have assumed this might be a problem on my part as I have
found out if I try to render multiple such dialogs one after the
other the
second instance is read correctly with orca.
Additionally I have found out one accessible test case here:
http://www.oaa-accessibility.org/example/2/
So I have tried to get an inspiration from that, rewrote my react
component
in a way that it creates a hidden dialog, it then shows it and finally
moves the focus but still this is not working like it should. Only the
dialog title is reported for me when focusing into such dialog.
Finally I have discovered all dialog windows are not reported with
Firefox
57 and Orca or Firefox 59 and Orca.
Even simple alert("blablabla"); that is under a browser control is not
reported correctly by orca.
Can you please test out possible aria dialogs on the web or inside some
real apps and help me to find a clue?
I am afraid something is wrong with Firefox vs at-spi vs orca
interaction,
but I am unable to find that out.
Greetings
Peter
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/
gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]