E-mail List Archives

Search E-mail List Archives for

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

From: Karla Kmetz
Date: Mon, Apr 09 2012 2:22PM
Subject: Web Analytics
No previous message | Next message →

Hi All,

I had a couple questions from a coworker that I do not know the answer to.
I would appreciate any input or information.


1. Is there a way to detect usage of screen readers and/or any other
assistive technology accessing a website (ie through google analytics)?
2. Do some AT users turn off Javascript when browsing the web?

Thank you,
Karla

--
*Karla Kmetz, M.Ed.*
Instructional Designer
Distance Learning and Instructional Media Services
University of South Florida St. Petersburg, POY 239
Phone: 727-873-4474

From: Jared Smith
Date: Mon, Apr 09 2012 2:50PM
Subject: Re: Web Analytics
← Previous message | Next message →

On Mon, Apr 9, 2012 at 2:22 PM, Karla Kmetz wrote:
>   1. Is there a way to detect usage of screen readers and/or any other
>   assistive technology accessing a website (ie through google analytics)?

No. Well, mostly no. You could use Flash to detect if Windows MSAA is
activated, which is an unreliable way of indicating that a user might
be using some sort of assistive technology, but I would not bother
doing so. You could also do some hacking to detect things like high
contrast or text sizing, but again, the data would likely not be
terribly accurate or useful. Individuals with disabilities have
historically been quite opposed to self-identification of assistive
technology to web site authors.

>   2. Do some AT users turn off Javascript when browsing the web?

Of course they do, but our experience has been that the percentage of
AT users that disable Javascript is not much different than the
general population. Our most recent screen reader user survey found
that 98.4% of respondents had Javascript enabled.

Jared Smith
WebAIM.org

From: Ryan Hemphill
Date: Mon, Apr 09 2012 2:54PM
Subject: Re: Web Analytics
← Previous message | Next message →

#1 - There is no means (I have researched) online to detect a screen reader
on the web at this point. Woud be nice, though - huh?

#2 - Most people don't do that. There's simply too much javascript at this
point to turn it off and expect a fully functioning site. Those that still
do so would be the minority as there are precious few cases these days
where that will work out anymore.


Ryan

On Mon, Apr 9, 2012 at 4:22 PM, Karla Kmetz < = EMAIL ADDRESS REMOVED = > wrote:

> Hi All,
>
> I had a couple questions from a coworker that I do not know the answer to.
> I would appreciate any input or information.
>
>
> 1. Is there a way to detect usage of screen readers and/or any other
> assistive technology accessing a website (ie through google analytics)?
> 2. Do some AT users turn off Javascript when browsing the web?
>
> Thank you,
> Karla
>
> --
> *Karla Kmetz, M.Ed.*
> Instructional Designer
> Distance Learning and Instructional Media Services
> University of South Florida St. Petersburg, POY 239
> Phone: 727-873-4474
> > > >



--



Shipping is a Feature...Perhaps the Most Important Feature.

From: Ryan Hemphill
Date: Mon, Apr 09 2012 2:57PM
Subject: Re: Web Analytics
← Previous message | Next message →

" Individuals with disabilities have
historically been quite opposed to self-identification of assistive
technology to web site authors."

Wow. That is news to me - can you point me to where this comes from? It
sounds very counterintuitive.


Ryan

On Mon, Apr 9, 2012 at 4:54 PM, Ryan Hemphill
< = EMAIL ADDRESS REMOVED = >wrote:

> #1 - There is no means (I have researched) online to detect a screen
> reader on the web at this point. Woud be nice, though - huh?
>
> #2 - Most people don't do that. There's simply too much javascript at
> this point to turn it off and expect a fully functioning site. Those that
> still do so would be the minority as there are precious few cases these
> days where that will work out anymore.
>
>
> Ryan
>
>
> On Mon, Apr 9, 2012 at 4:22 PM, Karla Kmetz < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi All,
>>
>> I had a couple questions from a coworker that I do not know the answer to.
>> I would appreciate any input or information.
>>
>>
>> 1. Is there a way to detect usage of screen readers and/or any other
>> assistive technology accessing a website (ie through google analytics)?
>> 2. Do some AT users turn off Javascript when browsing the web?
>>
>> Thank you,
>> Karla
>>
>> --
>> *Karla Kmetz, M.Ed.*
>> Instructional Designer
>> Distance Learning and Instructional Media Services
>> University of South Florida St. Petersburg, POY 239
>> Phone: 727-873-4474
>> >> >> >>
>
>
>
> --
>
>
>
> Shipping is a Feature...Perhaps the Most Important Feature.
>



--



Shipping is a Feature...Perhaps the Most Important Feature.

From: Jared Smith
Date: Mon, Apr 09 2012 4:18PM
Subject: Re: Web Analytics
← Previous message | Next message →

On Mon, Apr 9, 2012 at 2:57 PM, Ryan Hemphill
< = EMAIL ADDRESS REMOVED = > wrote:
> Wow. That is news to me - can you point me to where this comes from? It
> sounds very counterintuitive.

Self-identification of disability is generally opposed by individuals
with disabilities. It opens the door to discrimination. For example,
someone should not have to disclose that they have a disability when
applying for a job, otherwise this may impact the likelihood that they
are even considered for that job.

On the web, while it sounds like a great idea to be able to identify
the presence of AT and then customize the experience accordingly, I've
found that this is generally a very bad idea. It would result in
separate presentations for users with disabilities that would often
not be kept up-to-date or useful (the terms "separate" and "unequal"
are typically the nexus of defining discrimination). One should not be
forced to a text-only or "screen reader optimized" version of a page
simply because they are using a screen reader (especially when you
consider that many screen reader users are not blind). Additionally,
this approach would require a lot more work for developers. Creating
separate versions of web content is rarely necessary if good universal
design and accessibility are implemented.

Jared

From: Patrick Burke
Date: Mon, Apr 09 2012 5:42PM
Subject: Re: Web Analytics
← Previous message | Next message →

At 01:54 PM 4/9/2012, Ryan Hemphill wrote:
>#2 - Most people don't do that. There's simply too much javascript at this
>point to turn it off and expect a fully functioning site. Those that still
>do so would be the minority as there are precious few cases these days
>where that will work out anymore.
>
>Especially for news sites, I have found turning off JS works great!
>There are some sites that break completely, but most will serve up
>the story with a lot less wait time, & usually somewhat reduced page clutter.


I know, I know, I'm breaking the internet. :)

I! Am! The 1.6%!



Patrick
--
Patrick J. Burke

Coordinator
UCLA Disabilities &
Computing Program

Phone: 310 206-6004
E-mail: = EMAIL ADDRESS REMOVED =
Location: 4909 Math Science


Department Contact: = EMAIL ADDRESS REMOVED =

From: Birkir R. Gunnarsson
Date: Mon, Apr 09 2012 6:58PM
Subject: Re: Web Analytics
← Previous message | Next message →

If you read this article (admittedly on e-books and accessibility), it
clearly states the print-disabled community's stonch opposition to
being identified as such:
http://www.readingrights.org/kindle-tts-issue

I'd have no issues with my computer being identified as using screen
reading software in particular. I think it would at least be
interesting to have that option available, and the user could turn it
on and off for certain sites (e.g. turn it off for sites where user is
registerring for a job etc).
Though honestly web sites should not design specifically for screen
reader users, for all the excellent reasons Jared Smith already
mentioned.
Media queries offer interesting developments though, as they try to
maximize usability for websites based on user devices, there is even a
braille CSS style defined, though I have absolutely no idea how that
works.
Cheers
-B

On 4/9/12, Patrick Burke < = EMAIL ADDRESS REMOVED = > wrote:
> At 01:54 PM 4/9/2012, Ryan Hemphill wrote:
>>#2 - Most people don't do that. There's simply too much javascript at this
>>point to turn it off and expect a fully functioning site. Those that still
>>do so would be the minority as there are precious few cases these days
>>where that will work out anymore.
>>
>>Especially for news sites, I have found turning off JS works great!
>>There are some sites that break completely, but most will serve up
>>the story with a lot less wait time, & usually somewhat reduced page
>> clutter.
>
>
> I know, I know, I'm breaking the internet. :)
>
> I! Am! The 1.6%!
>
>
>
> Patrick
> --
> Patrick J. Burke
>
> Coordinator
> UCLA Disabilities &
> Computing Program
>
> Phone: 310 206-6004
> E-mail: = EMAIL ADDRESS REMOVED =
> Location: 4909 Math Science
>
>
> Department Contact: = EMAIL ADDRESS REMOVED =
>
> > > >

From: Randy Pope
Date: Mon, Apr 09 2012 7:35PM
Subject: Re: Web Analytics
← Previous message | Next message →

"Individuals with disabilities have historically been quite opposed to
self-identification of assistive technology to web site authors."

From a hearing person's perspective, I can see where you are coming from.
But from a Deaf or DeafBlind's perspective, I respectfully disagree.

One cannot imagine the number of times that I get caught right smack in the
middle of the crossfire between the Deaf/DeafBlind and other people with
disabilities in regards to their thoughts how accessible websites should be
design. Even the hearing blind vs. DeafBlind or Deaf vs. DeafBlind gets
into heated debates over the inaccessible of audio and caption information.

One can never crease to be amazed of the different perspectives. For
anyone's information, I'm DeafBlind.

Randy Pope

From: deborah.kaplan
Date: Mon, Apr 09 2012 7:37PM
Subject: Re: Web Analytics
← Previous message | Next message →

Randy, I agree -- not in terms of this specific issue, for which I have no particular opinions, but in the general sense that

> One cannot imagine the number of times that I get caught right smack in the
> middle of the crossfire between [people with different]
> disabilities in regards to their thoughts how accessible websites should be
> design.

As an accessibility professional, I try to design for everybody, but as a person with disabilities, I am of course primed to see my accessibility need (hands-free computer use) first. With websites, the needs difference between the primary group people think of when they think "web accessibility users" (which seems to be pretty universally screen reader users) and hands-free use has been marked, but not necessarily in conflict. It's more obvious for me in mobile design, where screen reader accessibility and hands-free accessibility have been so far met in completely conflicting ways.

It's good to remember that people with disabilities have needs, if anything, more heterogeneous than the needs of the able-bodied population. Even within the limited screenreader population, the WebAIM screenreader survey results remind us that there is no typical screen reader user.

(I was reminded of this yesterday when I was reading an article in which autistic self-advocates expressed anger with the type of people-first labels -- eg. "people with autism" -- that many other disability self-advocacy groups have spent years fighting *for*. Different disabilities, different needs.)

-Deborah

From: Karla Kmetz
Date: Tue, Apr 10 2012 6:08AM
Subject: Re: Web Analytics
← Previous message | Next message →

Thanks for all this information everyone. I will pass it along :)

On Mon, Apr 9, 2012 at 10:13 PM, < = EMAIL ADDRESS REMOVED = > wrote:

> Randy, I agree -- not in terms of this specific issue, for which I have no
> particular opinions, but in the general sense that
>
> > One cannot imagine the number of times that I get caught right smack in
> the
> > middle of the crossfire between [people with different]
> > disabilities in regards to their thoughts how accessible websites should
> be
> > design.
>
> As an accessibility professional, I try to design for everybody, but as a
> person with disabilities, I am of course primed to see my accessibility
> need (hands-free computer use) first. With websites, the needs difference
> between the primary group people think of when they think "web
> accessibility users" (which seems to be pretty universally screen reader
> users) and hands-free use has been marked, but not necessarily in conflict.
> It's more obvious for me in mobile design, where screen reader
> accessibility and hands-free accessibility have been so far met in
> completely conflicting ways.
>
> It's good to remember that people with disabilities have needs, if
> anything, more heterogeneous than the needs of the able-bodied population.
> Even within the limited screenreader population, the WebAIM screenreader
> survey results remind us that there is no typical screen reader user.
>
> (I was reminded of this yesterday when I was reading an article in which
> autistic self-advocates expressed anger with the type of people-first
> labels -- eg. "people with autism" -- that many other disability
> self-advocacy groups have spent years fighting *for*. Different
> disabilities, different needs.)
>
> -Deborah
> > > >



--
*Karla Kmetz, M.Ed.*
Instructional Designer
Distance Learning and Instructional Media Services
University of South Florida St. Petersburg, POY 239
Phone: 727-873-4474

From: Ryan Hemphill
Date: Tue, Apr 10 2012 9:09AM
Subject: Re: Web Analytics
← Previous message | Next message →

When I read the reason for not wanted to be identified as using an
accessibility technology, I gave a big sigh yesterday.

You can't hide the fact that you are a screen reader user. Anyone with any
understanding of screen reader behaviors would be able to detect your
technology almost immediately. Some of them are very straightforward.

(1) Clicking on a hidden link/anchor/button within a page. While this is
listed as an accessibility technique/practice, it's a red flag that you are
a screen reader user. No one else would see it in the first place and
there is definitely no one that would be able to click on it.

(2) Tabbing a lot. One focus jump after another going all over the entire
page (let along the entire site) unless it was a form would immediately
give a high probability of the user leveraging a screen reader or some
other accessibility software.

(3) Tabbing + Click event. This one would be a very strong indicator. If
the user was tabbing a lot and then clicked (via the simulated click event
that screen readers all use), the probability that the user is navigating
via screen reader is very very high. Why else would anyone tab through an
entire site only to use a mouse click once they have found what they were
looking for?

(4) I can detect, at this time, whether you are using JAWS, NVDA or
VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and might
even be able to figure out the version of JAWS with a little bit of extra
research. Given the information you have just provided (thank you for
that), I will avoid releasing how I can do this, but suffice to say - it
isn't hard once you really understand the behavioral differences from each
other and keyboard/non-screen reader users as a whole.

We need to revisit this issue. There is just no way you are going to be
able to hide many accessibility technologies from any developer on the web.
If someone has nefarious purpose for detection of your screen reader
technology or wants to detect the likeliness that you are a keyboard only
user that might have motor skill impairments, for example, you are not
going to be able to stop them.

Furthermore, you are creating a situation that makes it extraordinarily
difficult to deal with the differences between screen readers. The
compatibility issues that present themselves in rich internet applications
already make it so that JAWS, NVDA and VoiceOver are the only possible
means to handle things like focus management because it is that complex to
begin with. Add on the fact that they each handle it differently and you
are really looking at a major break between the desired avoidance of
detection and reality of making Rich Internet Apps work for these programs.
Developers who are doing Rich Internet Apps need to know what you are
using especially when the RIA becomes complex.

In our current situation at my company, we are required by law to provide
accessible solutions for screen reader users, but there is more than one
Rich Internet App in our company that require knowledge of which (JAWS,
NVDA or VoiceOver) screen reader is being used to insure failures
(interaction or formatting) don't occur. There is too much going on in
these apps for the SR software to handle it without some help as well. I
could go on for at least an hour or two about how these situations come
about and what we are doing to resolve them but mark my words, there is no
question at all that we need to know what we're working with.

I get why no one wants to be identified. No one wants their information
broadcasted to companies that want to exploit their data. It is invasive
and unsetting - I completely understand the objection.

But it isn't going to allow screen reader technologies (or others for that
matter) to maintain the pace of development that we are all witnessing even
now. I even remember seeing a post about half a year ago by a Google
employee that was stating how making some technologies accessible at this
time was extraordinarily difficult. This is Google we are talking about, a
company that hires super-geniuses to write their software - and they're
saying they can't the target. Now granted, I'm sure that there are those
among you that see this as an excuse or lack of knowledge on that person's
part - but for a massive technology driven company to have an employee
state publicly their doubts in creation of RIA accessibility - that's a
very bad sign. And we aren't doing them or any other design dev teams any
favors (or the user base it affects) by hiding the fact that you are a
screen reader user or have some other a11y tech-specific need.

If this post needs to move to a new discussion (probably not a bad idea) I
would like to continue this conversation further with anyone that wishes to
state their opinion. I am open to harsh criticism, so fire away, but I
feel very strongly that this perspective is going to hold back
accessible-friendly technology for the web in a critical and unfortunate
way. Don't get me wrong, I care very much about doing the right thing, but
as the assessment of a 15 year veteran in design/development, there is no
way this is going to work in the long run - and I am not the only person
that would tell you that.

We need to be open to telling the dev teams what tech we're shooting for.
A no-holds-barred approach to keep up with the pace we are seeing. It's
not going to slow down and you can't predict what is coming up next. I am
very unsettled and concerned by this issue.


Ryan.

From: Birkir R. Gunnarsson
Date: Tue, Apr 10 2012 9:50AM
Subject: Re: Web Analytics
← Previous message | Next message →

Ryan

You raise good points here (for one thing I have never understood the
privacy concerns of people, especially in the U.S., but that is a
completely separate thought and nothing necessarily to do with
accessibility).
The risk, to my mind, that specific detection of screen reader
technology can bring about, is still the customized behaviors of site
developers towards each specific screen reader.
I grant you that these are sometimes the only viable short-term
solutions (especially in the area you are working in), but longterm I
am worried that the responsibility of accessibility for a particular
screen reader moves from that SR developer to the website development
staff.
Users, after all, interact with a page through their screen reader and
their browser.
It is as much the SR vendors responsibility to implement standardized
behaviors, as it is the site developer to provide information in a
programatically decipherable manner.
With emergeing technologies of course this is difficult, since screen
readers typically have a new release every 6 to 12 months, moreover a
release that can be very pricy (except for NVDA), and out of reach for
a lot ofusers.
But, ultimately, screen reader vendors need to feel the heat, and have
the responsibility to adopt standards, and to consistently interpret
webpages that adhere to these standards. If the websites, instead,
start customizing the experience to a particular screen reader user,
longterm that responsibility may increasingly move to the site
developers themselves, and that would truly damage the prospect for
accessibility, which will most easily be realized through better
standarddization.
So from a longterm standpoint I am a bit worried about the customized
SR experience approach, though I perfectly agree with you, that I do
not really understand why detecting users' screen reading application
is valuable in certain cases, for customized instructions for instance
(many a time I wish I could provide relevant instructions to users of
a particular screen reader).
I could say a lot more about disabilities and opportunities, and the
apparent (to me anyway), lack of rational thinking in that regard, but
that would be entirely of-topic, and probably not overly Politically
Correct besides.
Cheers
-B

On 4/10/12, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
> When I read the reason for not wanted to be identified as using an
> accessibility technology, I gave a big sigh yesterday.
>
> You can't hide the fact that you are a screen reader user. Anyone with any
> understanding of screen reader behaviors would be able to detect your
> technology almost immediately. Some of them are very straightforward.
>
> (1) Clicking on a hidden link/anchor/button within a page. While this is
> listed as an accessibility technique/practice, it's a red flag that you are
> a screen reader user. No one else would see it in the first place and
> there is definitely no one that would be able to click on it.
>
> (2) Tabbing a lot. One focus jump after another going all over the entire
> page (let along the entire site) unless it was a form would immediately
> give a high probability of the user leveraging a screen reader or some
> other accessibility software.
>
> (3) Tabbing + Click event. This one would be a very strong indicator. If
> the user was tabbing a lot and then clicked (via the simulated click event
> that screen readers all use), the probability that the user is navigating
> via screen reader is very very high. Why else would anyone tab through an
> entire site only to use a mouse click once they have found what they were
> looking for?
>
> (4) I can detect, at this time, whether you are using JAWS, NVDA or
> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and might
> even be able to figure out the version of JAWS with a little bit of extra
> research. Given the information you have just provided (thank you for
> that), I will avoid releasing how I can do this, but suffice to say - it
> isn't hard once you really understand the behavioral differences from each
> other and keyboard/non-screen reader users as a whole.
>
> We need to revisit this issue. There is just no way you are going to be
> able to hide many accessibility technologies from any developer on the web.
> If someone has nefarious purpose for detection of your screen reader
> technology or wants to detect the likeliness that you are a keyboard only
> user that might have motor skill impairments, for example, you are not
> going to be able to stop them.
>
> Furthermore, you are creating a situation that makes it extraordinarily
> difficult to deal with the differences between screen readers. The
> compatibility issues that present themselves in rich internet applications
> already make it so that JAWS, NVDA and VoiceOver are the only possible
> means to handle things like focus management because it is that complex to
> begin with. Add on the fact that they each handle it differently and you
> are really looking at a major break between the desired avoidance of
> detection and reality of making Rich Internet Apps work for these programs.
> Developers who are doing Rich Internet Apps need to know what you are
> using especially when the RIA becomes complex.
>
> In our current situation at my company, we are required by law to provide
> accessible solutions for screen reader users, but there is more than one
> Rich Internet App in our company that require knowledge of which (JAWS,
> NVDA or VoiceOver) screen reader is being used to insure failures
> (interaction or formatting) don't occur. There is too much going on in
> these apps for the SR software to handle it without some help as well. I
> could go on for at least an hour or two about how these situations come
> about and what we are doing to resolve them but mark my words, there is no
> question at all that we need to know what we're working with.
>
> I get why no one wants to be identified. No one wants their information
> broadcasted to companies that want to exploit their data. It is invasive
> and unsetting - I completely understand the objection.
>
> But it isn't going to allow screen reader technologies (or others for that
> matter) to maintain the pace of development that we are all witnessing even
> now. I even remember seeing a post about half a year ago by a Google
> employee that was stating how making some technologies accessible at this
> time was extraordinarily difficult. This is Google we are talking about, a
> company that hires super-geniuses to write their software - and they're
> saying they can't the target. Now granted, I'm sure that there are those
> among you that see this as an excuse or lack of knowledge on that person's
> part - but for a massive technology driven company to have an employee
> state publicly their doubts in creation of RIA accessibility - that's a
> very bad sign. And we aren't doing them or any other design dev teams any
> favors (or the user base it affects) by hiding the fact that you are a
> screen reader user or have some other a11y tech-specific need.
>
> If this post needs to move to a new discussion (probably not a bad idea) I
> would like to continue this conversation further with anyone that wishes to
> state their opinion. I am open to harsh criticism, so fire away, but I
> feel very strongly that this perspective is going to hold back
> accessible-friendly technology for the web in a critical and unfortunate
> way. Don't get me wrong, I care very much about doing the right thing, but
> as the assessment of a 15 year veteran in design/development, there is no
> way this is going to work in the long run - and I am not the only person
> that would tell you that.
>
> We need to be open to telling the dev teams what tech we're shooting for.
> A no-holds-barred approach to keep up with the pace we are seeing. It's
> not going to slow down and you can't predict what is coming up next. I am
> very unsettled and concerned by this issue.
>
>
> Ryan.
> > > >

From: Jared Smith
Date: Tue, Apr 10 2012 10:05AM
Subject: Re: Web Analytics
← Previous message | Next message →

On Tue, Apr 10, 2012 at 9:09 AM, Ryan Hemphill wrote:

>  Developers who are doing Rich Internet Apps need to know what you are
> using especially when the RIA becomes complex.

As you note, you can, to some extent, detect screen readers (though I
think there are flaws in most of the methods you prescribe). The real
question is what would/should developers do with this knowledge?

Trying to address quirks, bugs, inconsistencies, and incompatibilities
in assistive technologies is a never ending process. You'll drive your
development staff mad trying to make things work perfectly across
assistive technologies. It cannot be done. The bulk of these problems
should not lie on developers, but on the assistive technology vendors.
They will never address these issues if developers continually cater
to them. If a developer follows standards and builds a web app
accessibly, yet it is not accessible due to a bug in a screen reader,
is that the developer's fault?

As Birkir notes, our efforts would be much better spent in improving
AT support for standards rather than catering to their lack of
standards support. With that said, we need to be considerate of the
end user experience. But providing distinct user experiences,
customized code, and hacks per screen reader or screen reader version
is going down a hole that has no bottom.

Jared

From: Tim Harshbarger
Date: Tue, Apr 10 2012 11:38AM
Subject: Re: Web Analytics
← Previous message | Next message →

Jared makes good points. I will try to make another good point.

One of the big issues with this approach isn't technical but social. People with disabilities have experienced and do experience discrimination based on their disability. One thing people with disabilities seem to prize on the internet is having the opportunity to interact with other people and organizations without their disability becoming known. While it might be hard to believe in this day and age, interactions with organizations and other people can be qualitatively different if disability isn't one of the factors.
Another factor in this attitude might be too many well intentioned people with little understanding. Basically, this approach is like saying "trust me, I know exactly what you need." I expect we all here are in a better position to understand what the user might need or want--but I expect everyone on this list with a disability has stories about well-intentioned people who felt they should make a decision on behalf of a person with a disability--and things ended up in disaster. But I am just guessing about this part.

So, the population we want to design user interfaces for is going to be somewhat resistant to us trying to determine if they have a disability and then prescribing their user experience for them based on that information. I even suspect that most of them would be more comfortable answering a question like "Do you want white text on a black background?" rather than "Are you a person with a visual impairment?"--not to mention it probably will get more answers since not all people we might define as having a disability define themselves as having a disability.

I do realize that when we design user interfaces, we have to make decisions based on what we think the users might need or want. I just think that people with disabilities would see a big difference between universal design and AT sniffing.

That is just my two cents worth--or the denomination of your own choosing.

Tim


I definitely understand the desire of some of the people in this community to want that information about users--we all want to be able to give people the best user experience we possibly can design. With this approach, I think the problem we run into is people with disabilities have had a lot of bad experiences with that identification approach. Screen reader only pages, anyone?

From: Ryan Hemphill
Date: Tue, Apr 10 2012 12:04PM
Subject: Re: Web Analytics
← Previous message | Next message →

I understand your thoughts...and at the same time, my company is not in a
position to wait on the AT software to get squared away. Our students need
things to work and there are a whole slew of challenges to making sure that
a Rich Internet App is stable. There are a whole slew of factors causing
these problems and you are absolutely right. It IS maddening. But it also
needs to be done to insure things work, and work in the here and now.

There is another thing, however, that makes me feel that waiting on the AT
software to get their act together is not a good idea. With the things
that I have experienced and discovered, I am fairly certain that the QA
resources available to these AT companies just can't possibly be aware of a
lot of the problems that we are seeing. Some of them are simple, others
are fairly complex. One of the key benefits that can come up when hacks are
leveraged is that it can give insight to the original software developers
into where some of the holes are and ALSO what kinds of desired behaviors
are out there.

Hacks can be, in many very real ways, improved bug identification and
feedback on what is wanted in the wild. It can help the AT company
actually get more in touch with what is going on outside their 4 walls. In
other words, it can help them adapt - which is exactly what we're all
looking for, right? Will there be excuses? Sure. But it could also
result in more people pushing for fixes because the communication door
opens up a lot more. I think we should be trying to do hacks and we should
be sharing them and how/why we're doing them and what makes it work as
opposed to the normal method.

If we look back at the browser compatibility issues that we have all seen
in the past, no one assumed that IE was going to fix anything very quickly
(sound familiar) and that something needed to be done in the meantime to
bridge the gap. And in most cases, it was successful. One of the greatest
successes was jQuery, something that had an amazing effect on the web on a
whole. jQuery could be considered one of the most beautiful hacks ever
made for the internet - and no one would argue that it shouldn't have been
done or it's long term value.

So there is my take. Just like the IE challenges that we have seen in the
past, screen readers are the new browser compatibility messes. It is my
opinion that avoiding hacks doesn't necessarily improve things for the
user, and it does bring light to bugs that might actually get the attention
of the developers who made the product.

Birkir is also right (thanks for the feedback, Birkir), the
hacks/normalization attempts may create some compatibility issues, but I
still think that taking the problem on gives us an opportunity to move
forward. I also feel that if people are willing to engage the hacks that
can make things operate the way they are supposed to, those people will
probably (not always, I admit) be open to suggestions their work to improve
compatibility and results. I remember reading about a hack for refreshing
content on a web page from Lemon that really helped. Despite the fact
that his attempt didn't work in my case, it gave me insight into what the
screen reader was doing and I was able to find another way to get the
problem fixed without his hacks.

The imple truth is that I can't wait for them to get their act together.
My job requires me to get around the failures and shortcomings that they
present as soon as I can manage.

However, outside of my job I also feel that we can't accelerate web
development to try and match pace with future needs without plunging into
the things that can make up that gap. The ATs shouldn't make the patterns,
we should. If we make it happen, they will have to pursue the requirements
that we are creating. If we wait for them to catch up - they are setting
the pace and rules. That is exactly what is happening right now. I feel
that waiting for them to fix the basic specs we want them to work towards
puts them in the driver's seat - and we have to be patient and wait it out.
I don't like that much at all.

not that I feel passionate about my position on this at all. ;)

Ryan.



On Tue, Apr 10, 2012 at 12:05 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Tue, Apr 10, 2012 at 9:09 AM, Ryan Hemphill wrote:
>
> > Developers who are doing Rich Internet Apps need to know what you are
> > using especially when the RIA becomes complex.
>
> As you note, you can, to some extent, detect screen readers (though I
> think there are flaws in most of the methods you prescribe). The real
> question is what would/should developers do with this knowledge?
>
> Trying to address quirks, bugs, inconsistencies, and incompatibilities
> in assistive technologies is a never ending process. You'll drive your
> development staff mad trying to make things work perfectly across
> assistive technologies. It cannot be done. The bulk of these problems
> should not lie on developers, but on the assistive technology vendors.
> They will never address these issues if developers continually cater
> to them. If a developer follows standards and builds a web app
> accessibly, yet it is not accessible due to a bug in a screen reader,
> is that the developer's fault?
>
> As Birkir notes, our efforts would be much better spent in improving
> AT support for standards rather than catering to their lack of
> standards support. With that said, we need to be considerate of the
> end user experience. But providing distinct user experiences,
> customized code, and hacks per screen reader or screen reader version
> is going down a hole that has no bottom.
>
> Jared
> > > >



--



Shipping is a Feature...Perhaps the Most Important Feature.

From: Will Grignon
Date: Tue, Apr 10 2012 12:05PM
Subject: Re: Web Analytics
← Previous message | Next message →

As a blind user, I would think that the issue of forced identification can
be quite important in the employment arena, where disabled applicants, who
are required to do things like fill out online applications might want to
prevent potential employers from knowing they are disabled. Since, The
decision when/if to disclose is a very personal one and giving potential
employers the ability to determine which applicants are using AT might give
rise to fears that these employers are (either consciously or subliminally)
using this capability to "weed out" disabled candidates.

Although, I suppose that potential employers can counter that, while the ADA
does not require a disabled applicant to disclose a disability at the
application stage (or even the interview stage) of the employment process,
disabled applicants are required to notify potential employers of a
disability if that disabled applicant is requesting reasonable
accommodations in order to complete the application process.

However, I can imagine that such disabled applicants could make a case that
AT is a passive technological accommodation that does not require express
disclosure of a disability to the employer and therefore should not
incorporate the employer's ability to identify applicants who use such AT
functionality.

An interesting question would arise if the potential employer's web-based
employment processes either malfunction or do not contain adequately
accessible functionality, and the disabled applicant is then forced to
contact the potential employer and, compelled against her private wishes,
identify herself as disabled and in need of reasonable accommodation AT...

From: Lucy Greco
Date: Tue, Apr 10 2012 12:06PM
Subject: Re: Web Analytics
← Previous message | Next message →

Hello:
there would be no point in determining that a screen reader user is accessing your website because every single screen reader works differently than the other. You can't go out and detect every single competitive screen reader and expect to have a modified version of your website. So are you going to code your tables differently for JAWS then you would with chrome vox? Are you going to make your website change to voiceover compatible or are you going to work with NVDA or window eyes. Maybe the visitor is using guide or the full supernova suite.

It's none of our business what the person is using to access our website I know there are people out there still using links but we don't code for that either. I know it's already been said on this thread but equal access means you made a good site that works for as many people as possible. Who cares what screen reader they're using. Who cares if they're using a screen reader the website should work and work for everyone. I don't want Amazon to know if I'm blind or not I don't want you to know if I'm blind or not I just want you to consider me a potential visitor to your website and make it work.

Once all this is been said and done as a trainer I need to be able to test something at home on my machine and understand how it works then go to a client system and not have any surprises because they might be using an earlier version of the screen reader or the browser or the OS.

Lucy Greco
Assistive Technology Specialist
Disabled Student's Program UC Berkeley
(510) 643-7591
http://attlc.berkeley.edu
http://webaccess.berkeley.edu

From: Ryan Hemphill
Date: Tue, Apr 10 2012 12:14PM
Subject: Re: Web Analytics
← Previous message | Next message →

Thanks for bringing up the issue around employment - I can definitely
appreciate this as a potential example where screen reader detection would
be a problem. As I mentioned, it is almost impossible to avoid SR
detection, but I get why this is a concern.

Ryan



On Tue, Apr 10, 2012 at 2:05 PM, Will Grignon < = EMAIL ADDRESS REMOVED = >wrote:

> As a blind user, I would think that the issue of forced identification can
> be quite important in the employment arena, where disabled applicants, who
> are required to do things like fill out online applications might want to
> prevent potential employers from knowing they are disabled. Since, The
> decision when/if to disclose is a very personal one and giving potential
> employers the ability to determine which applicants are using AT might give
> rise to fears that these employers are (either consciously or subliminally)
> using this capability to "weed out" disabled candidates.
>
> Although, I suppose that potential employers can counter that, while the
> ADA
> does not require a disabled applicant to disclose a disability at the
> application stage (or even the interview stage) of the employment process,
> disabled applicants are required to notify potential employers of a
> disability if that disabled applicant is requesting reasonable
> accommodations in order to complete the application process.
>
> However, I can imagine that such disabled applicants could make a case that
> AT is a passive technological accommodation that does not require express
> disclosure of a disability to the employer and therefore should not
> incorporate the employer's ability to identify applicants who use such AT
> functionality.
>
> An interesting question would arise if the potential employer's web-based
> employment processes either malfunction or do not contain adequately
> accessible functionality, and the disabled applicant is then forced to
> contact the potential employer and, compelled against her private wishes,
> identify herself as disabled and in need of reasonable accommodation AT...
>
>

From: Ryan Hemphill
Date: Tue, Apr 10 2012 1:37PM
Subject: Re: Web Analytics
← Previous message | Next message →

Hi Lucy, I understand what you are saying. I get it - I really do, but
technology-wise it's just not going to work in a Rich Internet App
environment. It isn't about what I want - I would much rather not have to
worry about the differences, it's a royal pain in the neck - but there are
only 3 screen readers that can truly handle Rich Internet apps at this time
(Focus Management and ARIA support) and the rest wouldn't be able to use
most those sites at all even if they wanted to. Granted I haven't worked
with ChromeVox much yet and that is a possible 4th.

It's annoying, it's upsetting and a whole list of other things that
shouldn't be said in public - but logistically, I can't see how we can move
forward and avoid these things. There is simply too much noise and most
dev/design teams would throw up their hands if they were dealing with a RIA
that needed to be made accessible, just like the guy at Google expressed.
This may be the reason they created their own SR. That being said, I have
been hammering away at that particular plugin and it doesn't work very
nicely in the RIA version of Gmail at all - or maybe I haven't figured out
how to use it just yet.

In most cases I would not be coding up tables or things like that any
differently - it's when we start getting into the interactive aspects.
Jumping back and forth through focus management techniques. Being able
to drop focus onto modal windows and use it in several different methods
without the screen reader going up in flames is a perfect example. I
actually had to take the AEGIS plugin (considered fully accessible, for
those who don't know) for modal/dialog and revamp it so that it would
behave like a typical modal window and work across multiple screen readers.
Part of fixing it required me to actually remove the role="dialog"
attribute because it seriously screwed up our ability to extend its usage.
ARIA actually REDUCED the accessibility of the widget. Imagine that! And
it didn't have the same effects on different SRs (NVDA and JAWS) until we
played around with it for some time. I can tell you some other bugs that
would have been introduced if we'd kept the native version, one of which
has the potential to break the whole site and kill the virtual buffer
permanently in JAWS, by the way. VoiceOver hasn't been handled yet, but
making that one work requires a different tweak to pull it off. Does it
matter? I would say yes. Purchasing textbooks cross-platform should
definitely be a priority use case for screen reader users. Would that
require compatibility hacks? Also yes.

This isn't something I love spending my time doing. It's something that
has to be done to insure accessibility of the site, which in this case is
for purchasing textbooks, by the way. SRs like Windows Eyes don't do focus
management at all, so we didn't even bother testing that SR because it
simply can't handle the interactive requirements of the site. Could we
make this site work for all SRs? Yes, we could as a basic page with no
bells and whistles at all. Could we make the site work for all SRs and also
have rich internet behaviors which involve focus management and possibly
ARIA attributes? NO WAY. Can I tell the marketing team to cease using
these features? They would laugh me right out of the room.

I go back to what I said before - we can't move forward if we're constantly
expecting to wait for the AT companies to get their act together and all
pull in the accessibility row boat in tandem. There is a good chance many
of the SRs aren't going to be considered usable for the web at all in a
short while, such as Windows Eyes, if they don't get their act together.

All that being said, I do appreciate your passion for the topic.

Ryan



On Tue, Apr 10, 2012 at 2:06 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = >wrote:

> Hello:
> there would be no point in determining that a screen reader user is
> accessing your website because every single screen reader works differently
> than the other. You can't go out and detect every single competitive
> screen reader and expect to have a modified version of your website. So
> are you going to code your tables differently for JAWS then you would with
> chrome vox? Are you going to make your website change to voiceover
> compatible or are you going to work with NVDA or window eyes. Maybe the
> visitor is using guide or the full supernova suite.
>
> It's none of our business what the person is using to access our website I
> know there are people out there still using links but we don't code for
> that either. I know it's already been said on this thread but equal access
> means you made a good site that works for as many people as possible. Who
> cares what screen reader they're using. Who cares if they're using a
> screen reader the website should work and work for everyone. I don't want
> Amazon to know if I'm blind or not I don't want you to know if I'm blind or
> not I just want you to consider me a potential visitor to your website and
> make it work.
>
> Once all this is been said and done as a trainer I need to be able to test
> something at home on my machine and understand how it works then go to a
> client system and not have any surprises because they might be using an
> earlier version of the screen reader or the browser or the OS.
>
> Lucy Greco
> Assistive Technology Specialist
> Disabled Student's Program UC Berkeley
> (510) 643-7591
> http://attlc.berkeley.edu
> http://webaccess.berkeley.edu
>
>
>

From: Birkir R. Gunnarsson
Date: Tue, Apr 10 2012 2:57PM
Subject: Re: Web Analytics
← Previous message | Next message →

I have always wondered about this attitude.
Firstly, it supposes that most employers find people with disabilities
undesireable to begin with (and isn't it the real problem and where
the change has to occur, if it is true, I have not found this in my
personal experience).

Secondly, by not disclosing their disability people are setting
themselves up for problems in the interview and testing process. I
have come across this multiple times where I have not done well on
inaccessible testing accomodations or surveys related to the job. With
better accessibility and accomodation requests I believe I could have
had a shot at some jobs I did not manage to get (of course there is no
way to prove this).

Thirdly, I believe most people's disabilities will become apparent
before they sign the job contract, so it will be an issue sooner or
later in the process. If an employer feels this is a major hindrance,
the/she has ample opportunity to exclude a candidate from the position
before the final decission is made. Being too evasive about your
disability will probably give of the impression that it is a big issue
for the job, and your potential employer may feel you were not honest
in the process, which further reduces your chances of landing said
job.

Forthly, if you require accommodations to do the job well, it is
better (in my opinion, which is perhaps not humble enough), to be open
and honest about that during the process itself. I have found that
sometimes it works in my favor when an interviewer actually sees me
analyze a spreadsheet during an interview, which leaves a positive
impression that may actually give me the edge.

But I digress, I still think people need to discuss thse things openly
and with a critical
attitude (though admittedly probably not on this list).
Cheers
-B

On 4/10/12, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Lucy, I understand what you are saying. I get it - I really do, but
> technology-wise it's just not going to work in a Rich Internet App
> environment. It isn't about what I want - I would much rather not have to
> worry about the differences, it's a royal pain in the neck - but there are
> only 3 screen readers that can truly handle Rich Internet apps at this time
> (Focus Management and ARIA support) and the rest wouldn't be able to use
> most those sites at all even if they wanted to. Granted I haven't worked
> with ChromeVox much yet and that is a possible 4th.
>
> It's annoying, it's upsetting and a whole list of other things that
> shouldn't be said in public - but logistically, I can't see how we can move
> forward and avoid these things. There is simply too much noise and most
> dev/design teams would throw up their hands if they were dealing with a RIA
> that needed to be made accessible, just like the guy at Google expressed.
> This may be the reason they created their own SR. That being said, I have
> been hammering away at that particular plugin and it doesn't work very
> nicely in the RIA version of Gmail at all - or maybe I haven't figured out
> how to use it just yet.
>
> In most cases I would not be coding up tables or things like that any
> differently - it's when we start getting into the interactive aspects.
> Jumping back and forth through focus management techniques. Being able
> to drop focus onto modal windows and use it in several different methods
> without the screen reader going up in flames is a perfect example. I
> actually had to take the AEGIS plugin (considered fully accessible, for
> those who don't know) for modal/dialog and revamp it so that it would
> behave like a typical modal window and work across multiple screen readers.
> Part of fixing it required me to actually remove the role="dialog"
> attribute because it seriously screwed up our ability to extend its usage.
> ARIA actually REDUCED the accessibility of the widget. Imagine that! And
> it didn't have the same effects on different SRs (NVDA and JAWS) until we
> played around with it for some time. I can tell you some other bugs that
> would have been introduced if we'd kept the native version, one of which
> has the potential to break the whole site and kill the virtual buffer
> permanently in JAWS, by the way. VoiceOver hasn't been handled yet, but
> making that one work requires a different tweak to pull it off. Does it
> matter? I would say yes. Purchasing textbooks cross-platform should
> definitely be a priority use case for screen reader users. Would that
> require compatibility hacks? Also yes.
>
> This isn't something I love spending my time doing. It's something that
> has to be done to insure accessibility of the site, which in this case is
> for purchasing textbooks, by the way. SRs like Windows Eyes don't do focus
> management at all, so we didn't even bother testing that SR because it
> simply can't handle the interactive requirements of the site. Could we
> make this site work for all SRs? Yes, we could as a basic page with no
> bells and whistles at all. Could we make the site work for all SRs and also
> have rich internet behaviors which involve focus management and possibly
> ARIA attributes? NO WAY. Can I tell the marketing team to cease using
> these features? They would laugh me right out of the room.
>
> I go back to what I said before - we can't move forward if we're constantly
> expecting to wait for the AT companies to get their act together and all
> pull in the accessibility row boat in tandem. There is a good chance many
> of the SRs aren't going to be considered usable for the web at all in a
> short while, such as Windows Eyes, if they don't get their act together.
>
> All that being said, I do appreciate your passion for the topic.
>
> Ryan
>
>
>
> On Tue, Apr 10, 2012 at 2:06 PM, Lucy Greco
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Hello:
>> there would be no point in determining that a screen reader user is
>> accessing your website because every single screen reader works
>> differently
>> than the other. You can't go out and detect every single competitive
>> screen reader and expect to have a modified version of your website. So
>> are you going to code your tables differently for JAWS then you would with
>> chrome vox? Are you going to make your website change to voiceover
>> compatible or are you going to work with NVDA or window eyes. Maybe the
>> visitor is using guide or the full supernova suite.
>>
>> It's none of our business what the person is using to access our website I
>> know there are people out there still using links but we don't code for
>> that either. I know it's already been said on this thread but equal
>> access
>> means you made a good site that works for as many people as possible. Who
>> cares what screen reader they're using. Who cares if they're using a
>> screen reader the website should work and work for everyone. I don't want
>> Amazon to know if I'm blind or not I don't want you to know if I'm blind
>> or
>> not I just want you to consider me a potential visitor to your website and
>> make it work.
>>
>> Once all this is been said and done as a trainer I need to be able to test
>> something at home on my machine and understand how it works then go to a
>> client system and not have any surprises because they might be using an
>> earlier version of the screen reader or the browser or the OS.
>>
>> Lucy Greco
>> Assistive Technology Specialist
>> Disabled Student's Program UC Berkeley
>> (510) 643-7591
>> http://attlc.berkeley.edu
>> http://webaccess.berkeley.edu
>>
>>
>>

From: Will Grignon
Date: Tue, Apr 10 2012 3:24PM
Subject: Re: Web Analytics
← Previous message | Next message →

This is certainly an ongoing debate within the disability community, with
equally passionate encouragement for full up front disclosure as well as
calls for judicious delay as long as possible.

This dichotomy seems to be further fragmented between those with
obvious/apparent disabilities and those who have "invisible" disabilities,
with the former tending (but by no means unanimously) toward up front
disclosure and the latter tending (again, by no means unanimously) toward
delayed disclosure until legally or functionally compelled to disclose.

Generally, it would be nice to think that employers do not discriminate on
the basis of disability, but research continues to show widespread
discrimination. Given this ongoing reality, it would seem that AT could
afford some protection for those who wish not to disclose by eliminating the
means by which a potential employer could determine if a candidate has used
AT in the application process.

This would not eliminate discrimination or obviate a disabled person's need
to disclose when necessary, but it would give that person some more freedom
and flexibility as to when and how she discloses her disability.

From: Stella Mudd
Date: Tue, Apr 10 2012 3:37PM
Subject: Re: Web Analytics
← Previous message | Next message →

Two words: dojo toolkit.

On 4/10/12, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Lucy, I understand what you are saying. I get it - I really do, but
> technology-wise it's just not going to work in a Rich Internet App
> environment. It isn't about what I want - I would much rather not have to
> worry about the differences, it's a royal pain in the neck - but there are
> only 3 screen readers that can truly handle Rich Internet apps at this time
> (Focus Management and ARIA support) and the rest wouldn't be able to use
> most those sites at all even if they wanted to. Granted I haven't worked
> with ChromeVox much yet and that is a possible 4th.
>
> It's annoying, it's upsetting and a whole list of other things that
> shouldn't be said in public - but logistically, I can't see how we can move
> forward and avoid these things. There is simply too much noise and most
> dev/design teams would throw up their hands if they were dealing with a RIA
> that needed to be made accessible, just like the guy at Google expressed.
> This may be the reason they created their own SR. That being said, I have
> been hammering away at that particular plugin and it doesn't work very
> nicely in the RIA version of Gmail at all - or maybe I haven't figured out
> how to use it just yet.
>
> In most cases I would not be coding up tables or things like that any
> differently - it's when we start getting into the interactive aspects.
> Jumping back and forth through focus management techniques. Being able
> to drop focus onto modal windows and use it in several different methods
> without the screen reader going up in flames is a perfect example. I
> actually had to take the AEGIS plugin (considered fully accessible, for
> those who don't know) for modal/dialog and revamp it so that it would
> behave like a typical modal window and work across multiple screen readers.
> Part of fixing it required me to actually remove the role="dialog"
> attribute because it seriously screwed up our ability to extend its usage.
> ARIA actually REDUCED the accessibility of the widget. Imagine that! And
> it didn't have the same effects on different SRs (NVDA and JAWS) until we
> played around with it for some time. I can tell you some other bugs that
> would have been introduced if we'd kept the native version, one of which
> has the potential to break the whole site and kill the virtual buffer
> permanently in JAWS, by the way. VoiceOver hasn't been handled yet, but
> making that one work requires a different tweak to pull it off. Does it
> matter? I would say yes. Purchasing textbooks cross-platform should
> definitely be a priority use case for screen reader users. Would that
> require compatibility hacks? Also yes.
>
> This isn't something I love spending my time doing. It's something that
> has to be done to insure accessibility of the site, which in this case is
> for purchasing textbooks, by the way. SRs like Windows Eyes don't do focus
> management at all, so we didn't even bother testing that SR because it
> simply can't handle the interactive requirements of the site. Could we
> make this site work for all SRs? Yes, we could as a basic page with no
> bells and whistles at all. Could we make the site work for all SRs and also
> have rich internet behaviors which involve focus management and possibly
> ARIA attributes? NO WAY. Can I tell the marketing team to cease using
> these features? They would laugh me right out of the room.
>
> I go back to what I said before - we can't move forward if we're constantly
> expecting to wait for the AT companies to get their act together and all
> pull in the accessibility row boat in tandem. There is a good chance many
> of the SRs aren't going to be considered usable for the web at all in a
> short while, such as Windows Eyes, if they don't get their act together.
>
> All that being said, I do appreciate your passion for the topic.
>
> Ryan
>
>
>
> On Tue, Apr 10, 2012 at 2:06 PM, Lucy Greco
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Hello:
>> there would be no point in determining that a screen reader user is
>> accessing your website because every single screen reader works
>> differently
>> than the other. You can't go out and detect every single competitive
>> screen reader and expect to have a modified version of your website. So
>> are you going to code your tables differently for JAWS then you would with
>> chrome vox? Are you going to make your website change to voiceover
>> compatible or are you going to work with NVDA or window eyes. Maybe the
>> visitor is using guide or the full supernova suite.
>>
>> It's none of our business what the person is using to access our website I
>> know there are people out there still using links but we don't code for
>> that either. I know it's already been said on this thread but equal
>> access
>> means you made a good site that works for as many people as possible. Who
>> cares what screen reader they're using. Who cares if they're using a
>> screen reader the website should work and work for everyone. I don't want
>> Amazon to know if I'm blind or not I don't want you to know if I'm blind
>> or
>> not I just want you to consider me a potential visitor to your website and
>> make it work.
>>
>> Once all this is been said and done as a trainer I need to be able to test
>> something at home on my machine and understand how it works then go to a
>> client system and not have any surprises because they might be using an
>> earlier version of the screen reader or the browser or the OS.
>>
>> Lucy Greco
>> Assistive Technology Specialist
>> Disabled Student's Program UC Berkeley
>> (510) 643-7591
>> http://attlc.berkeley.edu
>> http://webaccess.berkeley.edu
>>
>>
>>

From: Stella Mudd
Date: Tue, Apr 10 2012 3:40PM
Subject: Re: Web Analytics
← Previous message | Next message →

Two words, dojo toolkit.

On Tuesday, April 10, 2012, Ryan Hemphill wrote:

> Hi Lucy, I understand what you are saying. I get it - I really do, but
> technology-wise it's just not going to work in a Rich Internet App
> environment. It isn't about what I want - I would much rather not have to
> worry about the differences, it's a royal pain in the neck - but there are
> only 3 screen readers that can truly handle Rich Internet apps at this time
> (Focus Management and ARIA support) and the rest wouldn't be able to use
> most those sites at all even if they wanted to. Granted I haven't worked
> with ChromeVox much yet and that is a possible 4th.
>
> It's annoying, it's upsetting and a whole list of other things that
> shouldn't be said in public - but logistically, I can't see how we can move
> forward and avoid these things. There is simply too much noise and most
> dev/design teams would throw up their hands if they were dealing with a RIA
> that needed to be made accessible, just like the guy at Google expressed.
> This may be the reason they created their own SR. That being said, I have
> been hammering away at that particular plugin and it doesn't work very
> nicely in the RIA version of Gmail at all - or maybe I haven't figured out
> how to use it just yet.
>
> In most cases I would not be coding up tables or things like that any
> differently - it's when we start getting into the interactive aspects.
> Jumping back and forth through focus management techniques. Being able
> to drop focus onto modal windows and use it in several different methods
> without the screen reader going up in flames is a perfect example. I
> actually had to take the AEGIS plugin (considered fully accessible, for
> those who don't know) for modal/dialog and revamp it so that it would
> behave like a typical modal window and work across multiple screen readers.
> Part of fixing it required me to actually remove the role="dialog"
> attribute because it seriously screwed up our ability to extend its usage.
> ARIA actually REDUCED the accessibility of the widget. Imagine that! And
> it didn't have the same effects on different SRs (NVDA and JAWS) until we
> played around with it for some time. I can tell you some other bugs that
> would have been introduced if we'd kept the native version, one of which
> has the potential to break the whole site and kill the virtual buffer
> permanently in JAWS, by the way. VoiceOver hasn't been handled yet, but
> making that one work requires a different tweak to pull it off. Does it
> matter? I would say yes. Purchasing textbooks cross-platform should
> definitely be a priority use case for screen reader users. Would that
> require compatibility hacks? Also yes.
>
> This isn't something I love spending my time doing. It's something that
> has to be done to insure accessibility of the site, which in this case is
> for purchasing textbooks, by the way. SRs like Windows Eyes don't do focus
> management at all, so we didn't even bother testing that SR because it
> simply can't handle the interactive requirements of the site. Could we
> make this site work for all SRs? Yes, we could as a basic page with no
> bells and whistles at all. Could we make the site work for all SRs and also
> have rich internet behaviors which involve focus management and possibly
> ARIA attributes? NO WAY. Can I tell the marketing team to cease using
> these features? They would laugh me right out of the room.
>
> I go back to what I said before - we can't move forward if we're constantly
> expecting to wait for the AT companies to get their act together and all
> pull in the accessibility row boat in tandem. There is a good chance many
> of the SRs aren't going to be considered usable for the web at all in a
> short while, such as Windows Eyes, if they don't get their act together.
>
> All that being said, I do appreciate your passion for the topic.
>
> Ryan
>
>
>
> On Tue, Apr 10, 2012 at 2:06 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = <javascript:;>
> >wrote:
>
> > Hello:
> > there would be no point in determining that a screen reader user is
> > accessing your website because every single screen reader works
> differently
> > than the other. You can't go out and detect every single competitive
> > screen reader and expect to have a modified version of your website. So
> > are you going to code your tables differently for JAWS then you would
> with
> > chrome vox? Are you going to make your website change to voiceover
> > compatible or are you going to work with NVDA or window eyes. Maybe the
> > visitor is using guide or the full supernova suite.
> >
> > It's none of our business what the person is using to access our website
> I
> > know there are people out there still using links but we don't code for
> > that either. I know it's already been said on this thread but equal
> access
> > means you made a good site that works for as many people as possible.
> Who
> > cares what screen reader they're using. Who cares if they're using a
> > screen reader the website should work and work for everyone. I don't
> want
> > Amazon to know if I'm blind or not I don't want you to know if I'm blind
> or
> > not I just want you to consider me a potential visitor to your website
> and
> > make it work.
> >
> > Once all this is been said and done as a trainer I need to be able to
> test
> > something at home on my machine and understand how it works then go to a
> > client system and not have any surprises because they might be using an
> > earlier version of the screen reader or the browser or the OS.
> >
> > Lucy Greco
> > Assistive Technology Specialist
> > Disabled Student's Program UC Berkeley
> > (510) 643-7591
> > http://attlc.berkeley.edu
> > http://webaccess.berkeley.edu
> >
> >
> >

From: Stella Mudd
Date: Tue, Apr 10 2012 3:40PM
Subject: Re: Web Analytics
← Previous message | Next message →

Two words: dojo toolkit.

On Tuesday, April 10, 2012, Ryan Hemphill wrote:

> Hi Lucy, I understand what you are saying. I get it - I really do, but
> technology-wise it's just not going to work in a Rich Internet App
> environment. It isn't about what I want - I would much rather not have to
> worry about the differences, it's a royal pain in the neck - but there are
> only 3 screen readers that can truly handle Rich Internet apps at this time
> (Focus Management and ARIA support) and the rest wouldn't be able to use
> most those sites at all even if they wanted to. Granted I haven't worked
> with ChromeVox much yet and that is a possible 4th.
>
> It's annoying, it's upsetting and a whole list of other things that
> shouldn't be said in public - but logistically, I can't see how we can move
> forward and avoid these things. There is simply too much noise and most
> dev/design teams would throw up their hands if they were dealing with a RIA
> that needed to be made accessible, just like the guy at Google expressed.
> This may be the reason they created their own SR. That being said, I have
> been hammering away at that particular plugin and it doesn't work very
> nicely in the RIA version of Gmail at all - or maybe I haven't figured out
> how to use it just yet.
>
> In most cases I would not be coding up tables or things like that any
> differently - it's when we start getting into the interactive aspects.
> Jumping back and forth through focus management techniques. Being able
> to drop focus onto modal windows and use it in several different methods
> without the screen reader going up in flames is a perfect example. I
> actually had to take the AEGIS plugin (considered fully accessible, for
> those who don't know) for modal/dialog and revamp it so that it would
> behave like a typical modal window and work across multiple screen readers.
> Part of fixing it required me to actually remove the role="dialog"
> attribute because it seriously screwed up our ability to extend its usage.
> ARIA actually REDUCED the accessibility of the widget. Imagine that! And
> it didn't have the same effects on different SRs (NVDA and JAWS) until we
> played around with it for some time. I can tell you some other bugs that
> would have been introduced if we'd kept the native version, one of which
> has the potential to break the whole site and kill the virtual buffer
> permanently in JAWS, by the way. VoiceOver hasn't been handled yet, but
> making that one work requires a different tweak to pull it off. Does it
> matter? I would say yes. Purchasing textbooks cross-platform should
> definitely be a priority use case for screen reader users. Would that
> require compatibility hacks? Also yes.
>
> This isn't something I love spending my time doing. It's something that
> has to be done to insure accessibility of the site, which in this case is
> for purchasing textbooks, by the way. SRs like Windows Eyes don't do focus
> management at all, so we didn't even bother testing that SR because it
> simply can't handle the interactive requirements of the site. Could we
> make this site work for all SRs? Yes, we could as a basic page with no
> bells and whistles at all. Could we make the site work for all SRs and also
> have rich internet behaviors which involve focus management and possibly
> ARIA attributes? NO WAY. Can I tell the marketing team to cease using
> these features? They would laugh me right out of the room.
>
> I go back to what I said before - we can't move forward if we're constantly
> expecting to wait for the AT companies to get their act together and all
> pull in the accessibility row boat in tandem. There is a good chance many
> of the SRs aren't going to be considered usable for the web at all in a
> short while, such as Windows Eyes, if they don't get their act together.
>
> All that being said, I do appreciate your passion for the topic.
>
> Ryan
>
>
>
> On Tue, Apr 10, 2012 at 2:06 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = <javascript:;>
> >wrote:
>
> > Hello:
> > there would be no point in determining that a screen reader user is
> > accessing your website because every single screen reader works
> differently
> > than the other. You can't go out and detect every single competitive
> > screen reader and expect to have a modified version of your website. So
> > are you going to code your tables differently for JAWS then you would
> with
> > chrome vox? Are you going to make your website change to voiceover
> > compatible or are you going to work with NVDA or window eyes. Maybe the
> > visitor is using guide or the full supernova suite.
> >
> > It's none of our business what the person is using to access our website
> I
> > know there are people out there still using links but we don't code for
> > that either. I know it's already been said on this thread but equal
> access
> > means you made a good site that works for as many people as possible.
> Who
> > cares what screen reader they're using. Who cares if they're using a
> > screen reader the website should work and work for everyone. I don't
> want
> > Amazon to know if I'm blind or not I don't want you to know if I'm blind
> or
> > not I just want you to consider me a potential visitor to your website
> and
> > make it work.
> >
> > Once all this is been said and done as a trainer I need to be able to
> test
> > something at home on my machine and understand how it works then go to a
> > client system and not have any surprises because they might be using an
> > earlier version of the screen reader or the browser or the OS.
> >
> > Lucy Greco
> > Assistive Technology Specialist
> > Disabled Student's Program UC Berkeley
> > (510) 643-7591
> > http://attlc.berkeley.edu
> > http://webaccess.berkeley.edu
> >
> >
> >

From: Stella Mudd
Date: Tue, Apr 10 2012 3:55PM
Subject: Re: Web Analytics
← Previous message | Next message →

Ryan you stated "Given the information you have just provided (thank you for
that), I will avoid releasing how I can do this, but suffice to say - it
isn't hard once you really understand the behavioral differences from each
other and keyboard/non-screen reader users as a whole."

If you think it is so important, why would you avoid releasing this
information? I think if your methodology is sound, the community could use
your information, unless you are under some type of NDA. Let us know.
Thanks!

On Tue, Apr 10, 2012 at 8:09 AM, Ryan Hemphill < = EMAIL ADDRESS REMOVED =
> wrote:

> When I read the reason for not wanted to be identified as using an
> accessibility technology, I gave a big sigh yesterday.
>
> You can't hide the fact that you are a screen reader user. Anyone with any
> understanding of screen reader behaviors would be able to detect your
> technology almost immediately. Some of them are very straightforward.
>
> (1) Clicking on a hidden link/anchor/button within a page. While this is
> listed as an accessibility technique/practice, it's a red flag that you are
> a screen reader user. No one else would see it in the first place and
> there is definitely no one that would be able to click on it.
>
> (2) Tabbing a lot. One focus jump after another going all over the entire
> page (let along the entire site) unless it was a form would immediately
> give a high probability of the user leveraging a screen reader or some
> other accessibility software.
>
> (3) Tabbing + Click event. This one would be a very strong indicator. If
> the user was tabbing a lot and then clicked (via the simulated click event
> that screen readers all use), the probability that the user is navigating
> via screen reader is very very high. Why else would anyone tab through an
> entire site only to use a mouse click once they have found what they were
> looking for?
>
> (4) I can detect, at this time, whether you are using JAWS, NVDA or
> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and might
> even be able to figure out the version of JAWS with a little bit of extra
> research. Given the information you have just provided (thank you for
> that), I will avoid releasing how I can do this, but suffice to say - it
> isn't hard once you really understand the behavioral differences from each
> other and keyboard/non-screen reader users as a whole.
>
> We need to revisit this issue. There is just no way you are going to be
> able to hide many accessibility technologies from any developer on the web.
> If someone has nefarious purpose for detection of your screen reader
> technology or wants to detect the likeliness that you are a keyboard only
> user that might have motor skill impairments, for example, you are not
> going to be able to stop them.
>
> Furthermore, you are creating a situation that makes it extraordinarily
> difficult to deal with the differences between screen readers. The
> compatibility issues that present themselves in rich internet applications
> already make it so that JAWS, NVDA and VoiceOver are the only possible
> means to handle things like focus management because it is that complex to
> begin with. Add on the fact that they each handle it differently and you
> are really looking at a major break between the desired avoidance of
> detection and reality of making Rich Internet Apps work for these programs.
> Developers who are doing Rich Internet Apps need to know what you are
> using especially when the RIA becomes complex.
>
> In our current situation at my company, we are required by law to provide
> accessible solutions for screen reader users, but there is more than one
> Rich Internet App in our company that require knowledge of which (JAWS,
> NVDA or VoiceOver) screen reader is being used to insure failures
> (interaction or formatting) don't occur. There is too much going on in
> these apps for the SR software to handle it without some help as well. I
> could go on for at least an hour or two about how these situations come
> about and what we are doing to resolve them but mark my words, there is no
> question at all that we need to know what we're working with.
>
> I get why no one wants to be identified. No one wants their information
> broadcasted to companies that want to exploit their data. It is invasive
> and unsetting - I completely understand the objection.
>
> But it isn't going to allow screen reader technologies (or others for that
> matter) to maintain the pace of development that we are all witnessing even
> now. I even remember seeing a post about half a year ago by a Google
> employee that was stating how making some technologies accessible at this
> time was extraordinarily difficult. This is Google we are talking about, a
> company that hires super-geniuses to write their software - and they're
> saying they can't the target. Now granted, I'm sure that there are those
> among you that see this as an excuse or lack of knowledge on that person's
> part - but for a massive technology driven company to have an employee
> state publicly their doubts in creation of RIA accessibility - that's a
> very bad sign. And we aren't doing them or any other design dev teams any
> favors (or the user base it affects) by hiding the fact that you are a
> screen reader user or have some other a11y tech-specific need.
>
> If this post needs to move to a new discussion (probably not a bad idea) I
> would like to continue this conversation further with anyone that wishes to
> state their opinion. I am open to harsh criticism, so fire away, but I
> feel very strongly that this perspective is going to hold back
> accessible-friendly technology for the web in a critical and unfortunate
> way. Don't get me wrong, I care very much about doing the right thing, but
> as the assessment of a 15 year veteran in design/development, there is no
> way this is going to work in the long run - and I am not the only person
> that would tell you that.
>
> We need to be open to telling the dev teams what tech we're shooting for.
> A no-holds-barred approach to keep up with the pace we are seeing. It's
> not going to slow down and you can't predict what is coming up next. I am
> very unsettled and concerned by this issue.
>
>
> Ryan.
> > > >

From: Ryan Hemphill
Date: Wed, Apr 11 2012 6:25AM
Subject: Re: Web Analytics
← Previous message | Next message →

Happy to answer, Stella. The reason I thought I should avoid doing so is for the reason that seemed to be stated by many in this forum. People don't want to be identified via screen reader.




On Apr 10, 2012, at 5:55 PM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:

> Ryan you stated "Given the information you have just provided (thank you for
> that), I will avoid releasing how I can do this, but suffice to say - it
> isn't hard once you really understand the behavioral differences from each
> other and keyboard/non-screen reader users as a whole."
>
> If you think it is so important, why would you avoid releasing this
> information? I think if your methodology is sound, the community could use
> your information, unless you are under some type of NDA. Let us know.
> Thanks!
>
> On Tue, Apr 10, 2012 at 8:09 AM, Ryan Hemphill < = EMAIL ADDRESS REMOVED =
>> wrote:
>
>> When I read the reason for not wanted to be identified as using an
>> accessibility technology, I gave a big sigh yesterday.
>>
>> You can't hide the fact that you are a screen reader user. Anyone with any
>> understanding of screen reader behaviors would be able to detect your
>> technology almost immediately. Some of them are very straightforward.
>>
>> (1) Clicking on a hidden link/anchor/button within a page. While this is
>> listed as an accessibility technique/practice, it's a red flag that you are
>> a screen reader user. No one else would see it in the first place and
>> there is definitely no one that would be able to click on it.
>>
>> (2) Tabbing a lot. One focus jump after another going all over the entire
>> page (let along the entire site) unless it was a form would immediately
>> give a high probability of the user leveraging a screen reader or some
>> other accessibility software.
>>
>> (3) Tabbing + Click event. This one would be a very strong indicator. If
>> the user was tabbing a lot and then clicked (via the simulated click event
>> that screen readers all use), the probability that the user is navigating
>> via screen reader is very very high. Why else would anyone tab through an
>> entire site only to use a mouse click once they have found what they were
>> looking for?
>>
>> (4) I can detect, at this time, whether you are using JAWS, NVDA or
>> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and might
>> even be able to figure out the version of JAWS with a little bit of extra
>> research. Given the information you have just provided (thank you for
>> that), I will avoid releasing how I can do this, but suffice to say - it
>> isn't hard once you really understand the behavioral differences from each
>> other and keyboard/non-screen reader users as a whole.
>>
>> We need to revisit this issue. There is just no way you are going to be
>> able to hide many accessibility technologies from any developer on the web.
>> If someone has nefarious purpose for detection of your screen reader
>> technology or wants to detect the likeliness that you are a keyboard only
>> user that might have motor skill impairments, for example, you are not
>> going to be able to stop them.
>>
>> Furthermore, you are creating a situation that makes it extraordinarily
>> difficult to deal with the differences between screen readers. The
>> compatibility issues that present themselves in rich internet applications
>> already make it so that JAWS, NVDA and VoiceOver are the only possible
>> means to handle things like focus management because it is that complex to
>> begin with. Add on the fact that they each handle it differently and you
>> are really looking at a major break between the desired avoidance of
>> detection and reality of making Rich Internet Apps work for these programs.
>> Developers who are doing Rich Internet Apps need to know what you are
>> using especially when the RIA becomes complex.
>>
>> In our current situation at my company, we are required by law to provide
>> accessible solutions for screen reader users, but there is more than one
>> Rich Internet App in our company that require knowledge of which (JAWS,
>> NVDA or VoiceOver) screen reader is being used to insure failures
>> (interaction or formatting) don't occur. There is too much going on in
>> these apps for the SR software to handle it without some help as well. I
>> could go on for at least an hour or two about how these situations come
>> about and what we are doing to resolve them but mark my words, there is no
>> question at all that we need to know what we're working with.
>>
>> I get why no one wants to be identified. No one wants their information
>> broadcasted to companies that want to exploit their data. It is invasive
>> and unsetting - I completely understand the objection.
>>
>> But it isn't going to allow screen reader technologies (or others for that
>> matter) to maintain the pace of development that we are all witnessing even
>> now. I even remember seeing a post about half a year ago by a Google
>> employee that was stating how making some technologies accessible at this
>> time was extraordinarily difficult. This is Google we are talking about, a
>> company that hires super-geniuses to write their software - and they're
>> saying they can't the target. Now granted, I'm sure that there are those
>> among you that see this as an excuse or lack of knowledge on that person's
>> part - but for a massive technology driven company to have an employee
>> state publicly their doubts in creation of RIA accessibility - that's a
>> very bad sign. And we aren't doing them or any other design dev teams any
>> favors (or the user base it affects) by hiding the fact that you are a
>> screen reader user or have some other a11y tech-specific need.
>>
>> If this post needs to move to a new discussion (probably not a bad idea) I
>> would like to continue this conversation further with anyone that wishes to
>> state their opinion. I am open to harsh criticism, so fire away, but I
>> feel very strongly that this perspective is going to hold back
>> accessible-friendly technology for the web in a critical and unfortunate
>> way. Don't get me wrong, I care very much about doing the right thing, but
>> as the assessment of a 15 year veteran in design/development, there is no
>> way this is going to work in the long run - and I am not the only person
>> that would tell you that.
>>
>> We need to be open to telling the dev teams what tech we're shooting for.
>> A no-holds-barred approach to keep up with the pace we are seeing. It's
>> not going to slow down and you can't predict what is coming up next. I am
>> very unsettled and concerned by this issue.
>>
>>
>> Ryan.
>> >> >> >>
> > >

From: Stella Mudd
Date: Wed, Apr 11 2012 8:54AM
Subject: Re: Web Analytics
← Previous message | Next message →

Ok, but you stated, "In our current situation at my company, we are
required by law to provide
accessible solutions for screen reader users, but there is more than one
Rich Internet App in our company that require knowledge of which (JAWS,
NVDA or VoiceOver) screen reader is being used to insure failures
(interaction or formatting) don't occur. There is too much going on in
these apps for the SR software to handle it without some help as well."

So, by law you are required to provide access, and you feel the only
way to adequately
do so is by doing detection. I'm guessing other individuals are in the
same boat and could use your methodology? Confused now about what is the
proper course of action in terms of Rich Internet Applications... I
recently built a rich internet application with DOJO Toolkit and did not
run into a situation where I felt I needed to do any detection. Of course,
if I were catering to JAWS 6 that might be the case, but we had to draw
some very distinct lines just as we do with visual users (e.g. we don't
support Mac IE 5). Then again, I'm not in the same situation socially,
technologically, or legally as you and others, but would love to hear more
about it to necessitate screen reader detection in RIA. Thanks for keeping
up this lively convo!!


On Wed, Apr 11, 2012 at 5:25 AM, Ryan Hemphill < = EMAIL ADDRESS REMOVED =
> wrote:

> Happy to answer, Stella. The reason I thought I should avoid doing so is
> for the reason that seemed to be stated by many in this forum. People
> don't want to be identified via screen reader.
>
>
>
>
> On Apr 10, 2012, at 5:55 PM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Ryan you stated "Given the information you have just provided (thank you
> for
> > that), I will avoid releasing how I can do this, but suffice to say - it
> > isn't hard once you really understand the behavioral differences from
> each
> > other and keyboard/non-screen reader users as a whole."
> >
> > If you think it is so important, why would you avoid releasing this
> > information? I think if your methodology is sound, the community could
> use
> > your information, unless you are under some type of NDA. Let us know.
> > Thanks!
> >
> > On Tue, Apr 10, 2012 at 8:09 AM, Ryan Hemphill <
> = EMAIL ADDRESS REMOVED =
> >> wrote:
> >
> >> When I read the reason for not wanted to be identified as using an
> >> accessibility technology, I gave a big sigh yesterday.
> >>
> >> You can't hide the fact that you are a screen reader user. Anyone with
> any
> >> understanding of screen reader behaviors would be able to detect your
> >> technology almost immediately. Some of them are very straightforward.
> >>
> >> (1) Clicking on a hidden link/anchor/button within a page. While this
> is
> >> listed as an accessibility technique/practice, it's a red flag that you
> are
> >> a screen reader user. No one else would see it in the first place and
> >> there is definitely no one that would be able to click on it.
> >>
> >> (2) Tabbing a lot. One focus jump after another going all over the
> entire
> >> page (let along the entire site) unless it was a form would immediately
> >> give a high probability of the user leveraging a screen reader or some
> >> other accessibility software.
> >>
> >> (3) Tabbing + Click event. This one would be a very strong indicator.
> If
> >> the user was tabbing a lot and then clicked (via the simulated click
> event
> >> that screen readers all use), the probability that the user is
> navigating
> >> via screen reader is very very high. Why else would anyone tab through
> an
> >> entire site only to use a mouse click once they have found what they
> were
> >> looking for?
> >>
> >> (4) I can detect, at this time, whether you are using JAWS, NVDA or
> >> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and
> might
> >> even be able to figure out the version of JAWS with a little bit of
> extra
> >> research. Given the information you have just provided (thank you for
> >> that), I will avoid releasing how I can do this, but suffice to say - it
> >> isn't hard once you really understand the behavioral differences from
> each
> >> other and keyboard/non-screen reader users as a whole.
> >>
> >> We need to revisit this issue. There is just no way you are going to be
> >> able to hide many accessibility technologies from any developer on the
> web.
> >> If someone has nefarious purpose for detection of your screen reader
> >> technology or wants to detect the likeliness that you are a keyboard
> only
> >> user that might have motor skill impairments, for example, you are not
> >> going to be able to stop them.
> >>
> >> Furthermore, you are creating a situation that makes it extraordinarily
> >> difficult to deal with the differences between screen readers. The
> >> compatibility issues that present themselves in rich internet
> applications
> >> already make it so that JAWS, NVDA and VoiceOver are the only possible
> >> means to handle things like focus management because it is that complex
> to
> >> begin with. Add on the fact that they each handle it differently and
> you
> >> are really looking at a major break between the desired avoidance of
> >> detection and reality of making Rich Internet Apps work for these
> programs.
> >> Developers who are doing Rich Internet Apps need to know what you are
> >> using especially when the RIA becomes complex.
> >>
> >> In our current situation at my company, we are required by law to
> provide
> >> accessible solutions for screen reader users, but there is more than one
> >> Rich Internet App in our company that require knowledge of which (JAWS,
> >> NVDA or VoiceOver) screen reader is being used to insure failures
> >> (interaction or formatting) don't occur. There is too much going on in
> >> these apps for the SR software to handle it without some help as well.
> I
> >> could go on for at least an hour or two about how these situations come
> >> about and what we are doing to resolve them but mark my words, there is
> no
> >> question at all that we need to know what we're working with.
> >>
> >> I get why no one wants to be identified. No one wants their information
> >> broadcasted to companies that want to exploit their data. It is
> invasive
> >> and unsetting - I completely understand the objection.
> >>
> >> But it isn't going to allow screen reader technologies (or others for
> that
> >> matter) to maintain the pace of development that we are all witnessing
> even
> >> now. I even remember seeing a post about half a year ago by a Google
> >> employee that was stating how making some technologies accessible at
> this
> >> time was extraordinarily difficult. This is Google we are talking
> about, a
> >> company that hires super-geniuses to write their software - and they're
> >> saying they can't the target. Now granted, I'm sure that there are
> those
> >> among you that see this as an excuse or lack of knowledge on that
> person's
> >> part - but for a massive technology driven company to have an employee
> >> state publicly their doubts in creation of RIA accessibility - that's a
> >> very bad sign. And we aren't doing them or any other design dev teams
> any
> >> favors (or the user base it affects) by hiding the fact that you are a
> >> screen reader user or have some other a11y tech-specific need.
> >>
> >> If this post needs to move to a new discussion (probably not a bad
> idea) I
> >> would like to continue this conversation further with anyone that
> wishes to
> >> state their opinion. I am open to harsh criticism, so fire away, but I
> >> feel very strongly that this perspective is going to hold back
> >> accessible-friendly technology for the web in a critical and unfortunate
> >> way. Don't get me wrong, I care very much about doing the right thing,
> but
> >> as the assessment of a 15 year veteran in design/development, there is
> no
> >> way this is going to work in the long run - and I am not the only person
> >> that would tell you that.
> >>
> >> We need to be open to telling the dev teams what tech we're shooting
> for.
> >> A no-holds-barred approach to keep up with the pace we are seeing. It's
> >> not going to slow down and you can't predict what is coming up next. I
> am
> >> very unsettled and concerned by this issue.
> >>
> >>
> >> Ryan.
> >> > >> > >> > >>
> > > > > > >
> > > >

From: Ryan Hemphill
Date: Wed, Apr 11 2012 9:34AM
Subject: Re: Web Analytics
← Previous message | Next message →

Sure thing.

Our software has a lot of focus management needs. The most important
system, named MindTap, requires the screen reader to be able to jump back
and forth through the equivalent of an online OS. We are essentially
throwing applications onto a textbook with either partial or complete
integration. It gets really hairy.

Point is, we discovered that there were a lot of situations that we were
not going to be able to account for. JAWS doesn't play particularly well
with iframes, and we have a ton of them. Getting rid of them wasn't and
isn't an option for a variety of reasons but let's just say it's off the
table. We have many cases where the interaction gets sophisticated enough
to require an application/focus mode because of either tools being used or
something else. We have situations where the page was missing huge gaps of
content according to the reader even though they could tab through it and
have it read (broken buffer) and other situations where even if you could
read off the button, you couldn't click on it with the SR. I have several
examples of where a single change in the visible content can wreck the
buffer as well.

We need a higher vision to insure that even if the technology is not
particularly a11y-friendly that some remediation can be done without
expecting that we could get to them at the beginning of the process. Add
this on to the fact that we need to account for third party software
development that we have no control over and the important of knowing your
starting point becomes very necessary.

Dojo is a nice tool, no question - but it isn't the one being used here and
even if it was, we couldn't confirm that the other parties were doing the
same thing. jQuery is the leader and all the things that we are using to
make it powerful, such as unit testing and the JMVC all interconnect
tightly with that particular javascript library. I wouldn't even bother
bringing up the notion of Dojo to our team because they are a very jQuery
knowledgeable shop.

They would probably also show me this link about the javascript library
trends, which is a pretty clear argument whether anyone likes it or not...
http://www.google.com/trends/?q=jquery,dojo,mootools,yui,extjs

Well, back to work...

Ryan



On Wed, Apr 11, 2012 at 10:54 AM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:

> Ok, but you stated, "In our current situation at my company, we are
> required by law to provide
> accessible solutions for screen reader users, but there is more than one
> Rich Internet App in our company that require knowledge of which (JAWS,
> NVDA or VoiceOver) screen reader is being used to insure failures
> (interaction or formatting) don't occur. There is too much going on in
> these apps for the SR software to handle it without some help as well."
>
> So, by law you are required to provide access, and you feel the only
> way to adequately
> do so is by doing detection. I'm guessing other individuals are in the
> same boat and could use your methodology? Confused now about what is the
> proper course of action in terms of Rich Internet Applications... I
> recently built a rich internet application with DOJO Toolkit and did not
> run into a situation where I felt I needed to do any detection. Of course,
> if I were catering to JAWS 6 that might be the case, but we had to draw
> some very distinct lines just as we do with visual users (e.g. we don't
> support Mac IE 5). Then again, I'm not in the same situation socially,
> technologically, or legally as you and others, but would love to hear more
> about it to necessitate screen reader detection in RIA. Thanks for keeping
> up this lively convo!!
>
>
> On Wed, Apr 11, 2012 at 5:25 AM, Ryan Hemphill <
> = EMAIL ADDRESS REMOVED =
> > wrote:
>
> > Happy to answer, Stella. The reason I thought I should avoid doing so is
> > for the reason that seemed to be stated by many in this forum. People
> > don't want to be identified via screen reader.
> >
> >
> >
> >
> > On Apr 10, 2012, at 5:55 PM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > Ryan you stated "Given the information you have just provided (thank
> you
> > for
> > > that), I will avoid releasing how I can do this, but suffice to say -
> it
> > > isn't hard once you really understand the behavioral differences from
> > each
> > > other and keyboard/non-screen reader users as a whole."
> > >
> > > If you think it is so important, why would you avoid releasing this
> > > information? I think if your methodology is sound, the community could
> > use
> > > your information, unless you are under some type of NDA. Let us
> know.
> > > Thanks!
> > >
> > > On Tue, Apr 10, 2012 at 8:09 AM, Ryan Hemphill <
> > = EMAIL ADDRESS REMOVED =
> > >> wrote:
> > >
> > >> When I read the reason for not wanted to be identified as using an
> > >> accessibility technology, I gave a big sigh yesterday.
> > >>
> > >> You can't hide the fact that you are a screen reader user. Anyone
> with
> > any
> > >> understanding of screen reader behaviors would be able to detect your
> > >> technology almost immediately. Some of them are very straightforward.
> > >>
> > >> (1) Clicking on a hidden link/anchor/button within a page. While this
> > is
> > >> listed as an accessibility technique/practice, it's a red flag that
> you
> > are
> > >> a screen reader user. No one else would see it in the first place and
> > >> there is definitely no one that would be able to click on it.
> > >>
> > >> (2) Tabbing a lot. One focus jump after another going all over the
> > entire
> > >> page (let along the entire site) unless it was a form would
> immediately
> > >> give a high probability of the user leveraging a screen reader or some
> > >> other accessibility software.
> > >>
> > >> (3) Tabbing + Click event. This one would be a very strong indicator.
> > If
> > >> the user was tabbing a lot and then clicked (via the simulated click
> > event
> > >> that screen readers all use), the probability that the user is
> > navigating
> > >> via screen reader is very very high. Why else would anyone tab
> through
> > an
> > >> entire site only to use a mouse click once they have found what they
> > were
> > >> looking for?
> > >>
> > >> (4) I can detect, at this time, whether you are using JAWS, NVDA or
> > >> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and
> > might
> > >> even be able to figure out the version of JAWS with a little bit of
> > extra
> > >> research. Given the information you have just provided (thank you for
> > >> that), I will avoid releasing how I can do this, but suffice to say -
> it
> > >> isn't hard once you really understand the behavioral differences from
> > each
> > >> other and keyboard/non-screen reader users as a whole.
> > >>
> > >> We need to revisit this issue. There is just no way you are going to
> be
> > >> able to hide many accessibility technologies from any developer on the
> > web.
> > >> If someone has nefarious purpose for detection of your screen reader
> > >> technology or wants to detect the likeliness that you are a keyboard
> > only
> > >> user that might have motor skill impairments, for example, you are not
> > >> going to be able to stop them.
> > >>
> > >> Furthermore, you are creating a situation that makes it
> extraordinarily
> > >> difficult to deal with the differences between screen readers. The
> > >> compatibility issues that present themselves in rich internet
> > applications
> > >> already make it so that JAWS, NVDA and VoiceOver are the only possible
> > >> means to handle things like focus management because it is that
> complex
> > to
> > >> begin with. Add on the fact that they each handle it differently and
> > you
> > >> are really looking at a major break between the desired avoidance of
> > >> detection and reality of making Rich Internet Apps work for these
> > programs.
> > >> Developers who are doing Rich Internet Apps need to know what you are
> > >> using especially when the RIA becomes complex.
> > >>
> > >> In our current situation at my company, we are required by law to
> > provide
> > >> accessible solutions for screen reader users, but there is more than
> one
> > >> Rich Internet App in our company that require knowledge of which
> (JAWS,
> > >> NVDA or VoiceOver) screen reader is being used to insure failures
> > >> (interaction or formatting) don't occur. There is too much going on
> in
> > >> these apps for the SR software to handle it without some help as well.
> > I
> > >> could go on for at least an hour or two about how these situations
> come
> > >> about and what we are doing to resolve them but mark my words, there
> is
> > no
> > >> question at all that we need to know what we're working with.
> > >>
> > >> I get why no one wants to be identified. No one wants their
> information
> > >> broadcasted to companies that want to exploit their data. It is
> > invasive
> > >> and unsetting - I completely understand the objection.
> > >>
> > >> But it isn't going to allow screen reader technologies (or others for
> > that
> > >> matter) to maintain the pace of development that we are all witnessing
> > even
> > >> now. I even remember seeing a post about half a year ago by a Google
> > >> employee that was stating how making some technologies accessible at
> > this
> > >> time was extraordinarily difficult. This is Google we are talking
> > about, a
> > >> company that hires super-geniuses to write their software - and
> they're
> > >> saying they can't the target. Now granted, I'm sure that there are
> > those
> > >> among you that see this as an excuse or lack of knowledge on that
> > person's
> > >> part - but for a massive technology driven company to have an employee
> > >> state publicly their doubts in creation of RIA accessibility - that's
> a
> > >> very bad sign. And we aren't doing them or any other design dev teams
> > any
> > >> favors (or the user base it affects) by hiding the fact that you are a
> > >> screen reader user or have some other a11y tech-specific need.
> > >>
> > >> If this post needs to move to a new discussion (probably not a bad
> > idea) I
> > >> would like to continue this conversation further with anyone that
> > wishes to
> > >> state their opinion. I am open to harsh criticism, so fire away, but
> I
> > >> feel very strongly that this perspective is going to hold back
> > >> accessible-friendly technology for the web in a critical and
> unfortunate
> > >> way. Don't get me wrong, I care very much about doing the right
> thing,
> > but
> > >> as the assessment of a 15 year veteran in design/development, there is
> > no
> > >> way this is going to work in the long run - and I am not the only
> person
> > >> that would tell you that.
> > >>
> > >> We need to be open to telling the dev teams what tech we're shooting
> > for.
> > >> A no-holds-barred approach to keep up with the pace we are seeing.
> It's
> > >> not going to slow down and you can't predict what is coming up next.
> I
> > am
> > >> very unsettled and concerned by this issue.
> > >>
> > >>
> > >> Ryan.
> > >> > > >> > > >> > > >>
> > > > > > > > > > >
> > > > > > > >
> > > >



--



Shipping is a Feature...Perhaps the Most Important Feature.

From: Birkir R. Gunnarsson
Date: Wed, Apr 11 2012 9:42AM
Subject: Re: Web Analytics
← Previous message | Next message →

Ryan

Please make sure to file issues with NVDA through their issue tracker,
as you come across them.
Like you said, there is definitely a very strong need for more
feedback, especially from professionals trying to make their software
accessible.
In my experience, NVDA issue logging is simple, there will be
responses and it will create NVDA community discussion. I think
pushing screen reader innovation and fixing through open source is
probably our best short-term bet.
Thanks for a very informative discussion everyone.
-Birkir


On 4/11/12, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
> Sure thing.
>
> Our software has a lot of focus management needs. The most important
> system, named MindTap, requires the screen reader to be able to jump back
> and forth through the equivalent of an online OS. We are essentially
> throwing applications onto a textbook with either partial or complete
> integration. It gets really hairy.
>
> Point is, we discovered that there were a lot of situations that we were
> not going to be able to account for. JAWS doesn't play particularly well
> with iframes, and we have a ton of them. Getting rid of them wasn't and
> isn't an option for a variety of reasons but let's just say it's off the
> table. We have many cases where the interaction gets sophisticated enough
> to require an application/focus mode because of either tools being used or
> something else. We have situations where the page was missing huge gaps of
> content according to the reader even though they could tab through it and
> have it read (broken buffer) and other situations where even if you could
> read off the button, you couldn't click on it with the SR. I have several
> examples of where a single change in the visible content can wreck the
> buffer as well.
>
> We need a higher vision to insure that even if the technology is not
> particularly a11y-friendly that some remediation can be done without
> expecting that we could get to them at the beginning of the process. Add
> this on to the fact that we need to account for third party software
> development that we have no control over and the important of knowing your
> starting point becomes very necessary.
>
> Dojo is a nice tool, no question - but it isn't the one being used here and
> even if it was, we couldn't confirm that the other parties were doing the
> same thing. jQuery is the leader and all the things that we are using to
> make it powerful, such as unit testing and the JMVC all interconnect
> tightly with that particular javascript library. I wouldn't even bother
> bringing up the notion of Dojo to our team because they are a very jQuery
> knowledgeable shop.
>
> They would probably also show me this link about the javascript library
> trends, which is a pretty clear argument whether anyone likes it or not...
> http://www.google.com/trends/?q=jquery,dojo,mootools,yui,extjs
>
> Well, back to work...
>
> Ryan
>
>
>
> On Wed, Apr 11, 2012 at 10:54 AM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Ok, but you stated, "In our current situation at my company, we are
>> required by law to provide
>> accessible solutions for screen reader users, but there is more than one
>> Rich Internet App in our company that require knowledge of which (JAWS,
>> NVDA or VoiceOver) screen reader is being used to insure failures
>> (interaction or formatting) don't occur. There is too much going on in
>> these apps for the SR software to handle it without some help as well."
>>
>> So, by law you are required to provide access, and you feel the only
>> way to adequately
>> do so is by doing detection. I'm guessing other individuals are in the
>> same boat and could use your methodology? Confused now about what is the
>> proper course of action in terms of Rich Internet Applications... I
>> recently built a rich internet application with DOJO Toolkit and did not
>> run into a situation where I felt I needed to do any detection. Of
>> course,
>> if I were catering to JAWS 6 that might be the case, but we had to draw
>> some very distinct lines just as we do with visual users (e.g. we don't
>> support Mac IE 5). Then again, I'm not in the same situation socially,
>> technologically, or legally as you and others, but would love to hear more
>> about it to necessitate screen reader detection in RIA. Thanks for
>> keeping
>> up this lively convo!!
>>
>>
>> On Wed, Apr 11, 2012 at 5:25 AM, Ryan Hemphill <
>> = EMAIL ADDRESS REMOVED =
>> > wrote:
>>
>> > Happy to answer, Stella. The reason I thought I should avoid doing so
>> > is
>> > for the reason that seemed to be stated by many in this forum. People
>> > don't want to be identified via screen reader.
>> >
>> >
>> >
>> >
>> > On Apr 10, 2012, at 5:55 PM, Stella Mudd < = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> > > Ryan you stated "Given the information you have just provided (thank
>> you
>> > for
>> > > that), I will avoid releasing how I can do this, but suffice to say -
>> it
>> > > isn't hard once you really understand the behavioral differences from
>> > each
>> > > other and keyboard/non-screen reader users as a whole."
>> > >
>> > > If you think it is so important, why would you avoid releasing this
>> > > information? I think if your methodology is sound, the community
>> > > could
>> > use
>> > > your information, unless you are under some type of NDA. Let us
>> know.
>> > > Thanks!
>> > >
>> > > On Tue, Apr 10, 2012 at 8:09 AM, Ryan Hemphill <
>> > = EMAIL ADDRESS REMOVED =
>> > >> wrote:
>> > >
>> > >> When I read the reason for not wanted to be identified as using an
>> > >> accessibility technology, I gave a big sigh yesterday.
>> > >>
>> > >> You can't hide the fact that you are a screen reader user. Anyone
>> with
>> > any
>> > >> understanding of screen reader behaviors would be able to detect your
>> > >> technology almost immediately. Some of them are very
>> > >> straightforward.
>> > >>
>> > >> (1) Clicking on a hidden link/anchor/button within a page. While
>> > >> this
>> > is
>> > >> listed as an accessibility technique/practice, it's a red flag that
>> you
>> > are
>> > >> a screen reader user. No one else would see it in the first place
>> > >> and
>> > >> there is definitely no one that would be able to click on it.
>> > >>
>> > >> (2) Tabbing a lot. One focus jump after another going all over the
>> > entire
>> > >> page (let along the entire site) unless it was a form would
>> immediately
>> > >> give a high probability of the user leveraging a screen reader or
>> > >> some
>> > >> other accessibility software.
>> > >>
>> > >> (3) Tabbing + Click event. This one would be a very strong
>> > >> indicator.
>> > If
>> > >> the user was tabbing a lot and then clicked (via the simulated click
>> > event
>> > >> that screen readers all use), the probability that the user is
>> > navigating
>> > >> via screen reader is very very high. Why else would anyone tab
>> through
>> > an
>> > >> entire site only to use a mouse click once they have found what they
>> > were
>> > >> looking for?
>> > >>
>> > >> (4) I can detect, at this time, whether you are using JAWS, NVDA or
>> > >> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and
>> > might
>> > >> even be able to figure out the version of JAWS with a little bit of
>> > extra
>> > >> research. Given the information you have just provided (thank you for
>> > >> that), I will avoid releasing how I can do this, but suffice to say -
>> it
>> > >> isn't hard once you really understand the behavioral differences from
>> > each
>> > >> other and keyboard/non-screen reader users as a whole.
>> > >>
>> > >> We need to revisit this issue. There is just no way you are going to
>> be
>> > >> able to hide many accessibility technologies from any developer on
>> > >> the
>> > web.
>> > >> If someone has nefarious purpose for detection of your screen reader
>> > >> technology or wants to detect the likeliness that you are a keyboard
>> > only
>> > >> user that might have motor skill impairments, for example, you are
>> > >> not
>> > >> going to be able to stop them.
>> > >>
>> > >> Furthermore, you are creating a situation that makes it
>> extraordinarily
>> > >> difficult to deal with the differences between screen readers. The
>> > >> compatibility issues that present themselves in rich internet
>> > applications
>> > >> already make it so that JAWS, NVDA and VoiceOver are the only
>> > >> possible
>> > >> means to handle things like focus management because it is that
>> complex
>> > to
>> > >> begin with. Add on the fact that they each handle it differently and
>> > you
>> > >> are really looking at a major break between the desired avoidance of
>> > >> detection and reality of making Rich Internet Apps work for these
>> > programs.
>> > >> Developers who are doing Rich Internet Apps need to know what you are
>> > >> using especially when the RIA becomes complex.
>> > >>
>> > >> In our current situation at my company, we are required by law to
>> > provide
>> > >> accessible solutions for screen reader users, but there is more than
>> one
>> > >> Rich Internet App in our company that require knowledge of which
>> (JAWS,
>> > >> NVDA or VoiceOver) screen reader is being used to insure failures
>> > >> (interaction or formatting) don't occur. There is too much going on
>> in
>> > >> these apps for the SR software to handle it without some help as
>> > >> well.
>> > I
>> > >> could go on for at least an hour or two about how these situations
>> come
>> > >> about and what we are doing to resolve them but mark my words, there
>> is
>> > no
>> > >> question at all that we need to know what we're working with.
>> > >>
>> > >> I get why no one wants to be identified. No one wants their
>> information
>> > >> broadcasted to companies that want to exploit their data. It is
>> > invasive
>> > >> and unsetting - I completely understand the objection.
>> > >>
>> > >> But it isn't going to allow screen reader technologies (or others for
>> > that
>> > >> matter) to maintain the pace of development that we are all
>> > >> witnessing
>> > even
>> > >> now. I even remember seeing a post about half a year ago by a Google
>> > >> employee that was stating how making some technologies accessible at
>> > this
>> > >> time was extraordinarily difficult. This is Google we are talking
>> > about, a
>> > >> company that hires super-geniuses to write their software - and
>> they're
>> > >> saying they can't the target. Now granted, I'm sure that there are
>> > those
>> > >> among you that see this as an excuse or lack of knowledge on that
>> > person's
>> > >> part - but for a massive technology driven company to have an
>> > >> employee
>> > >> state publicly their doubts in creation of RIA accessibility - that's
>> a
>> > >> very bad sign. And we aren't doing them or any other design dev
>> > >> teams
>> > any
>> > >> favors (or the user base it affects) by hiding the fact that you are
>> > >> a
>> > >> screen reader user or have some other a11y tech-specific need.
>> > >>
>> > >> If this post needs to move to a new discussion (probably not a bad
>> > idea) I
>> > >> would like to continue this conversation further with anyone that
>> > wishes to
>> > >> state their opinion. I am open to harsh criticism, so fire away, but
>> I
>> > >> feel very strongly that this perspective is going to hold back
>> > >> accessible-friendly technology for the web in a critical and
>> unfortunate
>> > >> way. Don't get me wrong, I care very much about doing the right
>> thing,
>> > but
>> > >> as the assessment of a 15 year veteran in design/development, there
>> > >> is
>> > no
>> > >> way this is going to work in the long run - and I am not the only
>> person
>> > >> that would tell you that.
>> > >>
>> > >> We need to be open to telling the dev teams what tech we're shooting
>> > for.
>> > >> A no-holds-barred approach to keep up with the pace we are seeing.
>> It's
>> > >> not going to slow down and you can't predict what is coming up next.
>> I
>> > am
>> > >> very unsettled and concerned by this issue.
>> > >>
>> > >>
>> > >> Ryan.
>> > >> >> > >> >> > >> >> > >>
>> > > >> > > >> > > >> >
>> > >> > >> > >> >
>> >> >> >>
>
>
>
> --
>
>
>
> Shipping is a Feature...Perhaps the Most Important Feature.
> > > >

From: Ryan Hemphill
Date: Wed, Apr 11 2012 10:11AM
Subject: Re: Web Analytics
← Previous message | No next message

I'll look into it, Birkir - I second the discussion thanks as well. It's
good to hear voices on this subject. It's why I joined the discussion
board in the first place.

Ryan

On Wed, Apr 11, 2012 at 11:42 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Ryan
>
> Please make sure to file issues with NVDA through their issue tracker,
> as you come across them.
> Like you said, there is definitely a very strong need for more
> feedback, especially from professionals trying to make their software
> accessible.
> In my experience, NVDA issue logging is simple, there will be
> responses and it will create NVDA community discussion. I think
> pushing screen reader innovation and fixing through open source is
> probably our best short-term bet.
> Thanks for a very informative discussion everyone.
> -Birkir
>
>
> On 4/11/12, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
> > Sure thing.
> >
> > Our software has a lot of focus management needs. The most important
> > system, named MindTap, requires the screen reader to be able to jump back
> > and forth through the equivalent of an online OS. We are essentially
> > throwing applications onto a textbook with either partial or complete
> > integration. It gets really hairy.
> >
> > Point is, we discovered that there were a lot of situations that we were
> > not going to be able to account for. JAWS doesn't play particularly well
> > with iframes, and we have a ton of them. Getting rid of them wasn't and
> > isn't an option for a variety of reasons but let's just say it's off the
> > table. We have many cases where the interaction gets sophisticated
> enough
> > to require an application/focus mode because of either tools being used
> or
> > something else. We have situations where the page was missing huge gaps
> of
> > content according to the reader even though they could tab through it and
> > have it read (broken buffer) and other situations where even if you could
> > read off the button, you couldn't click on it with the SR. I have
> several
> > examples of where a single change in the visible content can wreck the
> > buffer as well.
> >
> > We need a higher vision to insure that even if the technology is not
> > particularly a11y-friendly that some remediation can be done without
> > expecting that we could get to them at the beginning of the process. Add
> > this on to the fact that we need to account for third party software
> > development that we have no control over and the important of knowing
> your
> > starting point becomes very necessary.
> >
> > Dojo is a nice tool, no question - but it isn't the one being used here
> and
> > even if it was, we couldn't confirm that the other parties were doing the
> > same thing. jQuery is the leader and all the things that we are using to
> > make it powerful, such as unit testing and the JMVC all interconnect
> > tightly with that particular javascript library. I wouldn't even bother
> > bringing up the notion of Dojo to our team because they are a very jQuery
> > knowledgeable shop.
> >
> > They would probably also show me this link about the javascript library
> > trends, which is a pretty clear argument whether anyone likes it or
> not...
> > http://www.google.com/trends/?q=jquery,dojo,mootools,yui,extjs
> >
> > Well, back to work...
> >
> > Ryan
> >
> >
> >
> > On Wed, Apr 11, 2012 at 10:54 AM, Stella Mudd < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> Ok, but you stated, "In our current situation at my company, we are
> >> required by law to provide
> >> accessible solutions for screen reader users, but there is more than one
> >> Rich Internet App in our company that require knowledge of which (JAWS,
> >> NVDA or VoiceOver) screen reader is being used to insure failures
> >> (interaction or formatting) don't occur. There is too much going on in
> >> these apps for the SR software to handle it without some help as well."
> >>
> >> So, by law you are required to provide access, and you feel the only
> >> way to adequately
> >> do so is by doing detection. I'm guessing other individuals are in the
> >> same boat and could use your methodology? Confused now about what is
> the
> >> proper course of action in terms of Rich Internet Applications... I
> >> recently built a rich internet application with DOJO Toolkit and did not
> >> run into a situation where I felt I needed to do any detection. Of
> >> course,
> >> if I were catering to JAWS 6 that might be the case, but we had to draw
> >> some very distinct lines just as we do with visual users (e.g. we don't
> >> support Mac IE 5). Then again, I'm not in the same situation socially,
> >> technologically, or legally as you and others, but would love to hear
> more
> >> about it to necessitate screen reader detection in RIA. Thanks for
> >> keeping
> >> up this lively convo!!
> >>
> >>
> >> On Wed, Apr 11, 2012 at 5:25 AM, Ryan Hemphill <
> >> = EMAIL ADDRESS REMOVED =
> >> > wrote:
> >>
> >> > Happy to answer, Stella. The reason I thought I should avoid doing so
> >> > is
> >> > for the reason that seemed to be stated by many in this forum. People
> >> > don't want to be identified via screen reader.
> >> >
> >> >
> >> >
> >> >
> >> > On Apr 10, 2012, at 5:55 PM, Stella Mudd < = EMAIL ADDRESS REMOVED = >
> wrote:
> >> >
> >> > > Ryan you stated "Given the information you have just provided (thank
> >> you
> >> > for
> >> > > that), I will avoid releasing how I can do this, but suffice to say
> -
> >> it
> >> > > isn't hard once you really understand the behavioral differences
> from
> >> > each
> >> > > other and keyboard/non-screen reader users as a whole."
> >> > >
> >> > > If you think it is so important, why would you avoid releasing this
> >> > > information? I think if your methodology is sound, the community
> >> > > could
> >> > use
> >> > > your information, unless you are under some type of NDA. Let us
> >> know.
> >> > > Thanks!
> >> > >
> >> > > On Tue, Apr 10, 2012 at 8:09 AM, Ryan Hemphill <
> >> > = EMAIL ADDRESS REMOVED =
> >> > >> wrote:
> >> > >
> >> > >> When I read the reason for not wanted to be identified as using an
> >> > >> accessibility technology, I gave a big sigh yesterday.
> >> > >>
> >> > >> You can't hide the fact that you are a screen reader user. Anyone
> >> with
> >> > any
> >> > >> understanding of screen reader behaviors would be able to detect
> your
> >> > >> technology almost immediately. Some of them are very
> >> > >> straightforward.
> >> > >>
> >> > >> (1) Clicking on a hidden link/anchor/button within a page. While
> >> > >> this
> >> > is
> >> > >> listed as an accessibility technique/practice, it's a red flag that
> >> you
> >> > are
> >> > >> a screen reader user. No one else would see it in the first place
> >> > >> and
> >> > >> there is definitely no one that would be able to click on it.
> >> > >>
> >> > >> (2) Tabbing a lot. One focus jump after another going all over the
> >> > entire
> >> > >> page (let along the entire site) unless it was a form would
> >> immediately
> >> > >> give a high probability of the user leveraging a screen reader or
> >> > >> some
> >> > >> other accessibility software.
> >> > >>
> >> > >> (3) Tabbing + Click event. This one would be a very strong
> >> > >> indicator.
> >> > If
> >> > >> the user was tabbing a lot and then clicked (via the simulated
> click
> >> > event
> >> > >> that screen readers all use), the probability that the user is
> >> > navigating
> >> > >> via screen reader is very very high. Why else would anyone tab
> >> through
> >> > an
> >> > >> entire site only to use a mouse click once they have found what
> they
> >> > were
> >> > >> looking for?
> >> > >>
> >> > >> (4) I can detect, at this time, whether you are using JAWS, NVDA or
> >> > >> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and
> >> > might
> >> > >> even be able to figure out the version of JAWS with a little bit of
> >> > extra
> >> > >> research. Given the information you have just provided (thank you
> for
> >> > >> that), I will avoid releasing how I can do this, but suffice to
> say -
> >> it
> >> > >> isn't hard once you really understand the behavioral differences
> from
> >> > each
> >> > >> other and keyboard/non-screen reader users as a whole.
> >> > >>
> >> > >> We need to revisit this issue. There is just no way you are going
> to
> >> be
> >> > >> able to hide many accessibility technologies from any developer on
> >> > >> the
> >> > web.
> >> > >> If someone has nefarious purpose for detection of your screen
> reader
> >> > >> technology or wants to detect the likeliness that you are a
> keyboard
> >> > only
> >> > >> user that might have motor skill impairments, for example, you are
> >> > >> not
> >> > >> going to be able to stop them.
> >> > >>
> >> > >> Furthermore, you are creating a situation that makes it
> >> extraordinarily
> >> > >> difficult to deal with the differences between screen readers. The
> >> > >> compatibility issues that present themselves in rich internet
> >> > applications
> >> > >> already make it so that JAWS, NVDA and VoiceOver are the only
> >> > >> possible
> >> > >> means to handle things like focus management because it is that
> >> complex
> >> > to
> >> > >> begin with. Add on the fact that they each handle it differently
> and
> >> > you
> >> > >> are really looking at a major break between the desired avoidance
> of
> >> > >> detection and reality of making Rich Internet Apps work for these
> >> > programs.
> >> > >> Developers who are doing Rich Internet Apps need to know what you
> are
> >> > >> using especially when the RIA becomes complex.
> >> > >>
> >> > >> In our current situation at my company, we are required by law to
> >> > provide
> >> > >> accessible solutions for screen reader users, but there is more
> than
> >> one
> >> > >> Rich Internet App in our company that require knowledge of which
> >> (JAWS,
> >> > >> NVDA or VoiceOver) screen reader is being used to insure failures
> >> > >> (interaction or formatting) don't occur. There is too much going
> on
> >> in
> >> > >> these apps for the SR software to handle it without some help as
> >> > >> well.
> >> > I
> >> > >> could go on for at least an hour or two about how these situations
> >> come
> >> > >> about and what we are doing to resolve them but mark my words,
> there
> >> is
> >> > no
> >> > >> question at all that we need to know what we're working with.
> >> > >>
> >> > >> I get why no one wants to be identified. No one wants their
> >> information
> >> > >> broadcasted to companies that want to exploit their data. It is
> >> > invasive
> >> > >> and unsetting - I completely understand the objection.
> >> > >>
> >> > >> But it isn't going to allow screen reader technologies (or others
> for
> >> > that
> >> > >> matter) to maintain the pace of development that we are all
> >> > >> witnessing
> >> > even
> >> > >> now. I even remember seeing a post about half a year ago by a
> Google
> >> > >> employee that was stating how making some technologies accessible
> at
> >> > this
> >> > >> time was extraordinarily difficult. This is Google we are talking
> >> > about, a
> >> > >> company that hires super-geniuses to write their software - and
> >> they're
> >> > >> saying they can't the target. Now granted, I'm sure that there are
> >> > those
> >> > >> among you that see this as an excuse or lack of knowledge on that
> >> > person's
> >> > >> part - but for a massive technology driven company to have an
> >> > >> employee
> >> > >> state publicly their doubts in creation of RIA accessibility -
> that's
> >> a
> >> > >> very bad sign. And we aren't doing them or any other design dev
> >> > >> teams
> >> > any
> >> > >> favors (or the user base it affects) by hiding the fact that you
> are
> >> > >> a
> >> > >> screen reader user or have some other a11y tech-specific need.
> >> > >>
> >> > >> If this post needs to move to a new discussion (probably not a bad
> >> > idea) I
> >> > >> would like to continue this conversation further with anyone that
> >> > wishes to
> >> > >> state their opinion. I am open to harsh criticism, so fire away,
> but
> >> I
> >> > >> feel very strongly that this perspective is going to hold back
> >> > >> accessible-friendly technology for the web in a critical and
> >> unfortunate
> >> > >> way. Don't get me wrong, I care very much about doing the right
> >> thing,
> >> > but
> >> > >> as the assessment of a 15 year veteran in design/development, there
> >> > >> is
> >> > no
> >> > >> way this is going to work in the long run - and I am not the only
> >> person
> >> > >> that would tell you that.
> >> > >>
> >> > >> We need to be open to telling the dev teams what tech we're
> shooting
> >> > for.
> >> > >> A no-holds-barred approach to keep up with the pace we are seeing.
> >> It's
> >> > >> not going to slow down and you can't predict what is coming up
> next.
> >> I
> >> > am
> >> > >> very unsettled and concerned by this issue.
> >> > >>
> >> > >>
> >> > >> Ryan.
> >> > >> > >> > >> > >> > >> > >> > >>
> >> > > > >> > > > >> > > > >> >
> >> > > >> > > >> > > >> >
> >> > >> > >> > >>
> >
> >
> >
> > --
> >
> >
> >
> > Shipping is a Feature...Perhaps the Most Important Feature.
> > > > > > > >
> > > >



--



Shipping is a Feature...Perhaps the Most Important Feature.