Baking WCAG into Web Design and Development

Too often, compliance with WCAG 2.1, to ensure web accessibility for people with disabilities, is an afterthought of the web development process. WCAG 2.1 compliance is a multifaceted endeavor, and when accessibility is incorporated into every phase of development, the result is greater efficiencies and superior outcomes.

Let’s look at the key phases of the web development workflow, and the advantage of keeping accessibility top of mind every step of the way. 

Planning and Wireframes

When planning and wireframing out a website project, accessibility needs to be considered at the very outset. During this phase, different functionalities of the website are flushed out, but accessibility tends to not be a top-of-mind. Here are a few practices to help keep the workflow on track for an accessible site and avoid unwelcome setbacks later in the process. 

1. During planning and wireframing processes, developers and site architects need to take notes and continuously question: “How is this going to work?”  “How will we make this component accessible?” This initial inquiry helps in planning and anticipating certain “pain points” or larger components -- such as a Calendar of Events -- that might take more time to be made accessible.
2. When planning out specific or custom functionality, it’s important to always stop and consider how it will be conveyed to a user who is visually or hearing impaired. 

Design

The design phase represents a whole new range of accessibility considerations that need to be taken into account. While color contrast is the most obvious issue, other issues such as focus styles or link text size are more likely to be overlooked. Below are a few of the many accessibility checks that need to be in place during the design phase. 

Evaluate elements of the website from the perspective of a person with color blindness, age-related sight loss, or other visual impairments. Can the text be clearly distinguished from the background image? Contrast checking resources and WCAG 2.1 provide support and guidelines for ensuring adequate contrast between the text and background elements.

Every website design should include a style guide that encompasses heading sizes, button styles, and other elements. Often, however, the style guide is not detailed enough and certain elements are forgotten or specific accessibility checks are missed. For example:

• Different font sizes require different color contrast ratios between the foreground and the background.
• Accessibility for heading colors varies by font size.
• Alert boxes need to be legible with adequate contrast.
• Primary and secondary colors need to be checked for accessibility with the site background.

Development

If accessibility has been top-of-mind up to this point, developers will be well positioned to avoid accessibility related setbacks and surprises. Notes taken during planning and wireframing can help to guide an accessibility roadmap during development. Below are a few items that are often overlooked:

“Read More” links

Almost every site created within the past 10 years has “Read More” links on landing pages, blog posts, and throughout interior pages. It is not accessible, however, to have the same text on multiple links that direct the user to different places. Link text needs to be descriptive and specific to the page, such as “Get Further Insights,” “Check Out this Special Offer,” or “Learn the Key Benefits.” 

Forms and error messages

Forms are extremely common sources of accessibility issues. Ensuring accessible forms involves many distinct elements that need to be developed properly.

• All form elements need to have proper labels with properly linked “for” attributes. Inputs with invalid “for” attributes cause the labels to not link to the inputs.
• All accessible form elements require properly set up labels with descriptive text, and linked “for” attributes. 
• Error messages need to be adequately informative for screen-reader users. Error messages such as, “This field is required,” don’t provide enough context for a visually impaired person using a screen reader. Consider more specific error messages such as, “Phone number required."

While accessibility considerations might feel like time-consuming additional steps, getting it right during development represents a significant savings of time and resources. It takes far more time and effort to find and fix accessibility issues once a site goes live, or even before it reaches the quality assurance (QA) phase than it does to understand the full scope of accessibility while the site is under construction.

Rules and Tools - It’s QA Time

Once development is complete and the site enters the QA phase, it is critical that QA testers are fully knowledgeable concerning what to check for from an accessibility standpoint and are familiar with WCAG 2.1 accessibility guidelines and testing tools. 

If accessibility issues arise during the QA phase, there needs to be a proper workflow and documentation processes in place for the QA team to successfully explain the scope of the issues, along with recommended fixes.

Want to Know More?

At Promet Source, we’re passionate about accessibility. We develop accessible sites, audit sites to uncover accessibility issues, remediate existing websites for accessibility, consult with clients on accessibility, provide accessibility training, and much more.

Contact us today for help with any or all of your web accessibility needs.