The web is undergoing a transitional phase. Because of new regulations, increasing legal pressure, and years of growing activism, web sites must now be accessible—usable by everyone regardless of ability. This covers a wide spectrum—the site must be legible even when the reader is color blind, the site must be usable even when the user cannot use a mouse or touch interface, the videos on the site must provide captions for users that cannot hear, and too many other cases to list. Arguably it has always been the case that sites should be accessible. But for a long time it was simply ignored. It was not a requirement for many businesses. Entire careers could pass without needing to know how to make a site accessible so few learned how, so few taught how, and few even knew that it was something that could or should be done.
The last transitional phase of the web was the move to responsive design. For a long time, all computers had displays with roughly the same dimensions. Sites were designed to fit that size and that size only. Most tools and techniques were based on the assumption of a fixed screen size. It was always possible to make sites that adapted to multiple screen sizes, but there were limitations and challenges, so few bothered. The smart phone and tablet came along and suddenly there was a wide range of screen sizes and web sites needed to work on all of them. This meant coming up with new tools and new techniques generally called responsive design. This meant going into old sites and retrofitting them, ripping out anything that assumed there was only one kind of screen and replacing it with something that would work on any kind of screen. It was a lot of work but the web is a better, more usable place because of it. Even though some sites still have not caught up, responsive is the new default.
The shift toward accessibility requires more care than the shift to responsive design. Instead of simply adapting to differently sized screens, now the site needs to adapt to different kinds of people all with different needs. The necessary changes are more complex, more invasive. Even finding what to change is more challenging since these issues are often invisible to the majority of people. Many of these changes help everyone, though, and when accessible is the new default, the web will be an even better, even more usable place.
As it is still early in the transition, many existing tools and techniques still ignore accessibility or have yet to correct all their accessibility issues. While new tools and techniques are being developed, it’s early. Much is still in flux. There are five major areas that require change:
The majority of web sites use content management systems (CMSes) such as Wordpress and Drupal but accessibility was deprioritized if not outright ignored in those systems and much work is still needed before they are compliant out of the box.
The web platform—the standards and technologies that are built into web browsers, such as Firefox, Chrome, and Safari—has issues that prevent or inhibit accessibility in some situations.
A lot of the free third-party code used to add effects or widgets to pages have ignored accessibility or required many extra steps to enable their accessibility features instead of making them the default.
Popular design choices and patterns that are either inherently inaccessible or hard to make accessible remain common.
Even entering content into your site can accidentally create accessibility issues if care is not taken.
Content Management Systems
CMSes provide an administrative portal for managing your content and themes that offer a lot of the structure of user-facing pages and their default styles. Popular CMSes have historically done accessibility relatively well. The bar was quite low, however. Recently, they have gotten much better as accessibility is now a high priority with most of them. These are large, complex pieces of software, though, so there’s still plenty of work left to be done. Their administrative portals, in particular, provide quite complicated user interfaces. Fortunately, these tend not to change much from site to site. Since everything is always in the same place and has the same purpose, they have been easy to fix up. The themes CMSes come with are simpler but are almost always changed and customized. They need to be accessible no matter how they’re used but not knowing how they’ll be used or modified makes that difficult. They tend to do pretty well now. Unfortunately, they are rarely used and it’s still possible to change them in ways that break the accessibility. Third-party themes do much worse and can still have many issues. There are some third-party themes with excellent accessibility but they tend to be indistinguishable from the less accessible ones.
The Web Platform
Even the web platform has had issues creep in over the years due to the prolonged lack of focus on accessibility. Features have been added that make it easy to do things that were once impossible or extremely hard that are, unfortunately, extremely hard if not impossible to use in an accessible manner. For example, after many years, to make responsive design easier, it is finally easy to reorder chunks of content visually, but this does not reorder the content for keyboard and screenreader users, making it effectively unusable except in very narrow circumstances. New standards and technologies to fill in accessibility gaps like this are being actively worked on, but it’s going to be quite a while before all the kinks are worked out. Once everything is worked out, it will take a while for browsers to implement these new features. Some people require special software to interact with the web browser to help them interact with websites and this software also needs to fully support the new features. Until these new standards are widely supported, there’s just going to be things that both can be done easily but cannot be done accessibly without a great deal of extra of work.
A great deal of third-party code can be included on a website and, with little to no additional work, suddenly, that list of images is a slideshow or those nested lists of links become a menu or a google calendar is embedded in the page or a request to subscribe to your newsletter that pops up when you scroll to the bottom of the page. Sometimes these are included directly by CMSes, their themes, or plugins. Very few sites on the web exist without at least one piece of such third-party code and some have hundreds of pieces. None of these are things intrinsically built into the web like, say, headings and forms are. Things built into the web come with a lot of accessibility for free. Whenever new features are created on top of the web like this, a great deal of care needs to be taken to ensure they are accessible. How much care depends on the specifics—certain things just need a little change here or there, some need to be torn apart and rebuilt from the ground up, and others just aren’t really possible to do in an accessible manner yet. Progress here is slow. Sometimes these can be fixed up from the outside with a little custom code, but this is not always the case. If not, this can mean buying an alternative, but that may itself still need accessibility fixes. It could also mean having a bespoke accessible, alternative created.
Many inherently inaccessible designs have become ubiquitous on the web: links without underlines and no indication of which has focus for keyboard users, fonts that are too thin, low contrast text, and slideshows with no controls among others. Some of these, like links without underlines, are copied from site to site without thought. Some, like no focus indication are due to a lack of education about the problems this causes. Many, like slideshows and thin fonts, are simply popular.
Even entering content into a CMS can cause accessibility issues. Images need alternate text descriptions, videos need subtitles, headings cannot be used decoratively, link text must sufficiently describe their destination instead of simply saying “click here”. Content is the hardest of all. Fixing code can correct thousands of pages at once, but content has to be gone through and updated one page at a time. How to fix it—how to even know that it needs to be fixed—and how to create content that does not cause any more issues, all require a great deal of training.
All of these accessibility issues need to be fixed.
Some may happen without intervention—CMS administrative portals and themes improving their accessibility, the web platform improving its accessibility defaults. Many require developer intervention—replacing an inaccessible menu system with an accessible one or just updating to a newer accessible version or changing some settings. Some require designer intervention—adding the additional controls that an accessible menu needs to be usable with only a keyboard into the site’s design, coming up with higher contrast colors and thicker fonts and link underlines that fit well with existing designs. Some require content creators to learn how to create and maintain accessible pages.
If you already have a site, it almost surely has accessibility issues that need to be fixed. There are many places these could come from. A manual audit is required to find the ones that are already there so that they may be fixed and training is required to prevent creating new ones. Automated auditing tools exist and are part of any manual audit, but automated tools can only find a small fraction of accessibility issues.
If you need a site created, you don’t want it to be created with accessibility issues that will need to be fixed. You need a team familiar with accessibility to avoid introducing them in the first place and who can train you so that you don’t inadvertently add any yourself
Morse Media can help you with your accessibility needs. We are currently working on a number of federal government websites that are legally mandated to follow accessibility standards. We can do the same for you by providing consulting, training, and accessibility-friendly design and development services to aid you through this transitional phase.