W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2017

RE: Accessibility testing on device simulators

From: Steve Green <steve.green@testpartners.co.uk>
Date: Mon, 4 Dec 2017 19:54:59 +0000
To: ALAN SMITH <alands289@gmail.com>, "Subramanian, Poornima (PCL)" <psubramanian@hagroup.com>, 'W3C WAI Interest Group' <w3c-wai-ig@w3.org>
Message-ID: <AM5PR0901MB14277A7BEDE2655ECA9C6F69C73C0@AM5PR0901MB1427.eurprd09.prod.outlook.com>
I also strongly recommend that anyone who is thinking of doing screen reader testing should get some experience of user testing with screen reader users. Otherwise, you have no idea what they will and will not be capable of doing and understanding.

From: ALAN SMITH [mailto:alands289@gmail.com]
Sent: 04 December 2017 19:02
To: Subramanian, Poornima (PCL) <psubramanian@hagroup.com>; 'W3C WAI Interest Group' <w3c-wai-ig@w3.org>
Subject: RE: Accessibility testing on device simulators


I agree with Steve to using real screen readers.

I’ve trained over 100 QA on-shore and off-shore QA team members to use NVDA and JAWS for testing.
Testing for screen reader support is not that difficult.

Your testers do not need to know how to use a screen reader with the screen off, they need to know what to listen for by the screen reader and what to listen for compared to what is displayed on the screen.

I have used this methodology for years testing 1000’s of pages, written online training material, training docs and have had it validated by senior folks at FreedomScientific - the folks who give us JAWS.

1-Know how to do a read-all of the page
              You need to know what to listen for
2-Know how to do a read-all from a specific location on the page
              You need to know what to listen for
3-Know how to navigate through the page with a keyboard for landing on and selecting all focusable elements
              You need to know what to listen for
4-Know how to use the screen readers table mode to read through a table
              You need to know what to listen for
Then also know these 3 things:
5-Know how to find the screen readers links, headings, regions/landmarks and other elements list
              This helps you see what the screen reader sees for your components
              Not all screen readers support this
6-Know how to capture what the screen reader says to share with the team members
              This helps you share your test findings with others
7-Know how to capture what is on the screen and in the code
              Sometimes, especially for mobile, you need to do screen captures as your main method
              Know how to capture codes snippets as examples of the issue along with screen shots

I would suggest you do testing with NVDA and JAWS on Chrome, IE, Firefox and Edge (as best as you can with each screen reader and browser combination your company can) as well as VoiceOver on Macs to determine your gaps.
Then go through the process of coming up with validated accessible designs for your most common components and create a library for UX and Developers to follow and use.
Have your teams use these components only.
Use your QA staff to validate that those were used. Some of the validation can be done without a screen reader if the design and code has been validated in the library.

Let me know if you have any further questions.

I’m sure other’s will have helpful information to share as the email list you sent this to contains many folks who have been doing this for a long time and have experience they can share.

Alan Smith

From: Subramanian, Poornima (PCL)<mailto:psubramanian@hagroup.com>
Sent: Monday, December 4, 2017 10:24 AM
To: 'W3C WAI Interest Group'<mailto:w3c-wai-ig@w3.org>
Subject: Accessibility testing on device simulators

Hello Team,

I am looking for device simulators to test live websites & apps for accessibility, mainly with screen readers. Our testing team currently using “browse stack” simulator for functional testing. Looks like the Settings option is not either seen OR functioning on the devices through browse stack. Few questions –

  1.  Will device simulators provide access to screen readers as well?
  2.  Any experience with “browse stack” simulator?
  3.  Would you like to suggest any other simulator that works for screen reader testing? Or only the real device can help with this?

Your advice, please?


The information contained in this email and any attachment may be confidential and/or legally privileged and has been sent for the sole use of the intended recipient. If you are not an intended recipient, you are not authorized to review, use, disclose or copy any of its contents. If you have received this email in error please reply to the sender and destroy all copies of the message. Thank you.

To the extent that the matters contained in this email relate to services being provided by Princess Cruises and/or Holland America Line (together "HA Group") to Carnival Australia/P&O Cruises Australia, HA Group is providing these services under the terms of a Services Agreement between HA Group and Carnival Australia.

Received on Monday, 4 December 2017 19:55:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 6 December 2017 16:04:47 UTC