Every movement begins with a moment.
At Moxie, our technology teams works closely across disciplines to deliver a better quality product for our users. Testing is not left solely to QA nor is it wrought exclusively at the end of the development lifecycle. As the digital landscape evolves and brands aim to cater to an increasingly large (and segmented) user base, Web accessibility testing has come to the forefront of design/UX/development/QA and delivery.
Web accessibility testing falls under the usability umbrella. It takes into account users with disabilities and how they interact with the Web across desktop, mobile and tablet properties. Accessibility and usability coalesce when we consider how easily humans can use a website and how design and implementation initiatives can be improved. For our Internet Sales & Operations (ISO) team, accessibility means a website should be designed for ease and efficiency regardless of user ability. Moxie developers must convey digital information intuitively so that HTML users can access content and accomplish their goals across Web browsers and devices. To achieve this aim, we ask ourselves a variety of key questions.
Considerations for Accessibility Coding and Testing
At Moxie, we do more than (manually) click around the websites we’re constructing to ensure we’re making them “accessible.” Our development and QA teams are leveraging sophisticated tools and APIs to render our work WCAG2.0 AA Compliant, regardless of the project’s scale and scope. We test across environments both before and after Development Peer Reviews. We test our HTML5 and our CSS3 not just for tags, navigation and keyboard interaction but also for items like structural markup and color contrast errors.
Accessibility Testing Tools
There is no “one size fits all” approach when it comes to accessibility testing tools. Establishing a process, conducting manual testing and employing a variety of tools will certainly help set you up for success. And while there is a wide array of tools out there, here are the ones we currently use at Moxie.
Testing in Four Phases for a Singular Result
Moxie’s accessibility testing process spans four phases and uses all of the tools listed above. This level of rigor ensures we’re identifying and solving for optimal usability and delivering a universally exceptional user experience.
Phase 1 – Color Contrast
The first phase is to check against color contrast. This is done through the creative department. The reason for this is to prevent having to rework comps after development has gotten too far along. This can lead to lapsed deadlines and scrapping code all together.
Phase 2 – Automation
The next phase takes place during development. At Moxie, not only do we feel that you should build early and build always, but you should also “test early and test always.” To achieve this without greatly impacting development time, we turn to automation. Once a developer is ready to send code for Peer Review, they use our accessibility automation scripts to test against the Nu HTML Checker and Tenon.io. This step allows the developer to fix any accessibility issues found early on before heading to the subsequent phase.
The automation scripts produce reports for the developer and team to review and store. This gives us a way to double-check ourselves throughout the entire build process. When the developer submits code for Peer Review, that reviewer is able to then verify that the code being merged is valid and compliant.
Phase 3 – QA
The third phase integrates with the QA team. Additional accessibility testing is conducted both with automation and manual testing. In this phase, the automation script uses AChecker to sweep the code for anything Tenon.io may have missed. In the manual testing, the team will test for issues related to keyboard interaction and screen reader efficacy. These are items that either cannot be tested against through automation or have a low success rate in doing so.
Once the additional testing has been completed and all fixes are committed, the QA team will use the accessibility reports to verify the pages are ready for production release.
Phase 4 – Report Packaging
The final phase of the process performs report packaging for production. The saved accessibility reports are combined and packaged for distribution to the client and stored for future use. This gives our clients peace of mind that Web accessibility has been thoroughly tested and that the code delivered remains compliant.
The Constant Evolution
As technology and its capabilities continue to advance and evolve, the tools and standards for accessibility will improve and change as well. The plan and process that work today may not be optimal tomorrow. Just like other areas of development and QA, Web accessibility testing will need to be maintained and constantly sought out for new learning. Remember, there is never a silver bullet solution, and one size definitely does not fit all. Understanding your clients’ needs and testing early and often will be your keys to success. As the landscape evolves, so must your company, your knowledge and your tool set.
Kevin Smith is an Interface Architect at Moxie. When he's not working on new processes to help the development team or diving into new technologies, he enjoys drawing, painting, home improvement and traveling.
Vijay Mahoney is the Senior QA Manager at Moxie. He has 10+ years’ experience working with Fortune 500 clients and InternetRetailer Hot 100 vendors in the e-commerce/digital marketing space. When he’s not staring at monitors, you can find him hanging with his hound dog, Covington.
PLEASE PROVIDE YOUR INFORMATIONTO DOWNLOAD THE PAPER.