WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

From: Ryan Hemphill
Date: Apr 11, 2012 10:11AM

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