Re: is javascript considered good wacg 2.0 practice?

I believe this takes too narrow a view of what javascript does. it's not just for things like animations and special effects. it also does things like checking that required fields have been filled in in a form, checking that values that are provided are valid, and sometimes performing the services that are the point of a site, like calculating an answer.

On Dec 14, 2012, at 11:45 AM, Karen Lewellen wrote:

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

Clayton Lewis
Professor of Computer Science
University of Colorado
http://www.cs.colorado.edu/~clayton