WCAG: Go Beyond and Be Creative by Irfan Ali from Princeton, New Jersey
This is written by Irfan Ali who lives in Princeton New Jersey
Everyone is struggling with the best possible way to implement, support and achieve accessibility compliance. Web Content Accessibility Guidelines (WCAG) conformance, whether 2.0 or the coming 2.1, is the global target and benchmark for building a more accessible Web. While WCAG 2.0 has been designed and written to be far more testable than its prior version, there are still situations that require more technical evaluation and focus on a usable, and accessible, implementation. For example, accessibility testing of educational content and assessments is a complex art and cannot be achieved only by following WCAG guidelines. WCAG alone is not sufficient to guarantee website, content, and report accessibility and not sufficient to address all of the issues encountered by users with disabilities.
Irfan Ali accessibility engineer from Princeton, New Jersey
This paper provides details about some challenges beyond the WCAG guidelines and success criteria and presents recommendations with the goal of producing a truly usable experience for all users, including those who have disabilities, while simultaneously conforming to the WCAG standards. WCAG certainly provides useful guidance and associated techniques for building accessible content, but in the case of educational content, there are many stakeholders comprising a multidisciplinary team involved in design, implementation, and testing. In going beyond the guidelines, it is essential to ensure all multidisciplinary team members take responsibility for accessibility. Complex content and interactions may not have immediate accessibility solutions, nor have clear direction from the success criteria of WCAG. Multidisciplinary teams can leverage their subject matter expertise, experience, and creativity to reach solutions that achieve what we all strive for, web content or an application that works for a user with disabilities.
Irfan Ali is from Princeton, New Jersey and an accessibility engineer
The aim of this paper is to explain the benefit of thinking beyond the WCAG guidelines and being creative to develop a good accessible platform. Our focus is to include accessibility at the beginning of a project and make the accessibility of products the responsibility of each team member. Whether you are a content subject matter expert, a specialist in image descriptions, a user interface designer, web developer or a manager, everyone has a responsibility to do their bit to contribute to accessibility. This approach can make sure that products are accessible from the start, from inception to design to implementation to delivery, and don’t need to be retrofitted with accessibility features at a late stage. At ETS, for example, new development efforts incorporate accessibility right from the initial design process and will utilize iterative prototyping and usability studies of novel interactions (for which we have no existing accessible design patterns). The prototypes themselves are based on research and best practices, but when for example, we are faced with novel interactions such simulations, we often don’t start with a design, but instead seek to understand how a person with a disability would actually perform the real task, and then seek creative solutions to identify if there is a digital equivalent. We do our research with a diverse audience representing the target user population, and include focus group studies, and then specific in house or remote usability studies with end users with disabilities. End to end usability studies, in which target users will undertake a complete interaction with, for example, a graduate school admissions test. Usability studies are also key for informing members of the multidisciplinary team on what works (the wins) and what doesn’t (where did we get it wrong). It is critical to have all members of the team invited to observe the usability studies. Thus, in carrying out these studies, it’s not just researchers but developers, designers and other stakeholders who participate. It is also important to engage the study participants to listen to their comments, observe where and how they use our services- their location, physical space and preferred assistive technology. We also include people with different disabilities to address the diverse audience we serve. We ask people to show us websites or related products that work well for them and then ask them to explain the problems in products that do not work very well. These are activities that are fundamental to designing a quality user experience; involving people with disabilities helps ensure an inclusive and high-quality experience.
At ETS, we believe in creating a simple and clear design with well structured, minimal HTML, and testing it using accessible technology including Accessibility checkers, such as the WAVE toolbar. The Wave tool can quickly identify very basic errors, such as incorrect heading structure, missing labels, color contrast, skip links, skip targets and missing alternate text. We then make sure that the application is keyboard accessible and we make sure that we are able to navigate using keyboard only. Keyboard accessibility for general users and screen reader users can be different experiences, and we make sure that all the essential content is readable by screen readers and that the user is able to navigate all the landmarks and content using screen readers keys.
Applying WCAG intelligently is the key to accessibility, especially in educational content item types. Math item types, region selection, and drag/drop are a few examples where we need to be creative and move beyond the WCAG. We create custom selectable and de-selectable radio buttons for high-stakes testing assessments and examine ways to address drag and drop style interactions so that they work without inducing unnecessary cognitive load for the end user. Sometimes it may be as simple as replacing drag and drop tasks with simpler interaction methods such as multiple-choice radio buttons. Rather than trying to force a complex task to become accessible and usable, which instead result in something that is technically conformant with WCAG, but not usable in the real world, one needs to rethink the task into a more accessible and usable model that achieves the same goal. It is key to remember that it is the end user of your product, who may use an assistive technology that you are building for, not simply to create an application that meets a specific WCAG success criteria.