WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen Readers as a Development Tool for Web Developers

for

From: _mallory
Date: Jul 23, 2015 8:37AM

While I'm unsure of which circumstances Jonathan's talking about, I
have seen developers avoid using tables for tables purely because of
mobile-suckage (that the best one can do with large tables is scroll
them).

_mallory

On Thu, Jul 23, 2015 at 12:46:33PM +0000, Moore,Michael (HHSC) wrote:
> 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
> >>
> > > > > > >