Don’t Shoot the Messenger
Over the last 15+ years I have regularly presented at accessibility conferences and have also conducted several training sessions on the topic of creating accessible digital content. More than once I have been told by some in attendance, “You are taking away my creativity!”
This comment has generally come from designers, but not always. I also understand why some may feel this way when they first start learning about digital accessibility. Accessibility, especially the Web Content Accessibility Guidelines (WCAG), can be overwhelming at first. For those who may not understand the technical aspects of digital accessibility this can be a common emotion – especially if your organization is telling you must start creating accessible content and then make you attend training on the subject with the expectation that this is all you are going to need. It doesn’t help that these presentations and training sessions on digital accessibility can be a lot of information. It may feel like you are being forced to drink from a fire hose.
The purpose of this post is to acknowledge the difficulty of this reality for many, to help management understand accessible content doesn’t happen overnight, and to hopefully demonstrate that accessibility doesn’t stifle the creative process.
Understanding what is required for content to be accessible should empower all who are involved in the web content lifecycle. Those that are good at their job now can become excellent at their job. This is meant in the sense that if you are currently only designing, creating, coding, or testing with mouse users in mind, you can expand your skill level to include other groups outside that category. In so doing, you not only become more skilled, but you are helping your organization be inclusive to all.
Is Accessibility Difficult?
Creating accessible content is not difficult, yet if you are new to accessibility it can seem like an impossible struggle. There is a lot of information that must be understood to ensure that content is being designed and created in an accessible way. There are also many “quick fix” solutions on the marketed which add to the confusion. It also doesn’t help that WCAG, the de facto accessibility standards for most, is often vague and technical.
While accessibility itself is not difficult, gaining the knowledge and experience needed to properly apply these guidelines can be difficult and time consuming.
When WCAG 2.0 was published as a recommendation in December 2008, one of the goals was to provide guidance that could be applied to newer technologies as they are developed. By doing so, these guidelines would have a longer life span compared to previous guidelines and standards. This makes sense because technology moves at such a fast pace and the time it takes to create new guidelines means you are always chasing the technology, which is not a sustainable model.
The W3C addressed the need for longer shelf-life guidelines by structuring WCAG so that there are success criteria which are written as testable true/false statements, which are not technology specific. This allows the criteria to applied to existing and future technologies. Each success criterion is then supported by sufficient, advisory, and failure techniques that cover general and technology-specific ways of conforming with the success criterion. Yet conformance doesn’t necessarily require that you use any of the published techniques, if you can achieve the purpose stated by the criterion with other methods.
While this model works, it does make it harder for many to properly grasp what really needs to be done to create accessible content. Since there can be many recommended techniques to conform with the success criteria, and because you are not required to use any of the specific techniques, a situation is created where a lot of assumptions can be made. This means if you do a web search for how to conform with a success criterion, you may find a lot of different approaches. These can often conflict with other recommendations, omit groups of users, or just be plain wrong.
While accessibility itself is not difficult, gaining the knowledge and experience needed to properly apply these guidelines can be difficult and time consuming. This needs to be understood by accessibility beginners and anyone who is requiring their teams to start creating accessible content.
Accessibility is a Journey – Not a Destination
Another common difficulty associated with digital accessibility is that many may think that once you make your digital content accessible, you have accomplished your goal. This is simply not the case. Why?
If you are creating a static web page, or pages, that will never be updated, you may be able to make the content accessible and not worry about accessibility again. This is not the case for most, as website are constantly redesigned and updated with new content. Even if the pages are meant to be static, as new web technologies emerge, older content can become obsolete and fail to stay accessible.
Just as with digital security and privacy, accessibility should be considered as part of the journey of digital content and services. Considering accessibility at the very start and ensuring that accessibility is considered through the web content development lifecycle will provide the most cost-effective and sustainable path to accessible content.
Being reactive about accessibility and thinking it is just something you must check after development is complete is a path to failure and creates a high risk of legal complaints. Being proactive and addressing accessibility with the same importance as security and privacy not only lowers the risk of potential litigation but also is the best way to ensure that digital content being created is as accessible as possible.
It is important for project and upper management to fully understand that accessibility is a journey and not a destination. In so doing they can ensure that proper training, funding, and expectations can be set that will avoid the trial-and-error method many organizations initially take.
Examples of Creative Accessible Design
I am going to get off the accessibility soapbox now and focus on a few examples of how understanding accessibility doesn’t stifle the creative process but rather empowers the creative process and allows individuals to do what they do best – create interesting and engaging experiences that are not just focused on mouse users but all users.
Creative Visual Headings
For non-visual screen reader users one of the most beneficial accessibility considerations is to ensure that the information and structure of the page content can be easily understood visually and can be programmatically determined. Using appropriate headings also benefits assistive technology users in providing another method of navigating the page content.
We often see sites that do not use headings because of the aesthetics of the page design. In some cases, this may make sense visually but has the opposite effect for the non-visual user. In cases where this is true, a simple way to provide that structure is to provide the headings at the source level but not display them visually. Just know that there are caveats in this approach and if you are in doubt, seek the help of an accessibility consultant such as Converge Accessibility.
When it comes to the creative process, I recently came across a page that I felt demonstrates how the creativity of the designer and the accessibility knowledge of the developer allowed for visually engaging and accessible headings. While the overall page itself does not fully conform to WCAG, the way the headings are presented allows for the non-visual user to understand the structure and relationship of the information, and still use headings as a means of navigation if necessary. In the following screen shot, notice how the heading appears to be more visually decorative and part of the background rather than actual text.
At first glance I thought this heading may be a background image which would be inaccessible. The designer and developer worked together to ensure that these headings are text headings yet maintain the visual design. Why does it matter that the headings on this page are text? First, the text is part of the page text. Therefore, if the images fail to load the page text is still available. Second, if the style sheets fail to load, or if the user needs to apply their own styles of turn them off entirely, the headings remain where they belong as part of the page text.
The contrast ratio of the heading in the example above does fail to meet the contrast minimum. That is a simple fix and should not take away from this example that demonstrates how accessibility does not stifle the creative process.
SVG Radio Button Selector
Recently I was working with a client who was using a slider pattern to allow the user to select answers within a questionnaire. Visually the control worked wonderfully with just the mouse and keyboard, but programmatically it was inaccessible to assistive technologies. This is because the slider pattern is designed to allow the user to select a value from within a given range. Therefore, assistive technologies were returning number values instead of the possible answer choices as were shown visually.
Even if the developers were to force the behavior through scripting so assistive technologies would hear the various answer choices, touch-based devices would likely be a problem. This is because the touch-based devices often use special gestures for sliders patterns. This could require additional scripting and might not work as expected on all touch-based devices.
Changing the current design was also an issue because the design was already approved, and the customer was emotionally invested in the design. Which is another key reason to address accessibility at the concept and design stages.
Did this stifle the creative process for our client? No! Instead, we were able to offer a solution that would provide the same design and user experience just by changing the type of control to one that is more appropriately suited to the purpose.
Following is an example of how we accomplished this. It is not the exact same resolution, but the principal is the same. We are using standard HTML radio buttons within the page source to allow the user to select their choice of options regardless of if the user is a mouse user, keyboard-only user, or a screen reader user. The creative team was able to put their skills to use to visually provide something that behaves like a slider pattern but also works with assistive technologies as intended.
NOTE: if you have trouble accessing the CodePen example below, you can access it directly via CodePen or via this separate HTML file.
What we have demonstrated in the previous example does not look 100% like a slider, but you can likely tell that the development, graphics, and style teams could apply their skills to make it look like a true slider. Why? Because they have been empowered with the accessibility knowledge to create a solution for everyone, not just a mouse user.
NOTE: There is an accessibility issue in the radio button example above. If you can find it, please leave a comment and show the world your accessibility testing skills!
See the Pen Accessible Custom UI Radio Button Selector by Jeff Singleton (@jwsingleton) on CodePen.
Summary
As we have already mentioned, creating and maintaining accessible content is not difficult if we understand what users require to successfully interact with the page, regardless of the methods used (e.g., mouse, keyboard, screen reader, etc.). Having this knowledge and applying it at the concept, design, development, content creation, and testing stages is the to key creating accessible and sustainable content.
This doesn’t happen overnight and cannot be achieved by attending as single accessibility training session or conference. There is no quick-fix solution that will fully make your content 100% conform to WCAG – no matter what the salesperson or marketing material say. It takes time and commitment from all involved in the web content lifecycle – include support from project managers, upper management, and even marketing and legal teams. Accessibility is everyone’s responsibility and is not just a developer issue.
