WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen Readers as a Development Tool for Web Developers

for

From: Sean Curtis
Date: Jul 27, 2015 8:09PM

As a developer doing quite a lot of cross browser and cross AT testing of
web components, it was quite frustrating to find that the trial version of
JAWS does not allow you to test web pages (
http://webaim.org/blog/jaws-license-not-developer-friendly/). I wish I'd
read that before wasting an hour trying to work out what I'd done wrong
when setting it up and nothing was getting announced.

I'm also lucky enough to work at a company that can afford $1000+ for a
license so we can test our software. I did contact FS in regards to this,
but they do not hand out free licenses to developers. I'm just thankful
that most of our devs use OSX, so VoiceOver is readily available for them
to do some basic Accessibility Testing of components before pushing their
commits.

--
Sean Curtis

On Sat, Jul 25, 2015 at 1:10 AM, Leitschuh, Jonathan <
<EMAIL REMOVED> > wrote:

> The primary reason that this was done (I think) is because it is much
> easier to style div elements. Default HTML tables don't easily support
> many of the features that many people want.
> I wasn't there for the beginning of the development of this product.
> UI-Grid just had many of the features that we needed but we also needed it
> to be accessible. Accessibility in this case was something that was
> thought up later rather than something that was thought of from day one.
>
> One of the major reasons why a grid like this was created is because most
> of the data can be virtualized when not within the scroll window. That way
> if your dataset is 100k rows the browser is only showing 12. It make the
> entire user experience much more responsive.
>
> -Jonathan
>
>
> On 7/23/15, 10:48 AM, "Graham Armfield" < <EMAIL REMOVED> >
> wrote:
>
> >_mallory is right in my view, that is a significant reason why devs would
> >want to do this. I've seen it in websites for mobiles, and in hybrid apps
> >too. Left and right scrolling of tables may deliver an accessible
> >experience, but many people don't like the way it looks.
> >
> >
> >Regards
> >Graham Armfield
> >
> >
> >
> >coolfields.co.uk <http://www.coolfields.co.uk/>;
> >M:07905 590026
> >T: 01483 856613
> >@coolfields <https://twitter.com/coolfields>
> >
> >On Thu, Jul 23, 2015 at 3:37 PM, _mallory < <EMAIL REMOVED> >
> >wrote:
> >
> >> 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
> >> > >> >> >
> >> > > >> > > >> archives at http://webaim.org/discussion/archives
> >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > >>
> >
>
> > > > >