7 accessibility questions for your outside web developer

Is your organization seeking or working with a third-party web developer to build a website, software application or mobile app? If so, you need to know whether they have the skillset to build user experiences that work for people with physical challenges, including those who are blind, have low vision, are hard of hearing or have motor impairments that affect their ability to use a mouse.

But how can you be sure if developers who operate outside of your organization are following digital accessibility standards? You could simply ask your developer if they are capable of creating accessible websites or applications. Or you can take what they report on an RFP at face value. However, those approaches are both risky and potentially very costly gambles.

Fortunately, there’s a better way to vet developers. By approaching them with a set of focused questions — and by knowing what information to listen for — you’ll be better equipped to gauge the true breadth of any developer’s accessibility skills. From there, you’ll be able to build a partnership with your web team based on trust.

Here are 7 questions to ask your outside developer to make sure they are building digital experiences that work for all users:

One: What accessibility standards do you use to guide your development process?

You’re hoping to learn whether the developer is familiar with the Web Content Accessibility Guidelines (WCAG). These guidelines, which are designed to make web content accessible to individuals with a variety of disabilities, are published by the World Wide Web Consortium (W3C), an international community of member organizations and full-time staff.

Ask your development firm if they are familiar with the 4 principles of WCAG (pronounced WUH-cag), which are to build web content that is 1) perceivable, 2) operable, 3) understandable and 4) robust. It’s a good sign if they know these principles (often referred to by the acronym “POUR”). If they do, ask what level of accessibility they aspire to achieve. Most companies who are publishing accessible web content aim for what is known as level AA compliance with WCAG standards. This consists of a set of 12 “guidelines” and 38 “success criteria.” A good developer should understand how WCAG is organized.

Two: What screen readers do you test with (and when do you test)?

This question will help to clarify two things:

• First, it will tell you if their developers are using assistive technologies as part of their testing procedures.
• Secondly, it will tell you if they are testing their work throughout different stages of the design and development process, which is a best practice

Listen for opportunities to ask your developer about the importance of using screen readers as they relate to testing specific functionalities, such as proper labeling of various HTML elements, reading alternative text for images and announcing errors as they appear when filling out a form. Ideally, they’re using JAWs, the most common screen reader that works on the PC platform, and VoiceOver, a screen reader built into the Mac OS.

Three: Do you include users with disabilities in your user testing?

Good developers should always involve the target audience in testing the website or app prior to releasing it to the wider public. This process enables developers to identify usability issues that are not discovered by expert assessment alone. User testing should be done as early as possible in the design and development phase, as bugs discovered in the design phase are much cheaper to fix.

However, it’s also important to test digital experiences with end users further down the development process. This is especially true when testing with individuals with disabilities, because a lot of accessibility issues are ultimately found in the functioning code and not in early prototypes. So the first question to ask is whether the developer tests their work with users and when? Then ask if they include users with disabilities in their testing, and how that fits into their overall testing strategy.

Four: How is accessibility accounted for in your quality assurance phase?

Many development organizations have quality assurance (QA) staff whose job is to walk through the primary use cases of the product while documenting any bugs they encounter along the way.

So when asking your developer this question, listen for a response that makes you feel confident that they have a way to 1) test for accessibility and 2) log accessibility defects.

For example, they should either have testing protocols for using just the keyboard to access all functionality or have a way to check the quality of the developer’s code using an HTML ‘validator’ (ask what they use). In their bug-tracking system(s) good developers should also have a way to log a bug as an accessibility issue. Ideally these systems have guidance for their developers (perhaps linking to WCAG ‘sufficient techniques’) to help them remediate the issues that are uncovered by QA testing.

Five: What are the roles and responsibilities in your organization for ensuring you are building accessible products?

Creating accessible products is a team game. The responsibility does not lie with one person or even one department. For example, product or program managers should be responsible for ensuring that accessibility is included in requirements documentation (sometimes known as BRDs or FRDs). Designers should be choosing colors from pallets that will ensure sufficient contrast so that content can be easily read. And developers should know about the importance of using ‘native’ HTML components (such as select boxes), which have built-in accessibility versus piecing together ‘simulated’ controls that require additional enhancements to make them fully accessible.

So start this conversation by asking what the various roles are in the development team and ask how each is held accountable. You may also want to ask if the people filling these roles have received training in accessibility or whether the job requires certain skills in accessibility.

Six: What have you done to make your page templates, components and / or JavaScript libraries more accessible?

Most development shops have code or component libraries that they pull from when piecing together web applications. They also often have page templates that they use for different types of websites. This allows the developer to be as efficient as possible.

Having these libraries also provides an opportunity to ensure that the developer’s set of ‘building blocks’ are of the highest quality. Therefore, developers should have spent a good deal of time testing these components, debugging them and making sure they are accessible to assistive technologies like screen readers. So ask your developer whether or not they build from a set of components and, if they do, follow up with questions about how they vetted them for accessibility.

Seven: Can you show me a website that you’ve built that is accessible?

Perhaps the best way to determine if your developer is following web accessibility standards is to ask them for an example of a website that they have built or to provide a testimonial from another client. As the old adage goes, the proof is in the pudding. If they hesitate when you ask, it’s unlikely they have much experience. But if they do provide an example of a website that they’ve built to be accessible, don’t just accept it at face value. Vet it. This is easier than it sounds.

The first thing you can do is use one of the many automated accessibility testing tools, such as Tenon, to scan the web page for accessibility defects — just don’t be alarmed if it finds dozens of ‘errors’ or ‘warnings,’ as most sites have them. The key is to compare your developer’s website to similar sites. Also keep in mind that automated testing will only uncover about 25% of the accessibility issues that are present.

There are also a number of quick tests that you can do manually, which don’t require you to be an expert in inspecting code or using a screen reader. You can find a list of these ‘easy checks’ on the WCAG website. Many of them are as easy as using the tab key to navigate the site or clicking on form labels to see if a blinking cursor is brought into the corresponding input field.

You’ve asked the questions – now what?

If you’re left with any lingering questions or doubts, consult our accessibility experts. As leaders in the field of assistive technology and web accessibility assessments, the Perkins Access team is here to help guide you through the process with the goal of creating a more accessible world for us all, both online and off.

Contact us to learn more about the digital design process. We’ll tell you exactly where you stand and, importantly, how to go about attaining your accessibility goals.