WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen Readers as a Development Tool for Web Developers

for

From: Bryan Garaventa
Date: Jul 17, 2015 11:52PM

> I agree. And while I believe that watching a screen reader user and trying to use one helps with empathy and understanding it is unrealistic to expect
> developers to be up-to-date screen reader users.

That is true, a person who does not use an AT like a screen reader on a regular basis, will never be an expert user.

When I refer to education for developers however, I'm not talking about empathy and understanding of the AT user, I'm referring to the mechanics behind the technology. These are two very different things.

For example, it is possible while teaching a web developer about JavaScript and HTML to also teach them the following at the same time:

* Accessibility on the operating system ties into the platform Accessibility API for that system, resulting in the creation of the Accessibility Tree.

* Browsers also tie into the Accessibility API role state and property mappings by building an Accessibility Tree based on the markup of web technologies; including the use of ARIA markup for this purpose.

* Assistive Technologies like screen readers then interface with the Accessibility Tree to convey the correct roles states and properties of web technologies, and process related events when fired by dynamic changes in the DOM.

* Desktop screen readers like JAWS and NVDA use a virtual offscreen model where all content that is offscreen but not hidden can be interacted with regardless, as opposed to VoiceOver on iOS that uses a visual rendering model where only the top layer of the visible UI can be reliably interacted with via touch. Additionally, when using one finger to explore the visible UI of an iOS device, only the visibly rendered model can be interacted with, which does not follow the DOM order. However, when swiping from Left to Right or Right to Left with one finger to navigate forward or backward from one object to the next, VoiceOver is actually following the DOM order and not the visibly rendered model, which is why offscreen content cannot be reliably interacted with on iOS.

None of the above information has anything to do with empathy or being understanding of the user, but instead conveys critical information that is of direct use to engineers. Moreover, the above information covers the most widely used and standards compliant screen readers, so it covers the majority of the global user base by providing the underlying behavioral information needed to understand why certain implementations behave differently on desktops versus touch screen devices.

If every engineering course started by simply explaining the above points to developers as part of the learning process, as well as within online learning materials for current developers wishing to become better versed in these concepts, it would have a significant impact on the future of accessible technologies.

For example, all of the above points perfectly illustrate how ARIA works, by being rendered in the DOM and changing the Accessibility Tree in the browser, which is mapped to the relevant control types on the platform Accessibility API, which ATs like screen readers then interface with, which is then conveyed to AT users.

It wouldn't be difficult to add this simple explanation to a programming training course for developers, and none of it requires Assistive Technology expertise on behalf of developers to understand or reproduce.





-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Jonathan Avila
Sent: Friday, July 17, 2015 6:23 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Screen Readers as a Development Tool for Web Developers

> I continue to believe that expecting folks to learn how to use screen readers is not going to scale. And it too often takes people down rat holes that are not important. I find that this is especially so when folks have never seen real people who use a screen reader. Using a screen reader is not like using a browser.

I agree. And while I believe that watching a screen reader user and trying to use one helps with empathy and understanding it is unrealistic to expect developers to be up-to-date screen reader users.

What we really need are
* Tools that can inspect the accessibility properties beyond what tools provide today and give developers assurance that what they have implemented is valid, correct, and will be consumed correctly by assistive technology
* Screen readers that operate in standards compliant modes
* More APIs such as text and JavaScript accessibility APIs so we don't have hopelessly complicated and unsupportable methods of exposing accessibility, e.g. methods that Google Docs uses for rich text areas.
* Accessibility training for developers and accessibility in the secondary school and university curriculum
* Tools such as authoring environments that make it easy for people to create accessible content
* Frameworks that build accessibility in at the beginning, e.g not like Angular

Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
<EMAIL REMOVED>

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Jennifer Sutton
Sent: Friday, July 17, 2015 2:44 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Screen Readers as a Development Tool for Web Developers

As evidenced by a recent thread:
http://webaim.org/discussion/mail_thread?threadp00

specifically this message from me:
http://webaim.org/discussion/mail_message?id(769

I continue to believe that expecting folks to learn how to use screen readers is not going to scale. And it too often takes people down rat holes that are not important. I find that this is especially so when folks have never seen real people who use a screen reader. Using a screen reader is not like using a browser.

Examples include both the difficulties people are having with understanding how to implement ARIA correctly, as well as, as far as I am concerned, the issues that are going to increasingly arise with the implementation of accessible SVG.

I realize what a complex issue this is (again, as evidenced by the thread cited above), but it seems to me that we've been having this expectation for many years, and it's not working particularly well.
If it were, we'd all be going out of business. [Some of you may not have that objective, but I do, even if my bank account may disagree.]

So, as I see it, we need a new way, and it seems to me that that way will involve meeting devs and designers where they are, i.e.
including relevant prompts (and visual replication of screen reader standard behaviors) in the off-the-shelf (commercial or opensource) tools they're already using.

If I were independently wealthy, and if I were a coder, I'd shut up and do it myself.

Dennis, for the record, this conversation has gone on many times in the past. Below my name are a small selection of links that, while they may have an older perspective, still outline the issues, I believe.

My conclusion: we have no choice, today, but I believe a paradigm shift would pay off hugely. And it *could* be (though I have no evidence for this, except hope) that digital publishers might be of great help in getting us there, given the large quantity of content and increasing requirements they have.

Best,
Jennifer
[hereby promising not to continue to step up on this Soap Box]

Should Sighted Developers Use Screenreaders To Test Accessibility Accessibility NZ http://accessibility.net.nz/blog/should-sighted-developers-use-screenreaders-to-test-accessibility/

Setting up a screen reader test environment http://www.iheni.com/screen-reader-testing/

Screen reader tips for Web Designers and Developers http://davidakennedy.com/2014/11/10/screen-reader-tips/

webaim Testing with Screen Readers - Questions and Answers http://webaim.org/articles/screenreader_testing/