Team Members
Digital Design Team:
Sean C. // Riley J. // Minjae L. // Emma P. // Amy S.
Tools
Google G Suite, SiteImprove, Squarespace, Windows Narrator, ZipBoard
Skills
Accessibility, web development, user research, user testing, presentation
Prologue: The Problem
Empowerment Through Integration (ETI) is a non-profit organization that focuses on inclusion and empowering those with disabilities by helping them be their best selves. They have struggled to keep their website as accessible as possible for their users, and have put my team and I up to the task.
Chapter One: Identifying and Solving Non-Compliance
SiteImprove & WCAG 2.1 Compliance
SiteImprove is a browser extension designed to find accessibility errors on websites. It follows Web Content Accessibility Guidelines (WCAG) to sort through and review site content, displaying three levels of error: A, AA, and AAA. Level A describes the most basic level of accessibility.
Our team primarily used SiteImprove to identify and tackle the errors found on ETI’s website to keep it compliant with WCAG 2.1 (the most up-to-date compliance level).
Key Features Breaking Code
These were some of the key features throughout ETI’s site that repeatedly needed adjusting:
- Embedding descriptions for videos/images
- Creating distinguishable links for each of the linked webpages
- Embedding elements (like checkboxes, descriptions + their fields) together
- Creating focus on certain buttons (highlighting when they should be pressed)
- Fixing color contrast of website and multiple contrast filters from the Userway Accessibility Menu
- Changing wording of some buttons so they are understood properly
Chapter Two: Reporting Unsolvable Errors
Not all errors could be fixed
Multiple errors were linked back to the site’s code, and since ETI’s website was built using Squarespace (and because of our own timeframe), we were unable to alter any HTML, CSS, or JavaScript. The errors we could not solve were shown, listed, and defined to our clients through a ZipBoard file.
** ZipBoard is a tool often used to report and give feedback for web pages, lines of code, etc. It is a collaborative presentation tool that worked fairly well for this project.
Chapter Three: Testing for Accessibility
Our Testers
We defined our user as a young adult who browses the internet with the aid of tools like screenreaders.
Since we did not find volunteers who fit this criteria, we visually impaired our volunteers (with a blindfold) and had them navigate the site using the Windows Narrator screenreader.
We tested five participants of varied backgrounds.
The Results
We had participants navigate around areas our team improved, focusing on their usability and readability by the screenreader.
Testers and the narrator were able to successfully navigate around these features. In a small test done with the original version of the site, the narrator was unable to understand video/image descriptions, checkboxes, and input forms.
The Finale
Our final deliverable was the finished website and the ZipBoard file. We were able to help our clients and their users have a smoother experience on the ETI website by successfully improving multiple areas that had previously broken accessibility guidelines.
Epilogue: Utilizing Accessibility
I believe all websites should utilize accessibility standards to some extent, especially after seeing how difficult it may be for disabled folk to navigate something so common in our everyday lives. While many websites do implement accessibility features, they are often not up to code and contain more errors than one would expect. 49 billion Americans have a disability, yet 92% of popular websites fail to address basic accessibility standards.
