E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 31 (In chronological order)

From: Dennis Deacon
Date: Fri, Jul 17 2015 10:44AM
Subject: Screen Readers as a Development Tool for Web Developers
No previous message | Next message →

I started my inquiry on Twitter, but wanted to get more feedback on this.

It is my opinion that web developers need to have a certain level of
expertise with using a screen reader to test their work during development.
I have run into a few with a similar point of view. However, the majority
of feedback has stated that this is an unrealistic expectation. I myself
find it difficult to hand over work to someone else to test without having
testing it myself.

I'd love to hear the opinion of others. I myself am a novice screen reader
user and have looked for training specifically for developers. Beyond the
online cheat sheets, there are none.

Thanks in advance.


Dennis Deacon

From: Paul Bohman
Date: Fri, Jul 17 2015 10:57AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

There are courses on using screen readers for web developers and QA
professionals. We have one at Deque called "Testing with Screen Readers."
It covers JAWS, NVDA, and VoiceOver in some detail, on both a conceptual
and technical level.

https://dequeuniversity.com/curriculum/courses/screenreaders


Paul Bohman, PhD
Director of Training, Deque Systems, Inc
https://DequeUniversity.com
703-225-0380, ext.121


*Join us at our Mobile Accessibility "Bootcamp!" *
August 6-7 in Austin Texas
https://dequeuniversity.com/events/2015/mobile
Topics include responsive web design, native apps, & more

On Fri, Jul 17, 2015 at 12:44 PM, Dennis Deacon < = EMAIL ADDRESS REMOVED = >
wrote:

> I started my inquiry on Twitter, but wanted to get more feedback on this.
>
> It is my opinion that web developers need to have a certain level of
> expertise with using a screen reader to test their work during development.
> I have run into a few with a similar point of view. However, the majority
> of feedback has stated that this is an unrealistic expectation. I myself
> find it difficult to hand over work to someone else to test without having
> testing it myself.
>
> I'd love to hear the opinion of others. I myself am a novice screen reader
> user and have looked for training specifically for developers. Beyond the
> online cheat sheets, there are none.
>
> Thanks in advance.
>
>
> Dennis Deacon
> > > > >

From: Paul J. Adam
Date: Fri, Jul 17 2015 11:05AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

Hey Dennis, here's my twitter response I sent you so WebAIM folks can see what I think :)


pauljadam
. @deconspray yes! If you expect them to do cross-browser web dev then they can handle learning an AT. If they take their craft seriously!
7/17/15, 9:44 AM <https://twitter.com/pauljadam/status/622054292489285632>


Paul J. Adam
Accessibility Evangelist
www.deque.com

Join us at our Mobile Accessibility "Bootcamp!"
August 6-7 in Austin Texas
https://dequeuniversity.com/events/2015/mobile
Topics include responsive web design, native apps, & more

> On Jul 17, 2015, at 11:44 AM, Dennis Deacon < = EMAIL ADDRESS REMOVED = > wrote:
>
> I started my inquiry on Twitter, but wanted to get more feedback on this.
>
> It is my opinion that web developers need to have a certain level of
> expertise with using a screen reader to test their work during development.
> I have run into a few with a similar point of view. However, the majority
> of feedback has stated that this is an unrealistic expectation. I myself
> find it difficult to hand over work to someone else to test without having
> testing it myself.
>
> I'd love to hear the opinion of others. I myself am a novice screen reader
> user and have looked for training specifically for developers. Beyond the
> online cheat sheets, there are none.
>
> Thanks in advance.
>
>
> Dennis Deacon
> > > >

From: Bryan Garaventa
Date: Fri, Jul 17 2015 11:17AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

It's always easier to build something if you understand how it works. The developers who I have worked with who have taken the time to do this are far better at building accessible software now than those who have not.

For example, understanding 'how' to do something is important, but it is equally important to understand the 'why' of doing something too, which is where AT familiarity comes into play. Also knowing the rendering differences between offscreen rendering models such as those in desktop screen readers like JAWS and NVDA, and how this differs from visual rendering models like that seen on iOS is important for responsive design.

From: Eades, Terri
Date: Fri, Jul 17 2015 11:34AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

I'm really torn. I would actually LIKE to learn how to use a screen reader and I see the benefit of testing with it, but as designers and developers go "full stack"--meaning they both design the visual interface and code, and usually also do UX--that's a lot already on the plate to learn and stay updated with. While I could definitely learn how to use a screen reader, I don't know if I could be competent enough to test thoroughly, just because there is already so much going on in my brain and because I am not your typical user, and I want to have real-world testing. But I do understand how you won't truly know how accessible you are unless you test it, yourself, just like we're used to testing sites in different browsers.


Terri Eades
Webmaster

Morgan Community College
920 Barlow Road, Fort Morgan, CO 80701
Phone: (970) 542-3155 | Fax: (970) 542-3115
= EMAIL ADDRESS REMOVED =

www.MorganCC.edu

From: Jennifer Sutton
Date: Fri, Jul 17 2015 12:44PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

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/

From: Andrews, David B (DEED)
Date: Fri, Jul 17 2015 12:58PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

On the whole I agree with Jennifer -- as I usually do! Anyway, as others have pointed out, this is a complex issue, and if I had to do so, I could argue it either way. I have even worked with developers, and given demonstrations at conferences, to developers, on using screen readers for testing.

However, in the end, I think it doesn't work well. Unless you use a screen reader on a regular basis, you simply aren't going to be very good at it. In an ideal world, developers would be able to test using screen readers, but they already have a huge amount on their plates, so I think it is unrealistic to expect them to be experts in this too.

Jennifer's visual tools are ultimately the best solution, but until they exist, we may just have to rely on accessibility professionals to do testing.

Dave

From: Paul Bohman
Date: Fri, Jul 17 2015 1:40PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

It's true that screen readers are complex, especially when you take into
account different brands, versions, browsers, bugs, and user settings.

Even so, when a developer creates an ARIA widget, *someone* has to test it
with a screen reader, because in approximately 100% of the cases where a
developer who doesn't know how to use a screen reader creates an ARIA
widget, it is flawed, and often badly unusable.

Whether an organization has on on-site designated screen reader testing
person (or team) or whether they expect developers to test it themselves,
someone has to do it, or it's essentially guaranteed to be broken.


Paul Bohman, PhD
Director of Training, Deque Systems, Inc
https://DequeUniversity.com
703-225-0380, ext.121


*Join us at our Mobile Accessibility "Bootcamp!" *
August 6-7 in Austin Texas
https://dequeuniversity.com/events/2015/mobile
Topics include responsive web design, native apps, & more

On Fri, Jul 17, 2015 at 2:58 PM, Andrews, David B (DEED) <
= EMAIL ADDRESS REMOVED = > wrote:

> On the whole I agree with Jennifer -- as I usually do! Anyway, as others
> have pointed out, this is a complex issue, and if I had to do so, I could
> argue it either way. I have even worked with developers, and given
> demonstrations at conferences, to developers, on using screen readers for
> testing.
>
> However, in the end, I think it doesn't work well. Unless you use a screen
> reader on a regular basis, you simply aren't going to be very good at it.
> In an ideal world, developers would be able to test using screen readers,
> but they already have a huge amount on their plates, so I think it is
> unrealistic to expect them to be experts in this too.
>
> Jennifer's visual tools are ultimately the best solution, but until they
> exist, we may just have to rely on accessibility professionals to do
> testing.
>
> Dave
>
>
>
>

From: Andrews, David B (DEED)
Date: Fri, Jul 17 2015 1:43PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

I certainly wasn't saying don't test. I agree, testing is absolutely necessary. I was just saying that unless a developer tests all the time, with a screen reader, it is an unrealistic expectation to expect her to be good at it.

Dave

From: Richard Hulse
Date: Fri, Jul 17 2015 2:20PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

I agree.

The best place to learn is someone who uses a screen reader full time. Or better still several people.

That'll give you a chance to see how different people discover what content is on a page, and how they interact with sites they already know.

You should also find your local screen reader mailing list if there is one and join it. This can give a unique perspective.

The problem is not how to use a screen reader, but how real people use them and how your understanding of that shapes the way you do testing.

At the very least it'll ensure you don't create pages that make no sense, and that the basics work correctly.

I do recommend real screen reader users for complex apps.

> On 18/07/2015, at 4:44 am, Dennis Deacon < = EMAIL ADDRESS REMOVED = > wrote:
>
> I started my inquiry on Twitter, but wanted to get more feedback on this.
>
> It is my opinion that web developers need to have a certain level of
> expertise with using a screen reader to test their work during development.
> I have run into a few with a similar point of view. However, the majority
> of feedback has stated that this is an unrealistic expectation. I myself
> find it difficult to hand over work to someone else to test without having
> testing it myself.
>
> I'd love to hear the opinion of others. I myself am a novice screen reader
> user and have looked for training specifically for developers. Beyond the
> online cheat sheets, there are none.
>
> Thanks in advance.
>
>
> Dennis Deacon
> > > >

From: Bryan Garaventa
Date: Fri, Jul 17 2015 2:34PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

Granted, this is typically a resource issue. I also wrote an article about this at
https://www.linkedin.com/grp/post/4512178-5921880667464941572
(Who is best qualified to understand web accessibility?)

However it is equally unscalable to expect all developers to ignore how ATs work and at the same time expect that the software they build will somehow become more accessible automatically. Only through education and cooperation can this happen effectively.

There was a discussion about this to at
https://lists.w3.org/Archives/Public/public-pfwg/2015May/0029.html

It is also just as easy to go down the rat hole of saying that, because most developers aren't properly trained now, they never will be.

Education has to start somewhere, and now we have some very good resources that are specifically dedicated for this purpose for engineers.

It cannot be helped if people don't want to learn, however for educators teaching programming, there is no reason why this can't be included within the curriculum for this purpose.
E.G https://www.linkedin.com/grp/post/4512178-5986846570295877633

Additionally, collaborative projects such as the following
http://whatsock.com/training/matrices/
make it easier to understand basic role hierarchy mappings and how these map into the latest ARIA 1.1 standard.

Becoming more knowledgeable about accessibility is becoming easier, but others need to step up as well, both in the academic sector for the education of future engineers, as well as individual engineers wishing to remain relevant by updating their skill sets as modern technologies evolve. Accessibility is a coding discipline like any other.

For instance, as 'accessibility' as it relates to the Accessibility API on platform operating systems is updated frequently, as the ARIA 1.1 standard is being worked on to make these mappings more secure, and as ATs use these new technologies to provide better experiences for users, all of these are considered as evolving technologies that are relevant to the skill sets of current and future engineers; who need to understand how they work together in order to see how to make them work better within their software.

We can continue to build these new powerful technologies forever, but as long as these developments are ignored as being beneath the notice of the educational process for those implementing them, and engineers feel that it's too hard to figure it out, accessibility will never be scalable.

So for this to work, three things need to happen,
(1) operating systems and browsers and ATs need to integrate together better,
(2) conformant coding practices and Assistive Technology familiarization needs to be a standard part of the educational process for engineers within academics,
and (3) current engineers need to use these training materials to become stronger in the field.

These things are time consuming and hard at first, but it does get easier as common knowledge spreads. It's also important for companies to step up and provide the time and funding necessary to train their developers as well. Often it's not the lack of valuable materials for training that are at play, but rather, the unwillingness of the business department to see the point in allowing it.

Insufficient understanding does far more harm in the long run than any other type of issue in development.

From: Jennifer Sutton
Date: Fri, Jul 17 2015 3:46PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

Paul and all:

Since Dave and I are lifelong screen reader users (for as long as
they've existed, I believe), and we have decades of experience in
this industry (between us), we're well aware of this fact -- that
ARIA, as it works today, requires a screen reader to test it.

But my point is that the current approach ain't workin' in the real world.

Sure, it works for businesses who are in the business of
specializing. And you bet I speak for myself, as a self-employed part
of this industry. Just because I can directly benefit from the status
quo doesn't mean I think it's the right path.

Today's expectation that devs/designers/whomever
(someone?/anyone?) should test with a screen reader isn't working out
very well for end-users since screen reader testing sites that
implement ARIA (no matter who does it) is not scaling. I don't see
that the notion is realistic. ARIA should *not* require screen reader
testing since it may be (today), but doesn't *have* to be, only for
screen reader users.

People who work *for* blind people in this industry, but who aren't
blind themselves, typically can go back to "normal" surfing for their
everyday tasks/needs, so the constant presentation of "ARIA going
even wilder, and wilder, and wilder . . ." (and flat out often being
a "blocker" when implemented incorrectly) is less for many of you
than for others of us. It's EVERYWHERE! And it's so rarely
implemented correctly that I daresay end-users have few opportunities
to learn how it should work.

[Thanks for the theft and modification of one of your presentation
titles, Jared]

As I was trying to do, in the previous thread, I'm not thinking here
about today; I'm trying to think about a different future, where we
learn from what isn't working in the present, and we maximize what
ARIA could be bringing to the table (and perhaps accessibility in
SVG, too, for that matter).

It's pretty simple, in my mind. Generally speaking, if sighted people
can't see it, they're not going to do it. By "seeing it" I mean
integrating prompts in tools, or some kind of screen reader emulator
that visually shows standard screen reader behaviors. Or something
even cooler that I can't imagine.

And even if those who are working on sites *could* see it, they'd
still have to go the extra mile to understand what they're seeing,
but at least the learning curve would be less.

That's just human nature; I'm not bashing anyone at all, here. I keep
thinking that if blind people expect sighted people to accommodate
us, then we need to figure out a way to accommodate them, even as I
wish this were about more than blind folks.

I'm so very excited to see tools, like Tenon, that are focusing on
being incorporated into common dev tools, to meet people where they
are. And, though I've not tried them, I'm seeing some mobile teaching
and testing tools that may have this idea in mind, to a degree.

Clearly, I'm thinking "bigger" than today's approach.
We've had many years of history in this industry (with progress,
but progress that's pretty slow in terms of adoption); it'd be great
if we could shift from repeating it, to find some ways to speed things up.

With apologies, Dennis, for side-tracking the conversation.

Jennifer, who will now go back to work in order to test and fix what
she can and stop beating this poor horse

From: Jonathan Avila
Date: Fri, Jul 17 2015 7:23PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

> 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 ADDRESS REMOVED =

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

From: timy sebastian ettumanoor
Date: Fri, Jul 17 2015 9:45PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

after reading this post thought to put a small suggestion here.

if it is possible someone please creat an audio tutorial for beginners
an intermediate/advance users all about aria coding, what is the use
of role, name, status, describedby aria properties, and alert etc.

this will be more helpful those who are new to this concept.

this is only a humble request from my side.

hope someone will do it shortly.

with regards,

Timy.

From: Bryan Garaventa
Date: Fri, Jul 17 2015 11:52PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

> 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.

From: Patrick H. Lauke
Date: Sat, Jul 18 2015 1:45AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

On 18/07/2015 06:52, Bryan Garaventa wrote:

> * 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.

Don't forget desktop screen readers also work on laptops/computers with
touchscreens (admittedly not as common yet, but a growing number of
Windows 8 laptops have it now). In those cases, they behave similarly to
what you describe on iOS (i.e. that users can touch-explore only what's
visible, but can also swipe left/right). So the distinction becomes very
blurred.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Avila
Date: Sat, Jul 18 2015 8:26AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

> 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 ADDRESS REMOVED =

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

From: Mike Bicknell
Date: Sun, Jul 19 2015 3:11PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

Another option for some, but not all:

Another option is for developers (professors, companies) to partner with
an organization for the blind or deafblind to gain first hand knowledge of
how users interact with their products. For instance, the Washington State
School for the Blind has had a multi-year partnership with Professor
Andreas Stefik from UNLV. He is the developer of Quorum
(http://quorumlanguage.com/), an evidence-oriented programming language.
He found that debuggers weren¹t friendly to the blind, so he set about
developing one in Sodbeans, the standard development environment for
Quorum. For several years WSSB has hosted a computer programming camp to
teach general education Teachers and Teachers of the Visually Impaired how
to use Quorum as part of their curriculum. We are now hoping that Quorum
will soon be officially accepted for use in LEGOs robotics competition.

We¹ve had a mutually beneficial relationship--One that has contributed to
the educational blindness field and to their language development. We also
partnered with Microsoft Lync¹s accessibility team a few years ago to the
benefit our synchronous distance learning math program and to make Lync
more accessible for all.

Just a thought.

Mike Bicknell
Digital Learning, Research, and Development Coordinator
Chief Information Officer
Washington State School for the Blind
Phone: 360-947-3331
http://www.wssb.wa.gov/Content/offcampus/DistanceLearning.asp





On 7/18/15, 7:26 AM, "WebAIM-Forum on behalf of Jonathan Avila"
< = EMAIL ADDRESS REMOVED = on behalf of
= EMAIL ADDRESS 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 ADDRESS REMOVED =
>
>703-637-8957 (o)
>Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Leitschuh, Jonathan
Date: Wed, Jul 22 2015 4:07PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
>
>703-637-8957 (o)
>Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Moore,Michael (HHSC)
Date: Thu, Jul 23 2015 6:46AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

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)

From: _mallory
Date: Thu, Jul 23 2015 8:37AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

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)
>
>

From: Graham Armfield
Date: Thu, Jul 23 2015 8:48AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

_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 ADDRESS 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)
> >
> >

From: Leitschuh, Jonathan
Date: Fri, Jul 24 2015 9:10AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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)
>> >
>> >

From: Sean Curtis
Date: Mon, Jul 27 2015 8:09PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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)
> >> >
> >> >

From: Joseph Sherman
Date: Tue, Jul 28 2015 7:36AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

Hi Sean. Let me start by saying I do not use JAWS trial. However, I think there are two different issues. The trial version of JAWS is fully functional for the 40 minute time limit, so when you say "nothing was getting announced", that is not related to the trail version. The blog post you link to below refers to the terms of the JAWS EULA, which states that the trial version cannot be used for web testing. It is a licensing restriction, not a product feature restriction.



Also note that NVDA is a free, open source screen reader that can be used for testing.





Joseph

From: Moore,Michael (HHSC)
Date: Tue, Jul 28 2015 8:23AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

I always love it when developers complain about the cost of tools to determine if what they build can be used by everyone - but the rant can wait for later.

First some alternatives:

As Joseph pointed out the JAWS demo version is fully functional in 40 min mode and as pointed out in the comments of the original blog post you can use it to evaluate whether it would meet your needs as a testing tool. How long and detailed your evaluation phase is, probably gets you into a gray area. The download page for the demo version does not list any licensing restrictions currently.

If you have Microsoft Office (cost $400) AI Squared will allow you to download and use a fully functional copy of Window Eyes. http://www.windoweyesforoffice.com/ This is a darn good fully functional screen reader but does not have as large a market share as JAWS.

Joseph mentioned that NVDA is available to download for free from NV Access. http://www.nvaccess.org/ Continued development of this product is dependent upon donations from those of us who use it. Set your own price.

VoiceOver is included in OSX with the price of a Mac ($1000+). The market share for people who are blind is still relatively low.

<rant>
The cost of JAWS relative to other developer tools is not exorbitant. $800-$1000 and you can keep it current by purchasing an SMA for about $120 per year. (for comparison Adobe Creative Cloud is about $600 per year) Seriously, what did those Macs cost? Did your company through in a few 4K displays for the designers? How about your Creative Cloud licenses from Adobe, Microsoft Office professional, adding Windows OS and how many other tools?

Mechanics don't complain (too loudly) about the need to purchase special tools to complete a single repair on one make of car. Carpenters, plumbers, electricians all have specialized tools that they only need for certain jobs - some are quite expensive and friend of mine in those professions are usually quick to show me new ones when they get them.

People balk at the cost of JAWS and think that Freedom should supply a "developer" version at lower cost. I guess that the discount should be supported by increasing the cost to blind users who's median income must be well above that of us poor underpaid web developers.

Show a little pride in your toolbox. Add a nice shiny new license for JAWS 16 and show it off to all of your friends. Buy an SMA and be the first one on your team to master JAWS 17 when its released.
</rant>

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

From: Guy Hickling
Date: Tue, Jul 28 2015 3:45PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

I feel honoured to talk with the earlier correspondent, I don't often get
to mix with people who can dismiss nearly a thousand quid so casually! I
wish I could do the same. However, I do think it is good to remember what
accessibility developers are doing here, often at their own cost with no
assistance from an employer. We are helping blind people which, I think,
ought to qualify us for some consideration from manufacturers of the tools.

But are we just helping blind people? No, we are also helping Freedom
Scientific, the makers of JAWS. If we can test our websites to be sure they
work with their product, that will make for a better experience for their
users. This in turn would encourage other blind people to select that
reader, and help it to retain it's currently top position.

On the other hand, if we developers have to restrict ourselves to testing
with NVDA, and any screen reader that bothers to assist developers by
providing developer copies, because of the cost otherwise, then NVDA users
will increasingly have the better experience while JAWS users experience
glitches and untested for bugs in the websites they visit. That can only
help NVDA continue to gain in popularity.

I would have thought that simple self-interest would encourage Freedom
Scientific to assist developers better, but apparently not.

From: Sean Curtis
Date: Tue, Jul 28 2015 6:25PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

Joseph,

When I ran the trial of JAWS the screen reader went absolutely silent the
second I started to navigate a web browser. This wasn't just licensing or
the EULA, the functionality was disabled. I'm not sure if this has changed
since JAWS 15, but it was definitely the case when I was originally testing
things.

We use NVDA, VoiceOver and Window Eyes. We use JAWS, but only because I
managed to get approval for the purchase. Also it's not just $1000. We cop
an "Australia" tax here when buying things from overseas. If I was to buy
JAWS from the local distributor, it ends up being nearly $1800. That's a
HUGE mark up in price.

As I originally stated, I'm lucky to be privileged enough to work somewhere
that can afford to buy this. Most freelance web developers would not be
able to afford this (or at least would not justify paying for this when
they could just use NVDA instead). It just means things only get tested in
1-2 screen readers, rather than 4-5.

Cheers,

Sean

On Tue, Jul 28, 2015 at 11:36 PM, Joseph Sherman < = EMAIL ADDRESS REMOVED = >
wrote:

> Hi Sean. Let me start by saying I do not use JAWS trial. However, I think
> there are two different issues. The trial version of JAWS is fully
> functional for the 40 minute time limit, so when you say "nothing was
> getting announced", that is not related to the trail version. The blog post
> you link to below refers to the terms of the JAWS EULA, which states that
> the trial version cannot be used for web testing. It is a licensing
> restriction, not a product feature restriction.
>
>
>
> Also note that NVDA is a free, open source screen reader that can be used
> for testing.
>
>
>
>
>
> Joseph
>
>
>
>
>
>

From: Patrick H. Lauke
Date: Tue, Jul 28 2015 6:32PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

On 29/07/2015 01:25, Sean Curtis wrote:
> When I ran the trial of JAWS the screen reader went absolutely silent the
> second I started to navigate a web browser. This wasn't just licensing or
> the EULA, the functionality was disabled. I'm not sure if this has changed
> since JAWS 15, but it was definitely the case when I was originally testing
> things.

You usually have to explictly (re)start the browser after JAWS has been
launched, to make sure it's hooking into the right APIs etc. Otherwise,
it's quite often the case that JAWS remains pretty silent as you navigate...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: _mallory
Date: Tue, Jul 28 2015 11:22PM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | Next message →

The argument about "if you're already paying good money for your other
tools, JAWS should be no diferent" makes plenty of sense if you work
for a medium/large company or a media bureau (those shops that make the
brochureware slick marketing websites for big clients... those folks
have those nice big monitors and macs).

And obviously people who are employed and can afford things in general
shouldn't come above disabled users who need these products and esp
if they are not employed or poorly employed due to their disability(ies).
If developers got a discount, shouldn't blind students/seniors/etc too?
(as an example)

But make no mistake, there's a lot of us who work all our work with
only free tools and 2nd hand machines running VMs to attempt to test
all areas. My company gets zero Mac testing, because nobody owns one
and my company even balked at the idea of 19 US dollars per month for
BrowserStack. I don't even think it costs that much now.

That said, all my JAWS testing I've ever done was against the EULA.

_mallory

On Tue, Jul 28, 2015 at 10:45:33PM +0100, Guy Hickling wrote:
> I feel honoured to talk with the earlier correspondent, I don't often get
> to mix with people who can dismiss nearly a thousand quid so casually! I
> wish I could do the same. However, I do think it is good to remember what
> accessibility developers are doing here, often at their own cost with no
> assistance from an employer. We are helping blind people which, I think,
> ought to qualify us for some consideration from manufacturers of the tools.
>
> But are we just helping blind people? No, we are also helping Freedom
> Scientific, the makers of JAWS. If we can test our websites to be sure they
> work with their product, that will make for a better experience for their
> users. This in turn would encourage other blind people to select that
> reader, and help it to retain it's currently top position.
>
> On the other hand, if we developers have to restrict ourselves to testing
> with NVDA, and any screen reader that bothers to assist developers by
> providing developer copies, because of the cost otherwise, then NVDA users
> will increasingly have the better experience while JAWS users experience
> glitches and untested for bugs in the websites they visit. That can only
> help NVDA continue to gain in popularity.
>
> I would have thought that simple self-interest would encourage Freedom
> Scientific to assist developers better, but apparently not.
> > > >

From: Eades, Terri
Date: Wed, Jul 29 2015 9:16AM
Subject: Re: Screen Readers as a Development Tool for Web Developers
← Previous message | No next message

I have to agree with Guy. I am a web developer in the Marketing department of a small community college and $1,000 is a lot of money. I don't have a Mac, I'm on Adobe CS 5, and I don't have the other luxuries that were cited. (That might be for designers who work at an agency.) I would like to test on JAWS since it is more widely used, but we just can't afford it at this time.

Terri