Does compliance to WCAG 2.0 AA prevent the use of JavaScript?
My understanding based on Understanding Conformance is that we can still use JavaScript as long as we don't generate any content that is noncompliant and that we explicitly state we support JavaScript. Is that correct?
The short answer is, no, it doesn't. Your understanding is pretty much correct.
Indeed, you can use JavaScript as long as we you abide by WCAG 2.0 success criteria :-)
There is a rationale why you may have heard JavaScript is banished from accessible content. In the old days of WCAG 1.0, it practically censured the use of any content generated by JavaScript. You needed to check that your web application still worked with JavaScript disabled, which practically restricted JavaScript to decorative purposes. Otherwise, you ought to provide an alternate, non-JavaScript reliant, version, which usually involved a lot of server-side magic (try and see Google Maps without JS to understand what I mean).
This was because in those old days assistive technologies and even some mainstream browsers (e.g. mobile) did not support JavaScript, or browsers did not expose script-generated contents.
This is not the case anymore. You can use JavaScript in accessible, WCAG 2.0, websites, but:
Get acquainted with WCAG 2.0 criteria and make sure you are not failing any of them. It is not a matter of using one or another technology, but a matter of using them correctly.
In particular, check you abide by the client-side scripting techniques for WCAG 2.0 which deal with recommended and disapproved scripting usages.
Use ARIA Techniques for WCAG 2.0 to define the semantics of non-standard controls, they are widely supported by major browsers.
A slightly longer answer is that pages can require JavaScript (AKA ECMAScript), but it's better if they don't. Use JavaScript sparingly and carefully. There's a set of guidelines for using JavaScript on WCAG 2.0 compliant pages.
You can use JavaScript. It is not a problem so long as all semantics are provided (name, state, and role) and you manage the focus accessible. Use ARIA when you need to provide semantics or manage focus.
Related
I am considering implementing the Secure Remote Password protocol to conduct a zero-knowledge password proof between the browser and my web application. The SRP website provides an example, but it requires java to perform calculations. I am wondering whether it is possible to implement SRP using javascript without the use of Java, as I do not want to require my users to have Java installed, particularly as my audience will be a security conscious one which would potentially consider the risk of having the java plugin enabled a greater risk to their security than a zero-knowledge password proof.
Here is the link to their demo: http://srp.stanford.edu/demo/
I am wondering whether it is possible to implement SRP using javascript without the use of Java,
If you are looking for a standardized method, the answer in NO.
The WebCrypto Working Group is standardizing things now for some crypto operations. However, the WG has already stated they will not provide access to the underlying BigInt primitives needed for the modular operations, so you won't have the primitives you need in the first release. You may get it in a subsequent release. See Question on BigInteger operations from their mailing list.
Update: the WebCrypto Working Group is not going to provide Diffie-Hellman as part of the standard, either. And the Chrome team is not even going to provide Diffie-Hellman as an extension. They claim there are no use cases or demand for Diffie-Hellman, either. See Diffie-Hellman in WebCrypto from their mailing list.
You might be able to find it in a Javascript library, but I would expect it to be slow (or slower than a native implementation).
Related, keep in mind that the same folks who are denying you BigInts and Diffie-Hellman are the same folks who decreed "interception is a valid use case" in the browser security model.
And they are the same folks who broke RFC 7469 Public Key Pinning Extension for HTTP. For a detailed commentary, see Comments on draft-ietf-websec-key-pinning. Worse, when they were called-out for providing the overrides and breaking the secure channel, they changed the language in Draft 21 to Final to make it even more obscure and hidden away.
I use an SRP client in KeeFox. It's a Firefox add-on so has fewer issues with backwards compatibility, cross-browser support, etc. I imagine a slightly modified version would work in most modern browsers though.
It is slow but still fast enough for the occasional use it gets (maximum of once per Firefox session).
I took inspiration from http://code.google.com/p/srp-js/
You can see the end result at https://github.com/luckyrat/KeeFox/blob/master/Firefox%20addon/KeeFox/modules/SRP.js
For my purposes I have optimised away a round-trip but you'll have to assess your own use case to determine whether my specific implementation would be secure.
I had trouble with the first couple of BigInteger libraries I tried (most seem to be faulty for the operations required by SRP) but settled on https://github.com/luckyrat/KeeFox/blob/master/Firefox%20addon/KeeFox/modules/biginteger.js
I've just had a fresh look into native BigInteger support and it still doesn't look like there are any options.
From a firefox addon perspective, I am wondering whether js-ctypes could give access to some Firefox internals that would allow me to speed things up a bit but I've seen my only previous use of ctypes break compatibility with 2 out the 10 Firefox versions that have been released since implementation so I'm wary of using them unless it becomes essential.
Thinbus which is on npm at https://www.npmjs.com/package/thinbus-srp has a pure javascript client library which performs SRP to a java server (Edit or a PHP server). If you are not using java or PHP in your web it should be fairly straight forward to port the server logic to your web application as it is only using standard SHA256 hashing and BigInteger math which will be available in other languages.
One of the major requirements for accessibility standards such as WCAG is that the web site or application displays without the use of javascript or provides some sort of non JS alternative. I did some initial research and couldn't find much information on this in regard to websockets. Should I assume websockets are treated similar to AJAX?
Since Websockets require JavaScript to do anything useful, if you have a standard that requires you provide a non-JavaScript alternative, you will need to provide a non-JavaScript alternative that doesn't use Websockets. Yes, Websockets are just like AJAX; they're really just a way to create a persistent, 2-way connection rather than a one-time, request-response that AJAX provides. You should treat them just like you treat AJAX.
While WCAG 1.0 requires that you provide alternatives to JavaScript, WCAG 2.0 is more technology neutral; instead of requiring an alternative to JavaScript, it provides a set of techniques for making web pages involving client-side scripting more accessible. You should keep in mind that not all of your users will have JavaScript enabled; there are still some users who prefer to browse with it disabled entirely or by default. But accessibility technologies today are able to deal with certain uses of JavaScript, so you can write accessible sites even when there is no non-JavaScript fallback.
Brian's answer is good, but I figured I'd add some additional insights.
There's really two issues here: technology, and compliance.
As far as compliance goes, if for some reason you need WCAG 1.0, then you need a non-JS version. Because WCAG 1.0 says so. It used to be the case that some screenreader users would disable JS because it caused problems for screenreaders, but that's several generations of technology ago. A recent survey of screenreader users on the web showed 98.6% with Javascript enabled.
As far as the technology goes, the issues with Javascript and accessibility really have nothing to do with Javascript itself: the accessibility issues have to do with the fact that something (usually Javascript) is manipulating the UI via the DOM. It's that manipulation of the UI that's at issue with accessibility; care must be taken to ensure that the resulting DOM is accessible, and that screenreaders handle the changes appropriately - eg using ARIA live regions to ensure that a screenreader will read out new content if that is appropriate, or that keyboard focus doesn't disappear and end up somewhere unexpected.
Any javascript that doesn't change the UI pretty much by definition will itself not have accessibility issues: so web sockets, web workers, local storage and so on do not in and of themselves have accessibility issues; what matters is if and when you update the DOM later on.
In theory browsers could support several programming languages for client-side scripting of web pages. In practice, ECMAScript is the only one widely implemented and used in all browsers. So for most people, it is an integral part of the web.
However, it has never been promoted as a recommendation by the W3C for web page scripting. And HTML5 does seems to promote it either, even though client-side interactivity is becoming more and more important. Why it is the case?
Is it to prevent a programming language monopoly on the web platform? (obviously failed)
Is it because the W3C prefers to concentrate ONLY on the declarative side of the web?
Or simply a political stance?
I'll take a stab at this: W3C tries to draft and recommend standards. ECMAscript is already a standard, from ECMA. It doesn't need to re-ratify the language.
Something close to this is the w3c's attempts to standardize the document object model (DOM) by which all browsers interact with a HTML page using javascript/ecmascript (or vbscript or any other client-side scripting language.) This hasn't actually been smooth sailing tbh, but it's better than nothing (so they keep telling me)
http://www.w3.org/DOM/
-Oisin
I'm not a JavaScript wiz, but is it possible to create a single embeddable JavaScript file that makes all browsers standards compliant? Like a collection of all known JavaScript hacks that force each browser to interpret the code properly?
For example, IE6 does not recognize the :hover pseudo-class in CSS for anything except links, but there exists a JavaScript file that finds all references to :hover and applies a hack that forces IE6 to do it right, allowing me to use the hover command as I should.
There is an unbelievable amount of time (and thus money) that every webmaster has to spend on learning all these hacks. Imagine if there was an open source project where all one has to do is add one line to the header embedding the code and then they'd be free to code their site per accepted web standards (XHTML Strict, CSS3).
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
So, is this possible?
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
Well... That's kind of the issue. Not every incompatibility can be smoothed out using JS tricks, and others will become too slow to be usable, or retain subtle incompatibilities. A classic example are the many scripts to fake support for translucency in PNG files on IE6: they worked for simple situations, but fell apart or became prohibitively slow for pages that used such images creatively and extensively.
There's no free lunch.
Others have pointed out specific situations where you can use a script to fake features that aren't supported, or a library to abstract away differences. My advice is to approach this problem piecemeal: write your code for a decent browser, restricting yourself as much as possible to the common set of supported functionality for critical features. Then bring in the hacks to patch up the browsers that fail, allowing yourself to drop functionality or degrade gracefully when possible on older / lesser browsers.
Don't expect it to be too easy. If it was that simple, you wouldn't be getting paid for it... ;-)
Check out jQuery it does a good job of standardizing browser javascript
Along those same lines explorercanvas brings support for the HTML5 canvas tag to IE browsers.
You can't get full standards compliance, but you can use a framework that smooths over some of the worst breaches. You can also use something called a reset style sheet.
There's a library for IE to make it act more like a standards-compliant browser: Dean Edwards' IE7.
Like a collection of all known
javascript hacks that force each
browser to interpret the code properly
You have two choices: read browser compatibility tables and learn each exception a browser has and create one yourself, or use avaiable libraries.
If you want a javascript correction abstraction, you can use jQuery.
If you want a css correction abstraction, you can check /IE7/.
I usually don't like to use css corrections made by javascript. It's another complexity to my code, another library that can insert bugs to already bugged browsers. I prefer creating conditional statements to ie6, ie7 and such and create separate stylesheets for each of them. This approach works and doesn't generate a lot of overhead.
EDIT: (I know that we have problems in other browsers, but since IE is the major browser out there and usually we need really strange hacks to make it work, css conditional statements is a good approach IMO).
Actually you can,there are lots of libraries to handle this issue. From the start of the time, javascript compliance issue always was a problem for developers and thanks to innovative ones who developed libraries to get over this problem...
One of them and my favorite is JQuery.
Before JavaScript 1.4 there was no global arguments Array, and it is impossible to implement the arguments array yourself without a highly advanced source filter. This means it is going to be impossible for the language to maintain backwards-compatibility with Netscape 4.0 and Internet Explorer 4.0. So right out I can say that no, you cannot make all browser standards compliant.
Post-netscape, you can implement nearly all of the features in the core of the language in JavaScript itself. For example, I coded all methods of the Array object in 100% JavaScript code.
http://openjsan.org/doc/j/jh/jhuni/StandardLibrary/1.81/index.html
You can see my implementation of Array here if you go to the link and then go down to Array and then "source."
What most of you are probably referring to is implementing the DOM objects yourself, which is much more problematic. Using VML you can implement the Canvas tag across all the modern browsers, however, you will get a buggy/barely-working performance in Internet Explorer because VML is markup which is not a good format for implementing the Canvas tag...
http://code.google.com/p/explorercanvas/
Flash/Silverlight: Using either of these you can implement the Canvas tag and it will work quite well, you can also implement sound. However, if the user doesn't have any browser plugins there is nothing you can do.
http://www.schillmania.com/projects/soundmanager2/
DOM Abstractions: On the issue of the DOM, you can abstract away from the DOM by implementing your own Event object such as in the case of QEvent, or even implementing your own Node object like in the case of YAHOO.util.Element, however, these usually have some subtle changes to the standard API, so people are usually just abstracting away from the standard, and there is hundreds of cases of libraries that abstract away.
http://code.google.com/p/qevent/
This is probably the best answer to your question. It makes browsers as standards-compliant as possible.
http://dean.edwards.name/weblog/2007/03/yet-another/
Perhaps I'm just unaware of the competitors, but it seems when it comes to client-side scripting in the browser and DOM, Javascript is it. I know there's VBScript, but it really isn't even in the same ballpark as JS (not even cross platform, for starters).
I'm just curious about how this came to be. Surely there would be a general desire for a new language to replace Javascript: built from scratch to do all the things Javascript has been bent and moulded into these days (look at the reliance on JS Libraries).
Momentum. JavaScript has been around for 15 or so years, and browser manufacturers have worked for 15 or so years to make it work in their browsers.
If a competitor came along, it would need to really bring something new to the table in order to convince everyone to a) adopt it, b) live with locking out all the users of older browsers like IE7, Firefox 3.0, Chrome 1.0 etc. and c) find replacements for all existing libraries like jQuery, prototype, extJS etc.
In short: we don't need another Standard, let's rather improve JavaScript and build on the rich foundation that already exists instead of starting back from stone age again.
There is! Ones that spring to mind are Flash, ActiveX, and Java... But these all have their drawbacks. Mainly security and integration with the browser/DOM.
Flash and Java live in their own little world, by design (and to address security issues). They can't alter the HTML around them. ActiveX has access to the DOM, but also everything else on your computer.
JavaScript seems to have found a nice balance between flexibility and security, it can trivially interact and alter the pages HTML/CSS, do "safe" networking, has a decent standard library (which has things like JSON, XmlHttpRequest'sih networking, DOM manipulation, and so on). Most importantly, it's available in basically all vaguely-modern browsers, on all platforms, in a consistent manner (compared to CSS)
There are problems with JavaScript, but nothing major. The biggest is the performance. Load a comment page on Digg and watch your CPU usage. Chance are it will be 100% of one CPU core. There are projects to improve this, like SquirrelFish, TraceMonkey, and other strangely named things. But the performance is adequate to do some extremely impressive things (Google Spreadsheet, for example).
Basically, JavaScript is great, and it's drawbacks aren't nearly as big as the other competitors.
JavaScript won because it was introduced by Netscape in the period when they had above 90% percent market share. IE and other browsers had no choice but to support it also.
If a new language should be introduced, it would have to be either by agreement between all major browser vendors, or in a period where a single browser have enough market share to push it through.
Microsoft could probably have pulled it off some years ago when IE has an extremely large market share (before the rise of Firefox and Safari), but they chose instead (for strategic reasons) to let the browser stagnate.
Today, a new language would require agreement between at least Mozilla, IE and Safari to gain traction, and I think that is highly unlikely. The browser vendors have invested a lot of ressources in optimization, compatibility testing and so on for JavaScript - why should they want to start from scratch with a totally new language - and have to support two languages in parallel for decades to come? The cost greatly outweights any benefits.
Anyway, it is quite unrealistic to believe that a new language designed from scratch could be significantly better than JavaScript.
Show me another language that isn't reliant on libraries?
C, C++, C#, VBs, ... all rely on libraries. The only difference is that they often come with a standard set of libraries.
So do we really want is a standard set of libraries? What we're currently getting is a range of library sets (JQuery, prototype, extjs, mootools, etc). This is a good thing since we the developers get to choose one that suits our needs. In addition these libraries can be included and evolved without changes to the client-side component.
I can think of no compelling language feature missing from Javascript. By compelling I mean so earth shatteringly important that I'd be willing to alienate those browsers that do not support it.
Standardized (ECMA-262)
Common syntax and relatively simple to master
Good browser support
Extendable
Still being developed
Relatively quick based on how much data it needs to process sometimes.
If a good competitor had arrived before 1999 (ECMAScript 3), it would probably be a tie between those two.
There are other languages for client side scripting, but AFAIK, none are integrated into a browser.
Both Flash and Silverlight have their own Languages. Flash has ActionScript, while Silverlight has many and all that work under the DLR including Python and Ruby.
To your second point as to why, more specifically you mention reliance on JS libraries as a flaw in the language; Libraries are popular, not because the language if broken, but because the standard API is broken. The existence of such great libs builds on the power of the language.
There is nothing particularly wrong with JavaScript, it has some features that up to very recently would have been esoteric or academic. First class functions for example.
Also, ubiquity / mass existing runtime deployment is a very compelling feature. ;)
I recommend you to view Douglas Crockford’s presentation about “The JavaScript Programming Language” to learn about the history of JavaScript.
I think Javascript (ECMAScript) with its C like syntax is so popular for some of the reasons C is:
Relatively small number of language
keywords (easier to learn).
Concise and efficient syntax (quick to write).
Easily extendable
through external libraries and APIs that do
not pollute the basic language (ie Browser DOM,FilesystemObject etc).
Creating a new language that will provide many of the current libraries "built-in" is always risky as it starts to limit future applicability of the language and makes learning the base language harder.
This would be even more problematic for a client side browser language because the language designers can't possibly know how the language may be used in the future.
I think Javascript the language is fine in its current role as the "glue" that links so many other client sode technologies.
There are no other competitors because while Javascript is not perfect, it does the job.
I guess because the demand for it would have to be huge for browsers to implement it.
After all, it's the browsers that process and run the JavaScript and you'd have to have a large amount of sites using the language in order to make the browsers interested in implementing it. Then again no-one would use it if there was no browser support in the first place.
i'd say that this is because client side web development is still a very young branch of programming.
if you look at it only now it has become more widespread since we moved to faster "intertubes" :) and we're not using modems anymore.
and the problem for clent based web development is that it's not up to the developer what platform he'll use but it depends on the browser manufacturers.
and they change slow.
VB script's demise was in my opinion its VB-innes. too much unnecessary stuff.
As for javascript it will mature, but it's a start.
Browser support. If its not an MS tech the it most likely will not go into IE. If it's not in IE then no one can use it. If it is an MS tech, then most likely only IE will have the right to use it as it will be closed source and proprietary. If only IE supports it then only some developers will use it.
To challenge JavaScript it must work just as easily and more consistently across all of the major web browsers. Without browser support any new client side web tech is destined to fail.
I think it has to do with standardization, because durring the last browser-war (ie v. netscape) there were two, Netscape's ECMA (+1 Geek point for you if you knew this was the real name for JavaScript) and Microsoft's JScript, obviously ECMA (JavaScript) won out and became the defacto standard.
Now, we have another browser-war in progress and each of the 2 (3 if you count Chrome 12% FFS) major competitors 3 fully (with a few edge-cases) support JavaScript.
My guess is that its ubiquity and ease of integration in any new user agent project. It comes built into almost all browsers so you dont have to download/install/configure anything to have it running. once you look at user agents off desktops (wii, iphone, windows mobile, n95 etc) the availability of any of the contendes dries up quick - so you code for html and javascript becuase it will work most of the time.
I agree with Michael, we should improve Javascript, not worry about competitors because there aren't going to be any, in fact even Javascript 2.0 seems so far from reaching reality.
Since Javascript is such an ambiguous language, we're able to create libraries (jQuery) and even abstractions (Objective-J) and not worry about all the problems that Javascript has at its heart.
After so many years we don't even have CSS implemented same in all the browser, same goes for the JavaScript, IE has one model and rest of browsers has another Model (I mean like Event Handlers and attaching events).
If new competitor comes, it has no chance, neither it has so much time as css and javascript had.