RE: is javascript considered good wacg 2.0 practice?

This has been an interesting discussion. A number of key (if not critical)
points have surfaced, and I'd like to take a stab at a bunch of them:

Karen Lewellen wrote:
>
> lol! browser agnostic?  Forgive me, but that expression
> made me laugh...get that browser to a church on time!
> Seriously, can you expand a bit here  please?  What I
> suspect is that the success criteria, say for wacg 2.0
> Level AA is not rooted in the browsers themselves...even
> though Bell is claiming it is.  as in if  our site works 
> with Chrome and Firefox it is fully wacg 2.0 compliant,
> end of story.

First, is this what Bell Canada is really saying? I for one would be
extremely surprised if Bell wasn't also testing their web properties in
Internet Explorer, given its continued significant market share. 

The "agnostic" expression is one that has a fair bit of misunderstanding
about it, but essentially it suggests that content authors should not be
creating content targeted to *any particular browser*, but rather towards
the (W3C) Standards, at which point [emphasis] it is up to the browsers to
meet those Standards.[/emphasis] 

Not all browsers meet all of the Standards today, for example, (and not to
pick on my Norwegian friends,) Opera, a pretty decent browser over-all, has
lousy support with regard to interaction with the Accessibility APIs of the
various operating system (i.e. none). This is not to say that sighted
Canadians cannot use Opera to access the Bell Canada site (they can if they
choose), but for non-sighted users, it is a non-starter. Is that Bell's
fault, or Opera's fault?  

If Bell's web authoring team follow the W3C Standards (including WCAG 2),
then they have (in my opinion) fulfilled their part of the Social Contract:
They have "paved the road" to industry standards, but they aren't telling
you which car you must drive on that road - feel free to drive a Lamborghini
or an Edsel. Which car you choose to drive however will impact on your
driving experience, but it is *you* that chooses the car, not them. Thus the
"agnostic" sentiment. 


> They write that they know that for 
> some people using jaws, javascript can lock the screen reader
> in a loop, but that the use of javascript is compliant according
> to wacg 2.0...which does not make sense here.  if Javascript is
> not easily usable than it should not be used, unless I am over
> simplifying. At the very least, there should be a css that gives
> users a choice?

Addressing that statement in backwards order: CSS is for design, JavaScript
is for scripting - they rarely have anything to do with each other. I'm not
sure that this will address your concerns.

To the larger question, there are a few glaring holes in your blanket
statement that may be part of the complexity of the problem here.
Specifically, which version(s) of JAWs are they talking about? In which
browser(s)? Is it constrained to certain versions of any given browser?  For
contrast, are they talking about Internet Explorer 9 with JAWs 13, or is it
only when you use Internet Explorer 6 with JAWS 10? Or is it only in some
specific combinations, and not others? (Does version of operating system
factor into this as well? Does the problem manifest only with Windows XP? Or
perhaps only on Windows Vista?)

The multitude of combinations of operating system, browser, and assistive
technology choices (both in terms of "brand" as well as versions of each
brand) often means that real user testing across all possible combinations
becomes cost prohibitive to the point of near impossible, which once again
suggests that being "agnostic" in terms of those combinations, in favor of
using w3C Standards, is often the only real choice large organizations have.


If Bell is using JavaScript that follows the EMCAScript Standard, if that
JavaScript includes the appropriate use of ARIA (an 'almost' W3C Standard in
that it is in the final stages of the formal process on the W3C
Recommendation path, and widely and well supported in multiple browsers and
screen readers today), and the use of JavaScript does not contravene any
WCAG 2 guidelines, then yes, it does make sense, even if it doesn't work on
every single device, with every single software package available to the
global community.


> what happened to the easy days of lynx, elinks, and links?  

Returning to my car analogy of earlier, we can all generally understand what
a modern car looks and operates like, and modern roads are built to
accommodate modern cars. We must stop short however of insisting that all
cars can be driven on all roads regardless of the age of the car, make of
the car, and condition of the car: you cannot take a Model-T out on the
freeway and then complain that everyone else is driving too fast to be safe
for your driving comfort. There is an implied responsibility that if you
wish to continue to function in the modern society, that you take steps to
also remain modern; again, what I personally refer to as the Social
Contract. 

Taking the transportation analogy even further, there are certain
communities in North America (Amish, Menonite, etc.) who don't drive cars -
period. Do they none-the-less have a "right" to take their horse and
carriages on Multi-lane Freeways? Do stores and municipalities have a Legal
Responsibility to provide hose-hitches on the main streets of their towns,
so that those members who don't drive cars can hitch their carriages? I
don't know, but I don't think so: these communities have taken a conscious
decision to not "keep up with technology", and as such they also forgo some
of their expectations of "accommodation" - nobody but themselves are forcing
them to not use modern transportation.

Equally, nobody is forcing you to go to the Bell Web site - you yourself
noted that Bell also provided other service outlets to accommodate their
users, and so their website is but one way of interacting with their
business. Yes, it might also be the most convenient, but it does not appear
to be the only way of doing so. If Bell is using current industry standards
on their web site then they have come their distance: are you using current,
standards-compliant tools, or is part of your lack of access the fact that
the tools you are using are now out of date? 

That might seem like a tough and even unfair question, and I do appreciate
that everyone's unique experience is just that, unique, but it also is one
that needs to be asked. Expecting a browser that was last updated in the
late 90's to be capable of interacting with the technology of 2012 is
unreasonable - it's your Model-T on the freeway: sure, you might be able to
drive 'ol Bessie on Highway 401, but it ain't gonna be easy, and in some
places nigh-on impossible. It was also *your* choice.


David Woolley wrote:
>
> There is no indication that this is a closed system.  Being able to 
> declare a technology baseline sounds like a good way to avoid the 
> nuisance of WCAG, if it applies to the general internet.

The modern web is more than just the push of text documents that was the web
of the 90's - today the web delivers to billions of humans a sophisticated
interactive platform that saves time, money and effort for countless number
of users. 

It is not unreasonable to state up front that to interact with that
interactive platform a certain level of technology support is required at
the user end: whether it be for accessibility considerations or simply any
one user's consideration. As Steve Faulkner pointed out, any user who
approaches a site that requires JavaScript, who does not use a tool that
supports JavaScript, will be blocked from using that site. 

Stating a minimum toolset requirement is not unreasonable, and is not
"anti-accessible"; on the contrary I think that it is unreasonable to not
set minimum requirements for users up front, and to expect that any old tool
will be a wonder tool. We are dealing with technology here, and it continues
to become increasingly complex every day, both to our betterment as well as
a certain sense of frustration. Suggesting that setting expectations is
discriminatory, or a means to avoid WCAG however is folly.


Harry Loots wrote:
>
> If however, this is a public website, where everyone has the right
> of access and can expect to be treated equally, then if a user uses
> a browser or AT that does not support JavaScript, and is thereby denied
> access to the functionality offered via the scripting, then the site is
> not accessible. Ergo, the site is non-compliant.

I respect your right to an opinion here, but I also respectfully disagree,
and I think you would have a very hard time defending that opinion in a
court of law (which sort of feels what this whole thread is leading
towards). 

Nobody is forcing you to go to that site, and nobody is forcing you to use
tools that are not up to the task. If you voluntarily choose to use tools
that cannot perform a specific function, then it is you, not the owner of
the function, who has made a choice that has a directly negative impact on
the outcome.

I am well aware of the "cost" argument, but that has little traction today.
I know of at least one user personally who has a copy of Firefox installed
on their Linux system for when Lynx does not meet their needs, and the cost
of them having that second browser is the same as not having it: nothing. We
have "free" operating systems that support "free" screen reading
technologies (and other Assistive devices), and we have free, Standards
compliant, JavaScript supporting browsers that work on those free systems.
Citing the "cost" argument today is a non-starter, and again (I suspect)
would be dismissed in a court of law should it ever come to that.

I am also aware of certain circumstances where, for security or other
reasons, JavaScript is blocked. But unless accessing specific sites that
require JavaScript support (such as the Bell Canada site) is part of your
actual job requirement, one could easily ask why you are going to a non-work
related site during working hours on the company machine... again, for any
reason why a user is blocked from a JS supporting tool, there are usually
counter-arguments that deflate those points.

Again, that might seem unfair to some, but it is also a reality.


Ramón Corominas wrote:
>
> That said, I agree that we must be realistic, too. We cannot pretend 
> that developers test every combination of OS, browser and AT, but there 
> should also be a limit to the "it's your fault by not using the 
> appropriate tool" excuse.

There is a middle ground here. If there are multiple tools and tool-chains
that users can use to perform any given task, then yes, we can in fact make
that assertion. 

Expecting anything and everything to always work irrespective of an
individual's *preferred* tool-chain is unacceptable; equally, insisting that
a 'specific' set of tools or tool-sets must be used is also unacceptable. I
do not see or hear anything in this conversation that comes anywhere near
that kind of statement. Instead what I am reading is that a certain
tool-chain combination is not performing a specific task (or series of
tasks). The end user can, however, use other (free) tools to perform the
task, and further (here I am presuming) that task or series of tasks have
been constructed to current industry Standards. 

The key to your statement is being realistic, and I fear (and hear) some
unrealistic assertions and expectations emerging on this thread. That makes
me sad, as it can have some serious negative backlash on the progress we
have made towards a more accessible web. Is web accessibility where I wish
it were today? No, but it is a far site better than it was when I started in
this field over a decade ago. Today I have numerous blind colleagues and
friends who can access web content on their iPhones, with nothing but a
glass-panel touch interface and VoiceOver for interaction; and they not only
can access the web, they can interact with it - on their cell phones! (Q:
Should they now also be able to access the web on their rotary dial phones,
because equal access is equal access? Of course not! Technology marches on.)


Harry Loots wrote:
>
> I'm not sure that ARIA was ever intended to be the future of
accessibility.
> I have always understood it to be bridging technology. Rue the day when
> ARIA becomes the standard, rather than the browser or user agent's
> accessibility APIs.

I've had the opportunity to think about this one, and to discuss this one,
with a large number of people both inside and outside of the W3C, and ARIA
today will continue to be a key piece of the larger accessibility puzzle. 

ARIA is part of HTML5, ARIA is/will be part of SVG, and in fact ARIA is and
will be a big part of any current and future mark-up languages that emerge
at the W3C, because of what ARIA does. Harry, you are correct in that it is
a bridge, but it is and will be a stable and permanent bridge (or bridging
technology) because what ARIA does is bridge the gap between the mark-up
language, the user-agents and the Accessibility APIs. While there is huge
value in mapping current (and future) native markup elements to the Roles
States and Properties that ARIA currently map to, if and when those native
elements don't exist, ARIA will remain in our toolkit. 

Also, the browsers and user-agents generally don't have Accessibility APIs,
it's the underlying operating system that provides those AAPIs, so ARIA is
"the glue" that binds it all together.

I don't rue the emergence of ARIA as a permanent part of the developer
tool-chain, I embrace it. As education and adoption of ARIA increases (and
it *WILL* increase), we can teach the concepts, and the aria-[attributes]
once, and then developers will be able to use them with *all* markup
languages. That is a huge and powerful win, and will go a long way over time
in increasing the accessibility of all markup technologies. As a matter of
fact, work is underway now on both ARIA 1.1 (an errata spec) as well as
thinking towards ARIA 2, and so I feel relatively comfortable in stating
that the W3C shares my perspective (or rather, I share theirs). I also smile
today, as more and more developers come to realize that done right, aria
attributes can also be used for CSS selectors, making their code lighter,
more accessible, and still easy to style
(http://blog.w3conversions.com/2010/05/aria-role-attributes-as-selectors/).
Talk about a win!

Anyway, this has been a long email. I hope I've provided some food for
thought, and happy to continue in this thread if others so desire.

Cheers!

JF

Received on Friday, 14 December 2012 03:33:22 UTC