W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2012

Re: is javascript considered good wacg 2.0 practice?

From: Michael Gower <michael.gower@ca.ibm.com>
Date: Fri, 14 Dec 2012 11:46:06 -0800
To: Karen Lewellen <klewellen@shellworld.net>
Cc: David Hilbert Poehlman <poehlman1@comcast.net>, W3C WAI ig <w3c-wai-ig@w3.org>
Message-ID: <OFEBE6DFB1.E1AE5986-ON88257AD4.006AB1A1-88257AD4.006C980F@ca.ibm.com>
I'm hard-pressed to think of many current sites I've encountered that do 
not utilize javascript. Javascript is the enabler on many sites for much 
of the functionality of wcag 2.0 guidelines.
As far as I know, a requirement to turn off javascript is a throwback to 
WCAG 1.0 which is no longer valid. WCAG 2.0 states that any technology can 
be used to deliver accessibility if it does so according to the standard.
In my work, we are constantly using javascript to remediate inaccessible 
third-party applications. Without the javascript, the apps would be 
completely inaccessible. And of course many sites now would be unusable by 
anyone without the javascript running.

The issue of backwards compatibility is related to this discussion, but 
separate. There needs to be a balance between supporting folks using older 
technologies and adopting new, better standards. But at some point, 
websites will draw a line. Try opening gmail with IE 7 and you'll get a 
message saying to upgrade your browser. That's not an accessibility issue, 
in my mind.
Likewise, if a user chooses not to use ATs or browsers that support 
WAI-ARIA, they aren't in a good position to complain that they aren't 
getting as rich an experience as users who do in regard to error handling 
and notification, etc.

Michael Gower
i b m  i n t e r a c t i v e

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   Karen Lewellen <klewellen@shellworld.net>
To:     David Hilbert Poehlman <poehlman1@comcast.net>
Cc:     W3C WAI ig <w3c-wai-ig@w3.org>
Date:   12/14/2012 10:49 AM
Subject:        Re: is javascript considered good wacg 2.0 practice?



just so.
Honestly and I mean this sincerely.  I think of Java Scripting as window 
dressing. if it is possible for it to be turned off then that possibility 
exists because people will want to turn it off.  Therefore your site 
should 
do basic things without it, end of discussion.
I am reminded of a carol Burnett parity commercial.  A woman goes into a 
McDonald's like restaurant  and says I  want a hamburger and I  have not 
eaten in three days.
the person behind the counter says sure...but first!
and the entire staff starts singing the restaurant theme song, with 
flashing lights and dancing  and confetti and fireworks...while this lady 
just wants to 
eat.
She faints before the production number repeated twice is over.
If all i want is to get a sandwich  on line, why must I go through mayhem 
i. e. Java script to do it?
Kare

On Fri, 14 Dec 2012, David Hilbert Poehlman wrote:

> I see why there's been so much discussion on this thread and did not 
read all of it but did read the below so please forgive if I'm repeating 
something.
>
> I remember the day when we had some simple tests for accessibility of a 
site and they were not necessarily aimed at screen reader users.  One of 
those tests was: "can I use the site with Javascript turned off? I also 
had and still have a sneaking feeling that just having js available is 
different than not having it available, (turned off or not), but yes, in 
order to provide equal access to a public interface it must be available 
in as many ways as is possible for a variety of reasons, not the least of 
which is so not to have to say: "sorry, you can't enter here" to anyone. 
Yes, dial in interactive web, browse aloud, non js, non css, non text even 
are paradigms of accessibility.
>
> Oh, don't get me wrong, I love all the future thinking, I love all the 
some day we'll be able to cross this or that bridge and I heavily applaud 
those who are turning this into reality.  At the same time, we live in the 
here and now and today, there are still millions of people for whom the 
reach is too high through no fault of their own.  If free means the cost 
of a computer or a steep learning curve, than we are sadly mistaken in our 
definition of it.
>
> Find me on twitter:
> @davidpoehlman1
>
> On Dec 13, 2012, at 10:32 PM, John Foliot <john@foliot.ca> wrote:
>
> 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
>
>
>
>
> -- 
> Jonnie Appleseed
> With His
> Hands-on technolog(eye)s
> Touching the internet
> Reducingtechnology's' Disabilities
> one byte at a time
>
>
>
Received on Friday, 14 December 2012 19:46:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 December 2012 19:46:46 GMT