Announcing Accessibility Upgrades at CERA
CERA is pleased to share that we have concluded a two-year comprehensive auditing and improvement process of our website, ELSIhub.org, with the support of both the Stanford Office of Digital Accessibility and BlndSpt, a software development company based in Denver, CO. We implemented many changes, big and small—from enabling the optimal functioning of screen readers to increasing the color contrast on the website—to facilitate the full participation of users with disabilities. To measure the impact of accessibility upgrades to ELSIhub, CERA is comparing baseline to post intervention scores for ELSIhub.org as generated by the Siteimprove plugin in the Accessibility section. The Siteimprove Accessibility score ranges from 0 - 100 and measures how closely ELSIhub.org follows the success criteria of the Web Content Accessibility Guidelines (WCAG).
Our work on ELSIhub to date has improved its accessibility score from 80.4 in September 2023 to 93.3 in March 2024. This score surpasses the industry benchmark for education, 87.4. We are working with an external reviewer to create a specific statement of compliances with the WCAG guidelines (which is called a “Voluntary Product Accessibility Template” or VPAT) which will be posted on the new ELSIhub accessibility and usability page.
Additionally, we upgraded CERA events with live captioning and American Sign Language (ASL) interpretation and added captioning to our video recordings. All CERA speakers now receive instructions on making accessible PowerPoint presentations and CERA staff have been trained in the creation of accessible web content, including writing alternative text for images and creating accessible documents. We are also pleased to share our new curated resources and guidance for those who want to incorporate accessibility into the processes of their organization or research project.
Kevin P. Murphy, a Digital Accessibility Consulting Engineer in the Office of Digital Accessibility of Stanford University IT, started us on this journey by providing the first site audit of ELSIhub.org. In this interview, he shares advice for getting started on your own web accessibility process.
CERA: Could you please tell us a little bit about what you do?
KM: I started building university websites in 1996 for the CSU Northridge Department of Music, where I was a graduate student at the time and running the electronic music lab. This was just a few years after the internet was released to the public domain. Since then, I've worked for Moorpark College, Western Nevada College, and the University of Nevada, Reno, along with a few forays into private industry and teaching at other institutions.
Specifically getting into digital accessibility happened while working as the web developer for Western Nevada College. I was aware of the federal regulations for websites (Section 508) and had worked on my own towards meeting those regulations. However, one day I attended a conference and casually mentioned something about Section 508, and no one in the session knew what I was talking about. That's when I realized I was, very unintentionally, the expert in the room on the subject, and that kind of scared me because I thought I was behind the curve. I took it upon myself at that point to learn everything I could about accessibility and apply this knowledge to the work I was doing, as well as educating as many people as I could on the subject.
A few years back, this led to me leaving higher education for a digital accessibility company where I worked with a wide variety of clients on making websites accessible. After a few years, however, I felt drawn back to higher education, which is when I ended up at Stanford University.
My job here at Stanford is primarily threefold. As part of University IT, we audit websites and web applications for accessibility. This includes most large-scale systems, such as those for class registration, parking permits, ordering food, and more. Basically, any system that can be used by multiple people at campus could be tested by myself and my team (as opposed to individualized accessibility documents, like classroom materials. Those are handled by a different group at Stanford). Sometimes, these are systems that are already being relied on; other times, this is part of the procurement process when deciding which vendor to choose.
The second responsibility is to help educate as many people as I can on accessibility issues and solutions. This includes teaching individual developers and groups of content creators, or pursuing other educational opportunities, such as writing for a broad audience.
Finally, I am also responsible for managing the university's accessibility monitoring platform, which for our institution is Siteimprove.
CERA: Why is the work you do is important to you?
KM: Twenty-six percent1 of the population has some sort of disability in the United States. This is a huge population, rather than a fringe group of people. At the same time, over 96%2 of websites have accessibility barriers. Almost everything is now online: applying to jobs, ordering pizza or groceries, doing banking, or just about any other aspect of modern life. It is virtually impossible these days to exist in society without being online.
Imagine being blocked from buying groceries online because of your race. Or being unable to get an education online or in person because of your gender. These simply wouldn't stand and would be clear violations of numerous laws. Discrimination is discrimination, but in terms of people with disabilities, it's more 'acceptable' for society to discriminate against them. What would your life have been like during the pandemic if you did not have access to the internet? That's exactly how it was for many people with disabilities. In short, accessibility is a civil rights issue, but we are behind in addressing it.
CERA: What would you say to someone who hasn’t really thought about making their website accessible to make them aware of its importance?
KM: As I said, accessibility is a civil right. At the basic level, addressing accessibility is “doing the right thing.” On a more practical level, there are many other reasons for addressing the accessibility of your website. There are already many cases where federal grants require an accessibility commitment. Also, since 26% of the population has a disability in the U.S., imagine how many customers, students, job applicants, etc. you are missing out on if your content is not accessible. Another huge reason for getting into accessibility is what is known as the 'curb cut effect', named after the cut in intersections that are made for people in wheelchairs. Although curb cuts are designed for wheelchair users, they are not the only ones who use and benefit from those curb cuts. Parents with strollers, delivery drivers with hand trucks, and kids with bicycles all use those curb cuts too. In short, the things we do for accessibility are not just a benefit for people with disabilities. In terms of websites, adding captions for the Deaf/hard of hearing individuals also helps people whose primary language is something other than English. Making your website work for low vision users that need to zoom in on the content means it works for mobile users as well.
And one of the biggest benefits is Search Engine Optimization (SEO). The Google bot that comes and scans your pages is blind, deaf, and can't use a mouse. If you are building an accessible website, you are also building an SEO-optimized website. My guess is that there is about 90% overlap between accessibility and SEO for your site.
Finally, in 2023, there were 4,605 lawsuits filed about websites that were not accessible. Being on the receiving end of one of these lawsuits is not a position you want to be in. Both the Department of Education (DoE) and Department of Justice (DoJ) have their own versions of an Office for Civil Rights (OCR). You want to stay off their radar as well.
CERA: Can you give our readers any sense of what accessibility barriers you commonly see during website audits and what challenges these barriers present to website users?
KM: One of the most common accessibility errors is keyboard access violations, yet these are some the easiest to test for and fix. Not everyone can use a mouse, which includes people with arthritis, people with profound motor disabilities (such as the late Stephen Hawking), people that are visually impaired, and many more. All these groups use some type of keyboard or keyboard simulator (e.g., a switch device, eye tracking device, sip/puff device, etc.).
To test your website for keyboard access, simply put aside your mouse and try to navigate using the keyboard, mostly with the TAB key (move to the next actionable element) and the ENTER key (activate that element). There might be cases where you need to use the arrow keys or spacebar, but those are the most basic. Can you navigate to every element and activate it? Can you see what element you have navigated to, visually?
Another major area for improvement is that visual elements need to have a text equivalent for screen reader users. Often a button will be added, such as a Facebook icon that links to Facebook, but a text version of the icon is not provided. For a screen reader user, the Facebook icon just becomes an unknown button. The same is true for images, which require a text equivalent (also known as "ALT Text"). This includes charts and graphs, which must be fully explained.
There are numerous tools that will expose the image ALT text or button text. One of our favorites is the ANDI tool from the Social Security Administration. Use that tool to expose the text equivalent to elements and make sure that what a screen reader is presented is the same as what a visual user is presented with.
CERA: The Web Content Accessibility Guidelines (WCAG) seem to be the standard that is commonly used. How were they established? Why are they described as “guidelines” (as opposed to rules or standards)?
KM: In short, the federal government amended the Rehabilitation Act of 1973 in 1998 to include accessibility standards and mandated accessibility compliance, but these only applied to federal websites. There was also debate about whether it applied to organizations that receive federal funds. The internet community and industry saw a need for guidelines for everyone else, so through the World Wide Web Consortium (W3C)—the organization that defined what HTML is—the WCAG standards were adopted in 1999. They were significantly revised and published in 2008 (WCAG 2). Because this was a voluntary initiative, WCAG is not legally binding, but rather guidelines and best practices that people should follow.
However, numerous rules and regulations do refer to, or closely follow, the WCAG standards—including the more recent update to Section 508 in 2018, the European Union standards, and more. While WCAG is still 'voluntary' here in the U.S., it is referenced by many state digital accessibility laws, and it is pretty much accepted that you need to meet these standards. Also, not meeting these standards is the basis for most lawsuits. I also need to point out that a lot of people think meeting these standards is the goal, and it's not. It's the bare minimum.
CERA: There are three levels in the WCAG guidelines, A, AA, and AAA. Can all parts of a website be upgraded to the AAA level? If not, why not?
KM: Level A are the easiest standards to meet, and meeting Level A will rarely change how your site looks. The AA standards are a bit harder and could affect what your site looks like, while the AAA standards are ones that will for sure change how your site looks and are the most difficult to meet. Almost all organizations, including Stanford, require the A and AA levels to be met, but not the AAA standards.
CERA: Some of our readers may have recognized the need to increase the accessibility of their website but are not sure how to begin the process. What advice can you give them?
KM: When remediating your existing website, it's important to learn to prioritize and not get stuck on the idea that you must fix everything all at once. Start with things that will have the biggest impact across your entire site. You should always start with remediating the template files and get that aspect of your website fixed before you worry about individual pages of sections.
For the rest of your pages, start by figuring out which ones are priority pages, and which are not. Obviously, your home page is highly trafficked and should be a priority. What other pages are critical to your site? For example, if this is an online store website, make sure the entire checkout process is fully accessible, from putting things into the cart to making payments.
One of the ways to do this is to use Google Analytics to help with prioritization. A story I like to tell is that at a previous university, we were debating how we were going to handle making numerous old issues of our alumni magazine accessible. These were fully inaccessible PDF files that dated back into the 70s and would have been a major effort for us to fully remediate. We couldn't come up with an approach that would work. Eventually, I had the idea to look at the Google Analytics for that section and see what issues we should be prioritizing. As it turns out, the entire archive section of our site got only 30 page views in an entire year. We ended up taking the entire section off the website with a note saying if you wanted an old issue, we'd send it to you. No one ever asked for one in the time I was there.
When it's time to rebuild your website from scratch, start with accessibility in mind from the beginning. If you are working with an outside agency, make sure accessibility is part of your contract and that they agree to solve issues uncovered. Don't let them treat accessibility as a "feature request" – something that is an add-on to existing functionality, rather than baked into the website design. Look for information on their website about accessibility. If I'm ever evaluating a third-party developer, I check the accessibility of their home page before I sign a contract with them.
CERA: How much time should anyone planning an accessibility remediation plan expect for it to take?
KM: This is the wrong approach. Accessibility is a process and not a project. It's a common thing for groups to approach accessibility as something that you will add on at the end of a project. "I've built my website and I'm launching it in 3 days, so now I'll address accessibility." Imagine if you tried to build a building that way, "Oh, we will think about adding wheelchair ramps after the building is built."
Instead, think of this as a process. Accessibility is integrated into everything you do. Adding a picture to your page? Write the ALT text when you add the picture, and don't try to come back to it later. When it becomes just part of the process that you do when you create anything, then it's not a big task. Another phrase I use all the time is "progress not perfection". Your website will probably never be 100% accessible and that's OK. What you want to do is make your website better today than it was yesterday.
CERA: How much does a full website remediation cost? Are there any low-cost solutions that still make a big difference to website users?
KM: Many of the accessibility issues that are present on a site can be fixed with just a few lines of code changed. For example, color contrast issues (text should be 4.5:1 against the background color) can often be fixed for an entire website by making one change to one value on your site's CSS file. Simple changes can have a lot of impact. Otherwise, there are no generalizations that you can make about effort. It's possible that a very large, inaccessible site can be made accessible with just a few fixes. On the other hand, a small site that was built completely inaccessible could require a complete rebuild. We see both scenarios often.
CERA: What should organizations who have completed an accessibility remediation consider doing in the future to ensure that they stay in compliance?
KM: There are several things that organizations can do. First is constant monitoring/testing of pages. At Stanford, we use a tool called Siteimprove to constantly monitor our websites for accessibility issues and currently scan 1,750 websites and almost 1.5 million pages. However, there are limitations with tools like this—namely, that at best they can catch about 30% of the different accessibility errors on the site. So not all accessibility issues are addressed, but it still reveals an important piece of the puzzle.
Next is consistent training and education of staff. This process not only includes developers and content creators, but also managers and other people that set schedules and expectations. "We don't have the time or budget to deal with accessibility" is often simply untrue. Another thing that seems to show up on most DoE OCR remediation requests is to have a simple way of contacting your accessibility team when an issue comes up. This is why Stanford requires a link to an Accessibility Page on all pages, which has an easy way to contact our team and report an issue or request an accommodation.
CERA: What resources do universities typically offer to support accessibility efforts on their campus?
KM: Typically, accessibility efforts on large campuses are divided into two distinct groups. The first is a group that works directly with students to provide class materials in an accessible format. At Stanford, this team is called the Office of Accessible Education and other institutions will call this something like the Disability Resource Center or numerous other names. If you need your textbook converted to braille, this is the group you would go to. Almost every institution will have a group such as this on campus.
Then, many institutions will have an office like my office, the Office for Digital Accessibility (ODA). We don't typically work with individual students or staff, but rather are more concerned with the large-scale systems, such as class registration, parking permits, and more. Our office is small (only five people to support the entire campus), so we can't fix everything for everyone. Our job is to check systems and give remediation advice, training, and expertise so that the developers can then fix the issues.
My previous institution didn't have this office but instead had an ad-hoc committee that did this kind of work. The community college I worked at had me and no one else. So, your mileage may vary. Beyond that, some large departments may have a dedicated accessibility person, but that is very rare.
CERA: What training videos or online web accessibility guidance would you recommend to individuals and organizations beyond Stanford?
KM: Fun fact: I've never received a formal education in technology. And the same is true for many of the people I work with. None of this information is secret, really—it's published on numerous websites, there are a lot of free resources, and many people like myself are always happy to discuss accessibility issues when we are able.
A few of the websites and resources that we recommend frequently include:
- WebAIM: WebAIM is available through Utah State University. They have created the widely used Wave tool for automatic accessibility checking and host numerous articles and tutorials.
- LinkedIn Learning (formerly Lynda), Udemy, or others: You might have a subscription to these or others through your local library.
- Stanford University IT: Office of Digital Accessibility: We have a growing number of articles and videos on our website, with a major overhaul coming over the summer of 2024.
Your institution may support your access to Deque University or something similar (other accessibility companies have their own versions), or you might be able to acquire a paid product like this.
CERA: Is there anything else you would like to share?
KM: I would just reiterate a couple of the things I mentioned earlier:
- Progress not perfection: Don't be so panicked about getting everything right that you fail to start simply making it better. I've also heard this phrased as “Don't let perfection be the enemy of good.”
- Process not a project: Incorporate accessibility into your process rather than leaving it as a big project to do at the end. When you do that, it’s not a huge undertaking.
Finally, disability is something that everyone will experience at some point in their lifetime, if you live long enough. From a simple broken arm to age-related hearing and vision issues, this will affect you at some point in your own life and your family and friends as well. You can't fix the whole internet, but you can positively affect your little corner of it.
The Center for ELSI Resources and Analysis (CERA) is committed to ensuring the full participation of users with disabilities. Visit our dedicated page for more information about accessibility and usability at CERA and to access our latest resources and guidance. If you are looking to start incorporating accessibility into your organization or research project, read our Getting Started with Creating Accessible Digital Content guide or browse through our curated set of resources for tips and guidance on creating accessible web content.
