WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

From: Will Grignon
Date: Apr 10, 2012 3:24PM

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.





-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R.
Gunnarsson
Sent: Tuesday, April 10, 2012 4:57 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Web Analytics

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 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 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
>>
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED> [mailto:
>> <EMAIL REMOVED> ] On Behalf Of Tim Harshbarger
>> Sent: Tuesday, April 10, 2012 10:38 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Web Analytics
>>
>> 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?
>>
>>
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED> [mailto:
>> <EMAIL REMOVED> ] On Behalf Of Ryan Hemphill
>> Sent: Tuesday, April 10, 2012 10:10 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Web Analytics
>>
>> 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.
>> >> >> list messages to <EMAIL REMOVED>
>> >> >> list messages to <EMAIL REMOVED>
>>
>>
>> >> >> list messages to <EMAIL REMOVED>
>>
>
>
>
> --
>
>
>
> Shipping is a Feature...Perhaps the Most Important Feature.
> > > list messages to <EMAIL REMOVED>
>
messages to <EMAIL REMOVED>