Skip to main content
At a session during the last year’s CSUN conference, someone asked, "Why don’t the vendors build all of their products so that they’re accessible?". In attempting to answer this, we came to several important realizations. Clients and vendors may both need an education in what accessibility entails. Content authors may need detailed information and training. Finally, working together with your vendor can result in a long-term commitment to an inclusive experience. Over the last several years, Primacy has been building accessible websites for clients in a variety of industries, including health care, higher education, and finance. We had been following “best practices” for a long time. However, attaining WCAG 2.0 A, AA, or AAA compliance requires more time, effort, and expertise than most developers get during their education or initial training, unless there is a specific focus on accessibility practices and requirements. Accessibility is iterative – it’s a moving target. Developers and testers can always find some point that needs improvement. The agency needs to be very clear on that with the client: there’s no such thing as a perfectly accessible site. However, we always strive towards perfection. There are several reasons why apps and widgets are not always accessible out-of-the-box:
  1. High cost of development/testing/maintenance
  2. Lack of demand for accessible products
  3. Lack of expertise on the part of developers, testers, and marketers
As far as the high cost of testing and developing an accessible product, a good part of that is due to the education that’s required, along with the testing. In our agency, for example, thoroughly testing a site for accessibility can double the cost of QA. Not only does the site require testing across our entire base browser set, we then have to test it with keyboard only, 2 screen readers on two more desktop browsers, and 2 different mobile screen readers. Each iteration finds different bugs – sometimes a feature will work perfectly with one screen reader/browser combination and be absolutely broken on another. Due to budgets or lack of education in ADA requirements, there has historically been a low demand for accessible products. However, as the internet matures, an increasing number of lawsuits with outcomes requiring accessibility accommodations has increased the visibility of the need for inclusive design, with the number of federal accessibility lawsuits growing from 57 in 2015 to 432 as of this writing in 2017. Even my father is familiar with some of the more recent lawsuits! This is a man who regularly gets mad at his computer and throws it across the room in frustration when he can’t find the shortcut for his web browser.  While we all wish that organizations would build accessible products for humane reasons, the current reality is that litigation, or fear of litigation, is driving much of the current demand. Why is there a lack of expertise in developing accessible products?  The answer to this is complex. When learning to code in HTML, many developers learn the basics of some ARIA roles and landmarks, but they don’t focus on them. Then they go and build sites where the requirements are simply that they look pretty. For example, heading levels may be there for aesthetics only, or the client doesn’t like having a keyboard focus indicator, and the developer removes it. Why would they do that, you ask? Some clients think it’s ugly, and they don’t understand the purpose. So the developer learns to remove it before being asked, or testers learn to ask for it to get removed. Developers new to accessibility need to learn to resist all those bad habits before learning the good habits and best practices that make inclusive builds go smoothly. In order to successfully build and launch an accessible product, there must be a partnership between you and your vendor. How do we build this partnership? First of all, and most importantly, accessibility needs to be included during the initial planning phase of a project. Nearly any design can be made accessible, as long as the designers and developers know from the outset. In fact, for accessible projects we even include content author training in the proposal. Content authors create or implement elements that affect accessibility of a site such as forms, alt text for images, or body content with its associated headers. Even though each of these is important to the accessibility of a site, the client may not understand what their role will be in maintaining the desired level of accessibility, and education can be critical to the success of the project. Providing training and ongoing support will build on the initial client-vendor partnership to create a lasting relationship. Coding the website using inclusive design principles at the outset is only a part of the solution; the accessibility must be maintained throughout the content development and future enhancements as well. This may require shifting the client’s outlook, encouraging them to build empathy and understanding throughout all levels of the organization. Existing inaccessible content may be difficult to remediate, including branding, image and video libraries, and legacy PDF files. The client may have a content management system that makes it difficult to include some required elements for accessibility – for example, Drupal’s form error handling poses some challenges. We often build custom form error handling protocols and integrate them into our Drupal implementations. We try to understand our client’s audience to target the digital asset towards that audience, and focus on improving the features that will most benefit them. For example, for a geriatric audience we might focus on high-contrast text, zoom functionality, and keyboard accessibility. Budget allowing, we may bring all of those elements into WCAG 2.0 AAA compliance rather than focusing on perfect screen reader compatibility. Although there are certain elements and behaviors that should be/are typically accessible by default (tab order, zoom, focus indicators, etc.), collaboration is essential to the success of a project that is both accessible and that meets the client requirements. That is, collaboration not just between client and vendor, but also amongst client stakeholders as well as vendor resources. Resource: