Weblogs: Web Accessibility

Niqui Merret invited me to be part of a panel discussion about the state of accessibility, along with co-worker Tom Hughes-Croucher, and Matthew Somerville.

After a slightly jerky start, we got into a very interesting conversation on a number of problematic areas about web accessibility, starting with the separation of responsibility. It is becoming increasingly clear that there are certain features that are best placed within the user-agent - like font-resizing and printing, and the website should not try to duplicate this behaviour.

The panel discussion, with very insightful comments and questions from the small audience, crystallised a number of thoughts for me:

Defining responsibility

Creating an accessible web experience involves the co-ordination number of independent groups. The website builders have an important role, but they cannot cover the entire spectrum of accessibility issues. The user-agent vendors (typically browsers, but not limited to that) play an equally important role, taking accessible content and rendering it in an accessible way. They are also tasked with the responsibility of easing visitor access to content by features such as font-resizing, alternate stylesheets, colour filters, print functionality. The assistive technology provider also plays an important role, making sure that content is conveyed to the user in a way they can perceive and operate (naturally this has dependencies on the operating system making content accessible via an accessibility framework.

For improving and establishing effective accessibility features, its crucial they are implemented at the right level of the web experience stack. Its not a genuine improvement for a website to implement accessibility features that are more effectively done in the user-agent. An accessibility feature implemented in a browser is available for use on all websites, but implementing it on the website layer makes the feature only available on that one site.

Colour contrast is an interesting area of responsibility, its a partially shared responsibility. The web developers need to ensure that the markup and styles they deliver are such that the styles can be removed if they create a barrier. This, of course, is the fundamental principle of web standards development - the separation of content, styling and behaviour.

The user-agent's responsibility is to provide the functionality to alleviate colour contrast issues - particular colour-blindness related barriers, either by filtering out the combinations of colours that the user finds problematical, or by removing colours altogether.

Contract of Trust

I stressed the importance of remembering that developing on the web is based on a series of shared responsibilities - for instance, the web developer has the responsibility of creating good quality markup and styles, the browser has the responsibility of rendering those resources in a usable manner for the browser-user. Its a mutual trust that allows this to work, but that trust needs a concrete foundation for it to work effectively and for the best interests of the site visitor.

Its also critical that no one party holds a dominant role in providing the site visitor with an accessible experience. Dominance means that the party has no pressure to pull its own weight in the chain of responsibility, or abrogate its responsibility. A good example is Internet Explorer's feature of disabling stylesheets or overriding pixel font-sizes are hidden deeply inside configuration options. Another good example are the Windows screen-reader vendors, who essentially hold a captive market, there's no incentive to support the groundswell of web standards based websites even if it can be in the user's best interests.

A foundation of trust is a well understood divide between where the responsibility of one party in the chain ends, and where the responsibility of the next party in the chain starts. We need to be in a position that web developers can trust browser vendors to render their content and suggested styles properly. The browser vendors need to be able to trust web developers to generate sites that are of sufficiently good quality (accessible content with well structured markup, styled with cascading stylesheets, and behaviour added unobtrusively with DOM Scripting). The assistive technology vendors need the confidence that the content rendered by the browser is provided as a robust data structure via the appropriate accessibility interface or framework.

The concrete foundation we have are the W3C recommendations - that is a contract, or an agreement between the web developer and the browser vendor. That agreement is important, without it we are left with de facto standards and browser wars. Web Content needs to adhere with the Web Content Accessibility Guidelines (where appropriate, the development tools must support the Authoring Tools Accessibility Guidelines), browsers and assistive technology need to support the User Agent Accessibility Guidelines. These three documents are stable, publicly open recommendations and guidelines. There's no reason for any party not to apply the applicable guidelines - and its important that they do so, since this is where the confidence and trust between parties is built, and were it seems to fall down.

We must be pragmatic and practical, but not at the expense of the fundamental basis of trust. Accessibility has suffered because of the dominance of Internet Explorer. Its suffered because of the dominance of JAWS and Window Eyes. Its suffered because of web developers not building sites to web standards. Every party has a measure of blame to accept, and accept it we must so we can be aware that we need to improve, and we need to be seen as improving. Web developers, Browser vendors and assistive technology providers need to publicly acknowledge the need for continuous improvement, and then publicly travel that road of improvement.

Meaning and Interpretation

Differences of meaning and interpretation are another stumbling block that adversely impacts the website visitor.

Pixels are a source of contention in Web Accessibility circles. Since recommendations are layered, its logical to use the CSS definitions of relative units when talking about font-sizes. And so WCAG 1.0 as written, allows the use of pixel sized fonts, since they are, by definition, relative. Internet Explorer is wrong not to allow pixel-sized fonts to resize, even though there's a sound reason behind it. But the web developer has to draw a line somewhere, and what better standpoint is there than a publicly available recommendation as opposed to informal suggestions from one browser vendor?

The issue is more difficult in that the intention of the checkpoint about relative checkpoints is that pixel-sized fonts are considered non-relative, contradicting the CSS recommendation. The spirit of WCAG is not to use pixel-sized fonts, yet the technical interpretation renders the opposite view. The issue is the meaning of the word relative - both views are correct, neither can claim absolute correctness, and so the use of pixel-sized fonts is not objectionably wrong. Internet Explorer's failure to resize pixel-sized fonts is based more on their support of the CSS recommendations, and not based on the spirit of WCAG. In that view Internet Explorer is wrong, and in breach of the contract of trust with web developers.

The definition of words goes a long way towards a common and mutual understanding. Relative fonts needs one definition to be globally unambiguous and clear. For WCAG to invent its own definition merely clouds the understanding of a recommendation, especially when it is not precisely defined within its own recommendation or normative supporting documentation.

Without a shared understanding of meaning, effective communication is difficult. Without a common ground to move forward on, effective co-operation is just not possible.

Schism

The lack of global consensus on the definition (and hence the purpose) of web accessibility is at the heart of the problems in web accessibility circles. Many people chose to ignore the only formal definition in the context of the web. And with that premeditated ignorance, there isn't a basis on which to build a common understanding, and no basis of trust between the web developers, browser vendors and assistive technology providers. That, unfortunately, suits the universality pundits - in terms of a nonexistent formal basis of trust, they've been homeless since the web's inception. Unfortunately, they've decided to squat with the web content accessibility guidelines - and that's hurting the practice of web accessibility.

The pragmatic approach

Practical and reasonable are the hallmarks of web accessibility. Our scope is about content and about visitors. We don't constrain ourselves to choices of technology, and we don't force that constraint on others. Every piece of content has an appropriate technology - as long as that technology is accessible, and as long as the selection is appropriate, then it is part of the accessibility toolbox.

Pre-selecting a baseline technology before deciding on the content is solving the wrong problem. Web accessibility is not about shoe-horning information into pre-determined technology. Its about making the practical technology selection after considering the content and the intended audience. This pragmatism runs contrary to the principles of universality, and so this stance is not tolerated by universality adherents posing under the banner of web accessibility.

Understanding

The crux is the definition of web accessibility. The only formal definition we have about web accessibility is found within the web content accessibility guidelines. Each guideline is written with that definition as a fundamental basis. Fundamental as in, if the definition changes, the interpretation of each guideline is different - either drastically or subtly. Instead of solving a problem that prevents or hinders a person with a disability, the guideline is warped as a solution to a user agent problem, which is certainly not in the spirit of the web accessibility initiative.

You can spot a universalist wearing an accessibility disguise by listening to their rationale as to why a website is not accessible - this includes whoppers like "Flash isn't accessible because it doesn't work in Lynx", and "its inaccessible because it doesn't validate". The most important part of the accessibility equation is ignored - the ability of a visitor with the right set of technology from completing the necessary tasks the online service offers.

Its interesting that universalists stand up and proclaim they are not against Flash, while at the same time twisting the poisoned knife with blanket statements that these technologies are used only to enhance an existing site. They are oblivious to the fact that Flash is content. This narrow vision is symptomatic of a premature technology stack selection - before analysing the content and its intended audience. Frankly it smacks of a self-protection racket - limiting the concept of the web to just something they can do - dogmatically rejecting other alternatives.

Moving forward

Its increasingly obvious that people really interested in accessibility - making content accessible to people with disabilities - need an environment where their ideas are valued, their experience shared. And free of the imposing posturing of universalists. There's a need for a clean start. The current web-developer focused organisations are tainted, constrained by universality, with sour to nonexistent relationships with assistive technology providers and browser vendors. And, more damning, a pervasive poison against any content that isn't HTML.

There needs to be a grassroots movement to share the experience of web accessibility in an atmosphere conducive to such endeavours. It needs to be open to all people interesting in moving accessibility forward - without any of the ingrained dogma of universality. Somewhere where content creators can work together on accessibility, regardless of the content technology (HTML, Flash, SVG, Canvas, multimedia). Where developers and browser vendors can exchange ideas and suggestions. Where assistive technology providers can participate in improving the accessibility experience for their customers.

Somewhere where genuine progress isn't drowned out by vociferous universality adherents, somewhere where genuine passion can be directed into something constructive.

GAWDS has failed. Accessifyforum has failed. Accessites is fundamentally flawed. WCAG 2.0 is in trouble. Joe Clark's WCAG Samurai remains as a glimmer of hope, so to is WaSP's Accessibility Task Force. We need something that doesn't repeat the same mistakes as GAWDS and Accessifyforum, but at the same time be open to involvement by the community, for the community

My support for the WCAG Samurai and WaSP Accessibility Task force remains positive and optimistic. But, we also need something else - we need a community of people working on the Web (as a content producer, as a browser - or plugin - vendor, as an assistive technology provider), focused on accessibility. And that we simply don't have.

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]