Post by Sean Murphy (seanmmur)The other one I have been informed about is combo boxes in chrome v70 do not support alt down arrow to open the drop down items. You have to press enter.
I have Chrome 70.0.3538.110 on Windows and alt+down works with JAWS, NVDA, and without a screen reader to open the standard select element (combo box).
Jonathan
-----Original Message-----
From: Sean Murphy (seanmmur) <***@cisco.com>
Sent: Sunday, December 2, 2018 6:05 PM
To: Steve Green <***@testpartners.co.uk>; w3c-wai-***@w3.org
Subject: RE: ARIA and Jaws question
All,
One web page I have seen is Chrome shows a table while Firefox does not. I have not yet looked to see why there is an difference. The other one I have been informed about is combo boxes in chrome v70 do not support alt down arrow to open the drop down items. You have to press enter.
I only started looking for these after this conversation has started. :-)
Sean Murphy
SR ENGINEER.SOFTWARE ENGINEERING
***@cisco.com
Tel: +61 2 8446 7751
Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html
-----Original Message-----
From: Steve Green <***@testpartners.co.uk>
Sent: Monday, 3 December 2018 1:50 AM
To: w3c-wai-***@w3.org
Subject: RE: ARIA and Jaws question
I can't think of any right now. They are usually things that are out of scope in my testing so I don't investigate or record them. I assume they are issues with the browser's accessibility tree or API because they are specific to Chrome.
To turn the question round, can you describe anything that Chrome does better than Internet Explorer or Firefox in relation to screen reader behaviour?
There may be some orthodoxy in people's thinking if they don't do any formal testing. But even those of us who do formal testing can only comment on the websites we have tested, so it's quite possible we will have different experiences from each other.
Steve
-----Original Message-----
From: Adam Cooper <***@bigpond.com>
Sent: 02 December 2018 00:13
To: Steve Green <***@testpartners.co.uk>; w3c-wai-***@w3.org
Subject: RE: ARIA and Jaws question
"My reasoning is that Chrome exhibits far more adverse behaviours than either Internet Explorer or Firefox"
Are you able to describe these 'adverse behaviours'? Are they about the browser or the screen reader?
As an everyday screen reader user, I find Internet Explorer 11 the most problematic followed by Firefox and then Chrome.
In my view, Firefox and Chrome work equally well with NVDA.
Just wondering how much of the thinking about the interoperability of browsers and screen readers is orthodoxy?
Cheers,
Adam
-----Original Message-----
From: Steve Green [mailto:***@testpartners.co.uk]
Sent: Thursday, November 29, 2018 1:07 PM
To: w3c-wai-***@w3.org
Subject: RE: ARIA and Jaws question
My reasoning is that Chrome exhibits far more adverse behaviours than either Internet Explorer or Firefox. Until recently, Chrome was not usable at all with JAWS, and they are still catching up. I cannot think of any occasion where it has performed better than the other browsers - it's either the same or worse.
I rarely experience any problems with Internet Explorer, but I only use JAWS for testing websites, not for everyday use. For the most part I find Internet Explorer works at least as well as Firefox, although it is lacking in support for some of the newer HTML elements and attributes.
I agree with you regarding the need for baked-in controls, with the caveat that browsers must allow them to be styled as designers wish. If that doesn't happen, and you can almost guarantee that Safari won't, the new controls won't be used. The same applies to existing elements - if you could style radio buttons, checkboxes and comboboxes any way you want, we wouldn't have all the terrible replacement techniques that most developers (and especially JavaScript framework developers) get wrong.
I have yet to see a complex widget implemented in an accessible manner. Some are theoretically accessible if you understand the interaction model, ensure your screen reader is in the correct mode and don't accidentally press the wrong key. I don't regard that as acceptable, but it's as good as it gets right now.
Steve
-----Original Message-----
From: Sean Murphy (seanmmur) <***@cisco.com>
Sent: 29 November 2018 00:52
To: Steve Green <***@testpartners.co.uk>; w3c-wai-***@w3.org
Subject: RE: ARIA and Jaws question
Steve,
Interested in your reasoning why those Jaws users who are using Chrome are not doing themselves any favour. As a Jaws user, I avoid IE11 now due to stability issues and I am now finding strange behaviours when Jaws worked with a page with no modifications in the past and does not now. While Firefox works fine.
I use Firefox and Chrome, and do see different behaviour with Jaws and NVDA using the same web sites. This is why I come back to my prior post on another list where more controls like combo boxes, treeviews, etc must be baked into the browser and the HTML 5.2 standards. Saves a lot of hacks I see to make these complex widgets work.
Sean Murphy
SR ENGINEER.SOFTWARE ENGINEERING
***@cisco.com
Tel: +61 2 8446 7751
Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html
-----Original Message-----
From: Steve Green <***@testpartners.co.uk>
Sent: Thursday, 29 November 2018 12:57 AM
To: w3c-wai-***@w3.org
Subject: RE: ARIA and Jaws question
I can't suggest how to fix this without seeing the code, but Chrome exhibits lots of incorrect behaviours that don't occur with Internet Explorer and Firefox. The last WebAIM screen reader survey showed that only 6.5% of screen reader users were using JAWS and Chrome, and frankly those people are not doing themselves any favours.
https://webaim.org/projects/screenreadersurvey7/#browsercombos
There are other gotchas with respect to non-editable textboxes. The last time I tested read-only fields, Dragon 15 (which is still the latest version) was able to edit them. A proposed workaround was to change the textboxes to "disabled", but that introduced new problems because they now don't receive focus. If a screen magnifier user is using keyboard navigation, it will skip right past the disabled textboxes and the user won't even know they are there. That's not always a problem but it was in our case because it was a timesheet application where the user needed to review and approve all the data even though they could not change it.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: Ginger Claassen <***@gmx.de>
Sent: 28 November 2018 13:16
To: w3c-wai-***@w3.org
Subject: ARIA and Jaws question
Good Morning everyone,
We currently have a web application here where some non editable text entry fields are correctly marked by ARIA but in Chrome they are not accesible by Jaws. However, in Internet Explorer they are accessible and visible to Jaws.
Is this due to some error in ARIA markup or is the Google Chrome Accessibility API not able to show those fields?
I would be glad about any idea how to fix this.
Thanks in advance for your input!
Solong
Ginger