Can Wcag 2 0 Be Simpler

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.