Not Invented Here syndrome (NIH) is the guilty pleasure that tempts engineering teams into creating bespoke approaches to problems that have already been solved. Even having your eyes opened to the temptation doesn’t immunize you from it. So, how do you know whether a bespoke solution warrants the effort or if it’s just plain hubris?
In July, Pattie Reaves and I presented on practical approaches to accessibility for an audience of academic technologists at WPCampus in St. Louis. Accessibility requirements are taken seriously at most academic institutions. Colleges and universities have a commitment to make all of their resources available to students, faculty, staff, alumni, and community members regardless of ability. If they fail in this commitment, penalties can be steep. Therefore, developing approaches for continually testing accessibility is especially important.
Our talk focused on two approaches to accessibility: creating a new site and making an existing site more accessible. In both cases, we would stress the importance of monitoring accessibility as new code is introduced, as well as monitoring for accessibility problems in content entered into content-management systems.
Monitoring for accessibility during active development can be assisted by a number of developer tools, including the WAVE and axe browser extensions, the Firefox accessibility inspector, and Pa11y. Accessibility problems are easiest to catch and address before the code is committed to the production site, so all accessibility issues that can be identified during development should be addressed during development. We would also stress the importance of regression testing to ensure that code updates do not introduce new accessibility problems.
For existing sites that need accessibility updates, it is critical to perform an initial audit of the site to determine what issues exist, and how severe and prevalent they are. From there, organizations should establish a plan to address those issues on the basis of which are the most severe and which are the most prevalent. For example, it may be more prudent to fix a medium-severity issue that affects all pages on the site than a high-severity issue that affects only a handful. For monitoring accessibility fixes to code and content on existing sites, we recommend the use of Siteimprove, a platform that’s able to run routine scans on public sites and identify accessibility problems.
For more details, please watch our full talk below. Looking to improve your site’s accessibility and open it up to an even larger audience? Talk to us!