In early 2017, I joined Crema as their first Quality Assurance Analyst. Drawn in by quirky YouTube videos, a results based culture, and the office being 217 steps from my front door, I ended 5 years of working from home. Three hours into my first day, I filed my first bug--an accessibility issue with a form.
:x: Correct Tab Order of Entry Form
Steps to reproduce:
- Open the Business Entry form at /business
- Enter a Business Name
- Tab through the fields and enter data
Expected results:
Can tab through each field and enter data
Actual results:
Can tab and enter through first 3 fields.
Tabbing out of 3rd field goes to the navigation menu and continued tabbing cycles through items on the page, through the first 3 form fields, then back to nav.
At that point, there were only a few issues I knew to look out for: tab order, Apple’s VoiceOver being able to read the page, and alt text needing to be set for images. My lack of accessibility testing knowledge only felt smaller when I had to plead the case to our developers (and then the client) on why this was an issue that deserved a fix.
This would be the story of 3 differing priorities constantly (and frustratingly) at odds. In the spirit of Constant Improvement, however, this is the story of how we started digital accessibility stewardship together.
I am a firm believer that quality is an ‘everyone’ problem. Quality of a product starts with sales and ends with testing and delivery. Every person at our company has a hand in quality assurance. This is true even when there is staff dedicated to quality roles.
Thinking about equal access and accessibility standards, I found myself coming back to that same belief but replacing quality with accessibility. This gave me the personal push to believe that, as a testing leader, I could drive a shift through Crema, and that digital accessibility compliance is an everyone problem.
In the last year, we’ve been mindful to design and develop for accessibility. We try our best to hit AA. All roles have tools to find what may be overlooked. When accessibility bugs are logged, we can point to the specific Web Content Accessibility Guideline we leave unserved.
Codified by the testing team, we’re sharing and learning together across the entire company. We do this because it aligns with our closely held values of generosity and constant improvement, and because we feel morally obligated to be accessible and inclusive.
We are constantly looking for new ways to improve, learn, and build to web accessibility standards. I’m sharing our first steps below, but I would love to know any tips, tricks or tools you use for accessibility within your product teams.
Our Information Sources
- WCAG - The main source, W3C Web Content Accessibility Guidelines document outlines 3 levels of adherence to accessibility and what that means.
- A11yWeekly - David A. Kennedy’s weekly roundup of accessibility news and links. I’ve found so many clarifying thoughts and positions through this newsletter. It’s a must read.
- #a11y - this hashtag on twitter is full of thoughtful conversation around accessibility and accessibility testing
- Designing for accessibility is not that hard by Pablo Stanley - UX Collective is rich with accessibility articles, but this piece breaks the process down into an actionable guide anyone can follow.
- Udacity Web Accessibility with Google - This free course is a great process class for front end developers, but we recommend everyone sign up and watch the first lesson to understand the connection of accessibility and assistive devices.
The Tools We Use
- WAVE Accessibility Evaluation Tool - the gold standard of accessibility testing tools and accessibility checking. WAVE is our first pass tool for testing.
- Color.review - A color contrast checker that lets you see background and foreground contrasts
- Accessible-Colors - Another color contrast checker that lets you set your level of WCAG compliance to verify against
- Storybook - The accessibility checking add-on allows easy review of ourReact components for issues.
- Google Lighthouse - Built in to Chrome, Lighthouse is an easy way to quick, single page accessibility testing.
- Transcriptive - Accessibility is not just for client work, and this plugin ensures our video content has solid captioning
- Screaming Frog - Spider for reviewing site which helps identify alt text issues
- SEMrush - More sitewide review for alt text and other issues
Our Internal Processes
- #a11y Slack Channel - Everyone is invited to join and share information
- Dogfooding on our own website - Crema.us is our best playground, and we’re constantly making increment improvements to use what we’ve learned
- Internal Chats - Our internal craft teams get together regularly to share learnings, and this is our best area for training in accessibility.
