Web User Education Guidelines
Web Accessibility is the responsibility of several key stakeholders. This includes web developers and content creators, browser makers, assistive technology and authoring tool creators, and those that create technical specifications for new languages and emerging technologies. It is also the responsibility of the end user, and they need our help.
Recently many have questioned where our responsibility as developers ends. At SXSW (also known as “Spring Break for Web Geeks”), James Craig of CookieCrook.com presented User Responsibility for Web Accessibility. Over on Accessify Forum, Patrick Lauke (redux) regularly provides a reality check reminding participants that the onus is also on the user.
As James and Patrick indicate, our work as “developers” is just one part of the puzzle of the overall Accessibility picture. Most developers – at some point or another – have asked themselves: “If I’ve done my job to make my content accessible, why is it my fault that the browsers and screen readers don’t work right?“
Ultimately we need shared responsibility between several key groups in order to ensure that we attain the goal of accessible web content.
Sharing Responsibility
In addition to the Web Content Accessibility Guidelines with which many standards-conscious developers are becoming very well acquainted, the World Wide Web Consortium has also produced several other Guidelines for our use:
- User Agent Accessibility Guidelines
- Authoring Tool Accessibility Guidelines, and
- XML Accessibility Guidelines
These are mainly focussed on technology – UAAG and ATAG are directly related to the the software that is used to either produce or consume web content, and XAG is focused on the underlying code and specifications that provide developers/authors the mechanism to deliver their content – whether through XHMTL, RSS, Atom or some other XML based format.
All of these are designed to “make the web a better place” in some way shape or form. Unfortunately none of them provide guidelines that shape the way we help the the end user, and develop the competencies of those end users over time. As someone who has been teaching people for 11 years in secondary, post-secondary and corporate training settings, I am a firm believer that while we can say that the onus is on the user, they also need a push in the right direction. After all, how will they know what they do not know? Not all users are active learners, seeking to learn and find new methods of doing things. What can we do to help them, help themselves?
Fish and Fishing
So, what are we to do? The old adage goes something like this:
Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime.
The trick is finding the right balance. If you focus only on teaching them to fish, they starve in the short term. If you focus only on giving them fish, they starve in the long term. We need to balance the short and long term goals – providing some fish to satisfy the hunger, while teaching them to fish for themselves at the same time.
We currently have a number of best practices for dealing with certain “issues” in web design, like providing text-sizing widgets for web pages. While a text-sizing widget may be useful when implemented on a site, that really only helps the end user on that particular site.
Perhaps what we really need is the widget (to help in the short term – providing the fish), along with an explanation of the reasoning behind it (to help in the long term – helping the user learn to fish for themselves),
With that, we present the Web User Education Guidelines, Working Draft. Modelled loosely on the Web Content Accessibility Guidelines:
Guideline 1: Provide equivalent alternatives to experience the web
Principle: Provide tools that when presented to the user, perform essentially the same function as existing tools.
- Checkpoint 1.1
- Provide alternative methods for viewing the web. Reliance on a particular browser simply because it is there is not acceptable. Exposure to and exploring different browsers is critical to empowering and educating users.
- Techniques for Checkpoint 1.1:
- Displaying educational notices on web sites explaining the benefits of using alternative standards compliant browsers is to be encouraged. This might be a kindler, gentler Browser Upgrade Campaign
- In person demonstrations, client walkthroughs and presentations at conferences should employ alternative browsers to encourage awareness of different user agents
- Checkpoint 1.2
- Provide alternative methods for navigating and using the web. Many people do not even know they can use the keyboard for navigation. Exposure to this type of functionality may enhance the ability of a user to fill in online forms, navigate more quickly or generally improve their experience online. It is better that they are aware that they have the choice.
- Techniques for Checkpoint 1.2:
- Demonstrate keyboard navigation in cases where possible.
- Briefly explain keyboard nagivation in your site “Colophon” or Accessibility Statement, or Help documentation.
Guideline 2: Design for User Independence
Principle: The end goal is to ensure that web users can operate on their own confidently and competently. This includes being able to change basic settings such as text size, understanding cookies, privacy, language settings and various other features.
- Checkpoint 2.1
- Explain the utility of features of the web sites that you develop.
- Techniques for Checkpoint 2.1
- Provide explanations along with web sites that explain why your site features are useful, and how similar effects can be achieved on other sites via user agent preferences.
Guideline 3: Use Interim Solutions
Principle: Many end users don’t know that they can adjust their user agent preferences (font size, colour scheme, window size, language preferences). Much software is like the human brain — we only ever use about 10% of its capability. With software, quite often this is simply a case of awareness, something we can attempt to address with interim solutions.
- Checkpoint 3.1
- Until users know they can change the size of text via their user agent preferences, provide an onscreen reference to changing text sizes, even if using relative font sizes.
- Techniques for Checkpoint 3.1:
Along with text sizing widgets we implement on the sites that we build, include some form of text based link: “What’s this?”, leading to a brief explanation why a text-sizing widget is needed in the first place and how the user can have better control over text size by using user agent preferences instead of the text-sizing widget.
This accomplishes two things:
- Promotes greater awareness of what settings are changeable in their user agent.
- Helps end users learn techniques that increase the usability of all web sites to them, rather than having to rely on text-sizing widgets that are not likely to be present on every site they visit.
- Checkpoint 3.2
- Until users know they can change the length of lines of text by resizing the user agents viewport, provide a reasonable alternative.
- Techniques for Checkpoint 3.2:
This may include using min-width and max-width settings, and/or a fixed width layout, along with an alternative to provide a liquid layout that the user can choose via an alternate stylesheet.
This accomplishes two things:
- Promotes awareness that variable line lengths can be useful for reading in different scenarios
- Helps users learn techniques that allow them to adjust the widths of all sites to be comfortable for them to read.
Where next?
In order to successfully help web users improve their skills and knowledge, a few more key points might be in order:
- Utilize the visibility of widgets that are on the screen to draw attention to and briefly explain the reasoning behind the widgets.
- Implement these techniques on personal sites, blogs, and developer resources to demonstrate these practices to other developers.
- Implement these techniques on sites that average users visit.
This is really just the start of a number of techniques that could be used to help web users become more knowledgeable and skilled. Certainly these guidelines and techniques could be developed further.
