Can Wcag 2 0 Be Simpler
Posted on 23 Oct 2006
by Vladimir Popov (Vladimir)
Rated 4.08 (Ratings: 1)
- More articles in Commentary & Society
WCAG 2.0 and Peace
The new WCAG 2.0 standard sparked a hotdiscussion around web accessibility and the standard direction. The main issueis how to make WCAG 2.0 simpler and easier to understand for web developer community.WCAG working group received many suggestions to improve the standard: wordingchanges for better clarity, changes to success criteria priority, new commonfailures and techniques. Does it make the standard better? Maybe… Does it makeit simpler? Not really… War and Peace of Leo Tolstoy. This titanic book is a part of the official high schoolcurriculum in Russia. However only a few scholars really read it. They prefer abridgedversions, which take around 5% of the original folio.
Talking seriously, WCAG 2.0 is too broad toconvey easy to understand ideas about web accessibility. In attempt to combatcomplexity and size, many web developers suggested a compact version of WCAG2.0, which is easier to understand and to follow. This approach is definitely valid,however how to choose the correct rules from the broad set?
We are looking on the WCAG 2.0 process fromthe side of the software developer, who has experience with internet browsers andweb accessibility. The most strange thing to us in the WCAG 2.0 that theworking group relies only on web developers to make their pages accessible.There is no discussion regarding user agents (screen readers and internetbrowsers). The UAAG web site claims an intention to link content accessibility with accessibility requirements to user agents. However WCAG 2.0 was designed without clear definition of the useragents where it can be applied. The result of this approach is a huge set of rules,which are hardly understandable for many web developers.
Roadmap to simpler web accessibility
There are only a few assistive tools, millionspeople, who create web pages, and billions of web pages. Consider thefollowing:
- Some assistive tools are not good enough.
- It is much simpler and quicker to improve several assistive tools than to teach accessibility to millions of web developers.
- From the billions of existing web pages, only a tiny share will be modified to conform WCAG 2.0. Therefore, there is a need for good assistive tools to view legacy content, which will never be modified.
- The technology, not the bureaucracy, makes life easier.
Summarizing the points above, we make aconclusion that defining content accessibility should start from examining useragents and recommending the software, which really works well and can beimproved further. It is hardly possible to design accessibility guidelines for anyuser agent. Limited scope of user agents is a good platform for easy tounderstand and feasible accessibility guidelines.
WAI should specify the UAAG requirements,which match the needs of WCAG 2.0. These guidelines should set technologytargets to assistive tools vendors. As soon as a technology target is met bythe most of recommended user agents, the corresponding WCAG 2.0 requirementshould retire or go to good practices status (level 3).
Our team investigated the WCAG 2.0 draft(level 1 and 2) in order to find success criteria, techniques and failures,which can be resolved by assistive tools. We detected several candidate SCs to beremoved or simplified.
WCAG 2.0 user agent dependant success criteria
SC 1.3.4Information that is conveyed by variations in presentation of text is alsoconveyed in text, or the variations in presentation of text can beprogrammatically determined. (Level 2)
In the other words, if importantinformation is conveyed in text by using bold, italic or other HTML markup, itmust be understandable without markup. WCAG 2.0 proposes two solutions: explainthe information using additional text or allow programmatic access to it.
This success criteria is mixing requirementto a web content (
presentation … conveyed in text) with a requirement to auser agent (
presentation … can be programmatically determined). In fact, textfont, size, typeface is always can be extracted from a browser. If a browserwrites text in bold it knows about it. The assistive tool can get informationabout text typeface through browser's API. A web developer can not do anythingto prevent an assistive tool from obtaining this information.
Using this knowledge we can conclude thatthe related common failure
F2: Failure of SC 1.3.1 and 1.3.4 due to using CSSto create variations in presentation of text that conveys information withoutalso using the appropriate markup or text.is not valid. It assures, that a web developer can confuse a user by using notappropriate CSS. However a browser shows the
NOword in bold and an assistivetool (Jaws, for example) can inform a user about bold text regardless the CSSclass definition.
The modern versions of assistive tools caninform a user about markup. Therefore the second part of the SC 1.3.4 is met. WCAGWG should consider excluding this success criteria out of the standard body.
SC 1.4.1 Text or diagrams, and their background, have a luminosity contrast ratio of at least 5:1. (Level 2)
The text contrast problem can be 100%resolved by browsers. Both Internet Explorer and FireFox have settings, which definetext and background colors on a web page. Furthermore, it is possible toimprove the contrast automatically on page, calculation the contrast andbrightness using the W3C formula.Do we really need this requirement for text in HTML on the level 2, if it canbe fixed by user agents automatically?
The related common failure F24provides examples of code, which does not allow certain (not specified) useragents to enable user defined font and background colors. If a browser does notallow to change text and background colors, it is a clear user agent problem. Ourteam tested all these examples using Internet Explorer 6 and 7 beta 3, FireFox1.5, Opera. In fact, only IE 6 has problems with the examples 1 and 2. Theother browsers, including the IE 7, show text with the user defined color andon the user defined background correctly. Therefore the bug in IE 6 is fixed inthe IE 7.0. Read the full test report.
The real contrast problem is with imagesand applets. There is no automatic way to improve the contrast in this case.However this situation is covered by the WCAG 2.0 success criteria 1.1.
The color contrast problem can be resolvedby user agents. This is not a real barrier. Therefore this SC should take placein the good practices of web accessibility.
SC 1.4.2 A mechanism is available to turn off background audio that plays automatically, without requiring the user to turn off all audio. (Level 2)
Playing sound interferes with the readervoice, which cause problems to disabled users. Internet Explorer has a settingto disable audio on a web page (Tools > Internet Options > Advanced tab> Multimedia > Play sounds in web pages). It looks like the problem iseasy to solve. Unfortunately, it is not. The IE setting rules only HTML backgroundsound. It can not disable sound from the ActiveX objects, like Flash. FireFoxdo not have a sound setting ever. In fact, many users dislike the sound fromFlash, but currently they have the only option to mute the sound in operationsystem. This is not acceptable for screen readers.
The problem is in the Windows operationsystem. However it can be resolved. To prove the concept, we conducted aresearch and discovered a simple method to disable Flash and other browsersounds in FireFox andInternet Explorer. The other Windows sounds keep playing (including Jaws!).
The problem should be forwarded toMicrosoft. They should provide a simple way to block all sounds originated froma browser and keep readers working.
Other WCAG 2.0 success criteria where user agents can help
SC 2.2.2Content does not blink for more than three seconds, or a method is available tostop all blinking content in the Web unit or authored component. (Level 2)
Browsers enable text blinking on thecorresponding HTML tags. Therefore they can disable it. Stop button in IE7blocks animated GIFs, for example. The specific problem is blinking from Flashobjects. Microsoft and Adobe should provide an API to stop animations.
SC 3.2.1When any component receives focus, it does not cause a change of context.(Level 1)
This SC can be resolved by user agents.Popup blockers are very standard today. The other unexpected actions asnavigating a browser to a new page on selecting a choice in pull down menu orchanging focus on click, can be suspended as well. A user agent can ask a userwhether to perform a blocked action. It seems this requirement is a goodcandidate for retirement.
SC 3.2.2 Changing the setting of any form control or field does not automatically causea change of context (beyond moving to the next field in tab order), unless theauthored unit contains instructions before the control that describe thebehavior. (Level 1)
This SC is very close to 3.2.1 and can beresolved in a similar manner.
SC 3.1.1The primary natural language or languages of the Web unit can beprogrammatically determined. (Level 1)
This SC puts a lot of attention toright-to-left language information. In fact, this kind of data isprogrammatically determined by browsers, since they need to renderright-to-left text correctly. The RTL language is programmatically determinableby itself, because all they contain unique symbols. So it is quite easy todistinguish between Hebrew and Arabic. In contrast, Polish and Czech are noteasy to detect automatically, since they share the same character set. Ifdisabled users find it useful, browsers can inform them about RTL contentpresence on a web page.
Summary of suggestions to WCAG 2.0
- Define and officially publish the set of user agents for WCAG 2.0.
- Define UAAG requirements, which conform with the WCAG 2.0. If a user agent wants to be included into the WCAG user agent list, it must comply with the UAAG requirements.
- Update the WCAG 2.0 body with the user agent progress.