Following in the footsteps of the discussion initiated last month, allow me to go further down the path of the so-called “accessibility core rules” as we cover the remaining accessibility principles that are operable, understandable, and robust.
In the spirit of grabbing what each one of those principles actually entails, here is a proposal to help build a more solid understanding of accessibility by looking not at the Success Criteria in detail but at the guidelines that are tied to the principles and what they mean. By teaching about core rules first and making sure stakeholders understand them, I believe we can convey a stronger, more foundational understanding of Web accessibility to the developers and designers in the trenches today.
Core rules on how to make content operable:
- Make sure that all functionalities can be fully used without a mouse and that users never get trapped in user interface components when using the keyboard alone.
- Make sure users are given enough time to read and use the content. Allow users to control time limits, if any, as well as control any type of movement or automatic updates at their own leisure.
- Make sure that content provided on the page has a low and short flashing rate, if any, in order to avoid causing seizures to users dealing with photosensitive epilepsy.
- Make sure that users can easily navigate, find content and determine where they are at any given time by providing them with clear descriptive navigation indicators, such as headings, labels and links. Make sure keyboard focus is always clearly visible.
Core rules on how to make content understandable:
- Make sure that text content is adapted to the intended target audience and is both readable and understandable to users as well as the assistive technologies they might be using. Provide clear mechanisms to support meaning, pronunciation, and the like.
- Make sure that the content in pages appears and can be operated in predictable ways by avoiding unexpected user interface changes, by providing consistent navigation patterns, and by making sure components are named consistently.
- Make sure that errors when submitting forms can be avoided or easily corrected by providing users with meaningful, context-sensitive, and assistive-technology-compatible error messages and remediation suggestions. Allow users to review and modify their data before submitting.
Core rules on how to make content robust:
- Make sure that every user interface components are compatible with assistive technologies used by people with disabilities on the Web and that the proper semantics and mark up is used when creating web pages.
To me, teaching Web accessibility can be as simple as covering these core rules. You can always count on people to ask you more specific questions anyway, so at some point you do get to dive in, but building that solid foundation is what matters. By talking about user experience first and explaining what goals we’re trying to achieve with Web accessibility, what we truly end up teaching are quality best practices that benefit everyone, including people with disabilities. I want designers and developers out there to grow awareness about issues first, instead of blindly jumping at solutions they can’t fully grasp yet.
I am aware that by talking about core rules I voluntarily simplify what Web accessibility represents. This is in no way a denial of the value of WCAG 2.0 to a “real accessibility expert” who knows what he or she is doing; but let’s face it, not everyone is as passionate as the Web content Accessibility Guidelines as we are.
I’ve seen enough people causing more trouble than they solved, by being misled into inaccurate interpretations exactly because they were lacking that important foundation piece. I’ve come to think that, for most people that I teach, it is best to start by looking at the broader picture – and that’s precisely what these core rules highlight.
Being aware of those rules will not turn your average developer or designer into an accessibility expert overnight, but it will definitely lead them into creating better, more inclusive user experiences that are more likely to be accessible to all. In other words, these rules are not meant to teach them the “how” of accessible Wed design, but they are probably all anyone needs to understand the “why.” I want to trust designers and developers to come up with innovative solutions but only if they truly get what it is users need first.
Anyone with a browser and an Internet connection can go and read the specification. That hardly makes these people experts. The Web development community doesn’t need more accessibility experts; what it needs is more developers and designers that are truly aware of digital exclusion and that are willing to step up and make it their responsibility to bridge that gap.
My experience shows that those who actually understand the foundation presented in these core rules stand a much better chance of successfully using and implementing the information provided in the WCAG 2.0 Success Criteria and corresponding techniques. Have you had similar experiences while teaching Web accessibility?
Denis is a Web accessibility consultant working for Deque Systems from Montreal, Canada. He has been helping organizations of all sizes build a better, more accessible Web for everyone since 2000.Pragmatica11y will be posting on the first Tuesday of every month.