WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen Readers as a Development Tool for Web Developers

for

From: Moore,Michael (HHSC)
Date: Jul 23, 2015 6:46AM

Wouldn't you consider it to be a fundamental semantic flaw to implement a grid with divs rather than a table or am I missing something. I see this implementation all of the time. I understand using generic markup (spans and divs) to create constructs that do not map well to existing html elements but for a grid a table provides the proper semantic structure. - Unless you are referring to a layout grid used to organize sections of a page. Perhaps the problem is that developers are using the frameworks layout grid construct where they should be dropping a table into a div within the grid.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Leitschuh, Jonathan
Sent: Wednesday, July 22, 2015 5:08 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Screen Readers as a Development Tool for Web Developers

I found one of the most difficult parts of trying to implement accessibility into an angular grid framework (pull request pending) was that there was a severe lack of real world application examples that you could gain inspiration from.

I spent many hours trying to find examples of div based grids that worked with screen readers, without much luck.
Another major problem was the inconsistency between browsers. One set of aria roles would work fine in chrome but safari wouldn¹t know how to read it at all. Meanwhile Firefox would think it was a list not a grid.

There were also many Œgotchas¹ that were totally undocumented.
For example: In chrome as long as the roles for Œrow¹ has some offspring with a role Œcell¹ it will read it fine. However, in Safari, unless the dom element with the role Œcell¹ is an immediate dependent of a Œrow¹ the XCode Accessibility inspector reports that there is a Œgroup¹ between the row and the cell causing the screen reader to be unable to correctly interact with the grid.

The grid framework I added accessibility roles to:
http://ui-grid.info/


Pull Request Pending:
https://github.com/angular-ui/ui-grid/pull/3850


-Jonathan

On 7/18/15, 10:26 AM, "Jonathan Avila" < <EMAIL REMOVED> > wrote:

>> 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.
>
>Yes, no disagreement here that developers need to be trained on how
>assistive technology accesses, interacts, and interfaces with content,
>apps, APIs, and specifications. All the points are valid and I agree
>on the education bit as indicated by my bullet on education that these
>things need to be a part of the curriculum and code examples used in
>books, courses, etc.
>
>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 Bryan Garaventa
>Sent: Saturday, July 18, 2015 1:52 AM
>To: 'WebAIM Discussion List'
>Subject: Re: [WebAIM] Screen Readers as a Development Tool for Web
>Developers
>
>> 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-screenre
>ade
>rs-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/
>
>>>archives at http://webaim.org/discussion/archives
>>>>archives at http://webaim.org/discussion/archives
>>
>>>archives at http://webaim.org/discussion/archives
>