WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

From: Ryan Hemphill
Date: Apr 10, 2012 12:04PM

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