WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

From: Birkir R. Gunnarsson
Date: Apr 10, 2012 2:57PM

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