WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

From: Birkir R. Gunnarsson
Date: Apr 11, 2012 9:42AM

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