Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

Can WCAG 2.0 be simpler?

Posted on October 23, 2006

in Commentary & Society | IA/Usability

by Vladimir Popov (Vladimir)

Rated 4.07 (Ratings: 1) (Add your rating)

Log in to add a comment
(7 comments so far)

Want more?

 
Picture of Vladimir

Vladimir Popov

Member info | Full bio

User since: September 20, 2006

Last login: February 02, 2007

Articles written: 1

WCAG 2.0 and Peace

The new WCAG 2.0 standard sparked a hot discussion around web accessibility and the standard direction. The main issue is 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: wording changes for better clarity, changes to success criteria priority, new common failures and techniques. Does it make the standard better? Maybe… Does it make it simpler? Not really…

The main problem of WCAG 2.0 is its size. Understanding and Techniques documents are so big, that my IE7 works slow on them. FireFox performs better, but even it died once without any notice during my WCAG 2.0 documents browsing. By its size WCAG 2.0 is very close to War and Peace of Leo Tolstoy. This titanic book is a part of the official high school curriculum in Russia. However only a few scholars really read it. They prefer abridged versions, which take around 5% of the original folio.

Talking seriously, WCAG 2.0 is too broad to convey easy to understand ideas about web accessibility. In attempt to combat complexity and size, many web developers suggested a compact version of WCAG 2.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 from the side of the software developer, who has experience with internet browsers and web accessibility. The most strange thing to us in the WCAG 2.0 that the working group relies only on web developers to make their pages accessible. There is no discussion regarding user agents (screen readers and internet browsers). 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 user agents 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, millions people, who create web pages, and billions of web pages. Consider the following:

  • 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 a conclusion that defining content accessibility should start from examining user agents and recommending the software, which really works well and can be improved further. It is hardly possible to design accessibility guidelines for any user agent. Limited scope of user agents is a good platform for easy to understand and feasible accessibility guidelines.

WAI should specify the UAAG requirements, which match the needs of WCAG 2.0. These guidelines should set technology targets to assistive tools vendors. As soon as a technology target is met by the most of recommended user agents, the corresponding WCAG 2.0 requirement should 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 be removed or simplified.

WCAG 2.0 user agent dependant success criteria

SC 1.3.4 Information that is conveyed by variations in presentation of text is also conveyed in text, or the variations in presentation of text can be programmatically determined. (Level 2)

In the other words, if important information is conveyed in text by using bold, italic or other HTML markup, it must be understandable without markup. WCAG 2.0 proposes two solutions: explain the information using additional text or allow programmatic access to it.

This success criteria is mixing requirement to a web content (presentation … conveyed in text) with a requirement to a user agent (presentation … can be programmatically determined). In fact, text font, size, typeface is always can be extracted from a browser. If a browser writes text in bold it knows about it. The assistive tool can get information about text typeface through browser's API. A web developer can not do anything to prevent an assistive tool from obtaining this information.

Using this knowledge we can conclude that the related common failure F2: Failure of SC 1.3.1 and 1.3.4 due to using CSS to create variations in presentation of text that conveys information without also using the appropriate markup or text. is not valid. It assures, that a web developer can confuse a user by using not appropriate CSS. However a browser shows the NO word in bold and an assistive tool (Jaws, for example) can inform a user about bold text regardless the CSS class definition.

Conclusion.

The modern versions of assistive tools can inform a user about markup. Therefore the second part of the SC 1.3.4 is met. WCAG WG 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 define text and background colors on a web page. Furthermore, it is possible to improve the contrast automatically on page, calculation the contrast and brightness using the W3C formula. Do we really need this requirement for text in HTML on the level 2, if it can be fixed by user agents automatically?

The related common failure F24 provides examples of code, which does not allow certain (not specified) user agents to enable user defined font and background colors. If a browser does not allow to change text and background colors, it is a clear user agent problem. Our team tested all these examples using Internet Explorer 6 and 7 beta 3, FireFox 1.5, Opera. In fact, only IE 6 has problems with the examples 1 and 2. The other browsers, including the IE 7, show text with the user defined color and on the user defined background correctly. Therefore the bug in IE 6 is fixed in the IE 7.0. Read the full test report.

The real contrast problem is with images and 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.

Conclusion

The color contrast problem can be resolved by user agents. This is not a real barrier. Therefore this SC should take place in 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 reader voice, which cause problems to disabled users. Internet Explorer has a setting to disable audio on a web page (Tools > Internet Options > Advanced tab > Multimedia > Play sounds in web pages). It looks like the problem is easy to solve. Unfortunately, it is not. The IE setting rules only HTML background sound. It can not disable sound from the ActiveX objects, like Flash. FireFox do not have a sound setting ever. In fact, many users dislike the sound from Flash, but currently they have the only option to mute the sound in operation system. This is not acceptable for screen readers.

The problem is in the Windows operation system. However it can be resolved. To prove the concept, we conducted a research and discovered a simple method to disable Flash and other browser sounds in FireFox and Internet Explorer. The other Windows sounds keep playing (including Jaws!).

Conclusion

The problem should be forwarded to Microsoft. They should provide a simple way to block all sounds originated from a browser and keep readers working.

Other WCAG 2.0 success criteria where user agents can help

SC 2.2.2 Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web unit or authored component. (Level 2)

Browsers enable text blinking on the corresponding HTML tags. Therefore they can disable it. Stop button in IE7 blocks animated GIFs, for example. The specific problem is blinking from Flash objects. Microsoft and Adobe should provide an API to stop animations.

SC 3.2.1 When 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 as navigating a browser to a new page on selecting a choice in pull down menu or changing focus on click, can be suspended as well. A user agent can ask a user whether to perform a blocked action. It seems this requirement is a good candidate for retirement.

SC 3.2.2 Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order), unless the authored unit contains instructions before the control that describe the behavior. (Level 1)

This SC is very close to 3.2.1 and can be resolved in a similar manner.

SC 3.1.1 The primary natural language or languages of the Web unit can be programmatically determined. (Level 1)

This SC puts a lot of attention to right-to-left language information. In fact, this kind of data is programmatically determined by browsers, since they need to render right-to-left text correctly. The RTL language is programmatically determinable by itself, because all they contain unique symbols. So it is quite easy to distinguish between Hebrew and Arabic. In contrast, Polish and Czech are not easy to detect automatically, since they share the same character set. If disabled users find it useful, browsers can inform them about RTL content presence on a web page.

Summary of suggestions to WCAG 2.0

  1. Define and officially publish the set of user agents for WCAG 2.0.
  2. 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.
  3. Update the WCAG 2.0 body with the user agent progress.
Vladimir Popov is a principal of Erigami, Ltd, a website quality assurance company. Erigami provides products and services to evaluate website compliance with accessibility, privacy, quality, performance, branding standards. Erigami runs a free online validation tool Truwex.
7 comments on this article. Log in to add your comment | Rate this article: Rate this node 1 star.Rate this node 2 star.Rate this node 3 star.Rate this node 4 star.Rate this node 5 star.

WCAG 1.0 is tough enough

Submitted by cianuro on November 22, 2006 - 14:30.

An excellent article Vladimir and some very valid points. I have been reading the 2.0 specs for the past week and am still not through. I have a really bad feeling about it too. Even to pass to WCAG 1.0 Level 'AA' is horrendously time consuming for Web Designers and web developers. Tim Berners-Lee has some excellent insight into this and between the WCAG and W3C specs, we're in for a long and turbulent time in the world of standards. Regards Dave Davis

login or register to post comments

colour contrast

Submitted by tresise on January 18, 2007 - 11:58.

I have to strongly disagree with the comments about colour contrast. I have a separate issue with the 1:5 contract ratio as the human eye does not record light in a linear way so having a fixed ratio does not work constantly from shadows, mid tones and highlights. Colour density is measured using a logarithmic scale, and the human eye has a different response again. The key point here is a 1:5 contract ratio in the shadows will not be perceived the as being the same as in say the midtones.

My second point is why should I struggle to see colours? Why should I have to make changes in the browser, perhaps for different sites because the designer can’t be bothered? The whole point of access for all means creating a site that is inclusive. The tone of this article is an abrogation of their responsibilities and high minded ignorance coming to a conclusion which means they don’t have to bother.

I wonder if they would be happy, changing settings all the time if they had a less than perfect sight, and a good monitor.

login or register to post comments

not abrogation, but technology solution

Submitted by Vladimir on February 2, 2007 - 13:08.

I’m asking the following questions in my article: How can technology help disabled users to access internet content? Can we do a bit more software development to reduce the standard body? Answering this question in relation to W3C color contrast requirements as it is defined in WCAG 2.0, I can say only “Yes”. Does it mean, that designers should not care about color contrast? Definitely not. I particularly hate websites with grey text on white background. Therefore I agree with your question “why should I struggle to see colours?”. But can we expect that all website will have normal contrast? I suppose, it is not realistic. Therefore the internet browser producers (or freelance add-in programmers) can do more to help color blind users. For example: - make a button on a browser toolbar, which fixes the color contrast on all text nodes - or do this operation automatically on problem text nodes All these things are very simple. You points the problem that fixed contrast ratio does not work well. Unfortunately, this issue is not considered in WCAG 2.0. Do you mean that the issues you outlined can be recognized by a human with normal vision ability?

login or register to post comments

this for every one

Submitted by tresise on March 2, 2007 - 15:57.

Your comment about helping 'colour blind' is too restrictive, this is not just for colour blind people. My comments are about people with normal vision. There many other conditions which also come into play here, so its not just visual ones but cognitive one as well, such as dyslexia. Proper 'colour contrast' should be for all. Just for the record by background is BSc Photographic Sc – with 30 years experience in visual media and design, both old fashioned analogue colour and this more modern digital stuff. The whole subject is more complex and subtitle than people actually appreciate.

login or register to post comments

Very well. Ultimately, it

Submitted by espmartin on May 3, 2007 - 03:10.

Very well. Ultimately, it _IS_ up to the designing community to reliably construct very usable and accessible designs, from every aspect of the design process. If I leave accessibility "clean-up" to browsers and UI's - I dare say I'll get very sloppy. Best Regards, Martin E.

login or register to post comments

very great post, I believe

Submitted by alansmith on May 26, 2007 - 03:21.

very great post, I believe this update addresses many of the concerns that were brought at that time and since. It’s certainly not yet perfect, I think WCAG 2.0 seem can't be simpler than now.

login or register to post comments

To the uninformed

Submitted by t4tw on June 21, 2007 - 00:18.

As I had the opportunity to participate in the translation process of certain documents associated with WCAG2 into Polish and had a closer insight into how things developed I'd like to share a few of my thoughts here. You may consider them to be the thoughts of not only a translator, but also a person that is keenly interested in the matter of accessibility. By the way, (a note to the Polish readers) you can find other translations of W3C documents on www.t4tw.info. But, let's get to the point. Although it took five years for a Web Accessibility Initiative (WAI) committee to develop WCAG 2, the results of their work are far from expectations that certain interested people had put on it. Firstly, the basic rules of WCAG 2 are against the idea of standards-compliant pages. It seems that a future website that complies with WCAG 2 won't need valid HTML at all.

Secondly, the whole WCAG development process was inaccessible to people not speaking English, not to mention those with disabilities. A question arises: how could they contribute to it if they are not given the opportunity to do so? Although the drafts were prepared in a way to look reasonable and complete they don't look so. We can hear the discontent voices of those informed that definitely too little progress has been made and only low-priority guidelines have been covered which is a great dissapointment, not to use a much bolder statement, a failure. Moreover, suprisingly little time (more or less 1 month) was given to comment on such a long-term project. Now something from the point view of a translator. Some definitions used in WCAG 2 documents are simply very vague, so if you happen to be a man developing a site, you may turn out to be 'an author authoring authored units to be used in authored components in programmatically-determined web units that can be parsed unambiguously'. Don't those explanaitions already say it all? All in all, what has been attained really leaves a lot to be desired! What is your opinion on that?

login or register to post comments

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.