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

(unknown charset) Re: is javascript considered good wacg 2.0 practice?

From: (unknown charset) Karen Lewellen <klewellen@shellworld.net>
Date: Fri, 14 Dec 2012 15:33:10 -0500 (EST)
To: (unknown charset) Michael Gower <michael.gower@ca.ibm.com>
cc: (unknown charset) David Hilbert Poehlman <poehlman1@comcast.net>, W3C WAI ig <w3c-wai-ig@w3.org>
Message-ID: <Pine.BSF.4.64.1212141523290.6298@server1.shellworld.net>
well, lets use this example.
every day several times a day I visit.
mail.google.com
using the latest edition of Lynx the cat something like September this 
year.

i write mail there do searches there  and for the most part activate 
the links there in mail.
If I meet with a site from a mail that does not work
I try again using links the chain, or e-links.  which appears closer to 
what folks find with Ie I suspect.
my user experience gets more cluttered and less fun the closer I get to 
something more graphical.
Yet I can do my job easily and effortlessly because google keeps something 
close to HTML in place.
What is wrong with my definition of ahem Modern?
it gets  the job done I have practically no risk of bugs, and for at least 
95% of my effort at google, if not, more, its effortless with two Java 
script friendly but also text friendly options.
How can you, not living my experience, decide my technology is backward? 
smiles.
Or how can you decide anyone is using something backward if it works for 
them?

Karen

On Fri, 14 Dec 2012, Michael Gower wrote:

> 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 20:33:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 December 2012 20:33:40 GMT