Step Back and Get a Perspective
You may have heard the saying, "Can’t see the forest for the trees". That saying is applied to situations where a person is focused on the small details to such a degree that they lose sight of the purpose of the larger objective. As applied to accessibility, this means being too focused on conforming with the accessibility techniques (specifically the Success/Failure Techniques in those guidelines) instead of creating accessible content based on what the Success Criteria is ultimately driving at.
A lot of attention is placed on conforming with the accessibility guidelines such as WCAG 2.0/2.1 Level A & AA. That is because there must be something measurable to prove accessibility has been accounted for in our web content. This set of technical guidelines states in the WCAG Introduction that the goal is to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. Additionally, it states that the WCAG documents explain how to make web content more accessible to people with disabilities.
The WCAG Success Criteria are often vague in that they are intended to accommodate for existing and future technologies. These Success Criteria are then supported by several Success Techniques and Failure Techniques to determine if the associated criterion is met. The techniques can get very technical and often overlap with or rely on the application of other techniques. This can get confusing quickly. It is not surprising that many often fall into the trap of being overly focused on the smaller details of these techniques to the point where they fail to "see the forest for the trees" in the success criteria. All too often, priority is placed on conforming with WCAG techniques rather than ensuring the criterion is met so that content is accessible, and that the user experience makes sense. After all, this is the overarching goal of the Success Criteria.
What do we mean by all this?
Here are some examples we see often – even from some accessibility professionals who have been working with WCAG for years. Following is a screen shot of our WebAlign site.
On the main landing page there is an image banner with a black background with blue text that reads "<WebAlign/>" This image is stretched a bit for visual effect which cuts off a small portion of the text in the image but is still readable.
There are a few WCAG Success Criteria that may come to mind when looking at the WebAlign banner image in the screen capture above, such as:
Reviewing for WCAG Success Criterion 1.1.1 Non-text Content
An image would be considered non-text content. WCAG Success Criterion 1.1.1 ensures that all non-text content provides a text alternative that serves an equivalent purpose. Many times, when an image of text is seen, the immediate response is to flag a failure against Success Criterion 1.1.1 if there is no ALT attribute or ARIA-LABEL provided. In the case of our image banner, this image is embedded as a background image and therefore does not support an ALT attribute or ARIA-LABEL.
Does that mean it is a failure of Success Criterion 1.1.1 Non-text Content? Not at all! The banner image is provided as a decorative image. Success Criterion 1.1.1 excludes decorative content from requiring a text equivalent.
You may be thinking that the image still has visible text displayed and users should be made aware of that text. That is true in some cases but in this case, it would not make sense to repeat that text unnecessarily. In the screen capture below you can see the same image banner, but you will also see that we have highlighted in front of that banner text that also says "WebAlign".
It is true that we do not include the angle brackets as part of the text but why would we need to? All of that is purely decorative and does not add to the purpose of the page content. If we were to force the image banner to have a text equivalent for the decorative image, a screen reader would then read the same information twice. Most screen readers I know prefer not to have unnecessary information included as part of the page content because it distracts from the purpose of the page. In this case, the banner does not require a text equivalent to conform with Success Criterion 1.1.1.
Reviewing for WCAG Success Criterion 1.4.5 Images of Text
The same is true for Success Criterion 1.4.5 Images of Text. This criterion is focused on using text rather than images of text if the technologies being used can achieve the same visual presentation. Because our banner image is decorative and presented as part of our brand name, it would be excluded from Success Criterion 1.4.5. Spending the resources to achieve the same brand name appearance for the sole purpose of presenting the details in ‘text’ does not make sense. We have already established this banner is decorative and the text it contains is already provided on the screen in an accessible way.
Step Back and See the Bigger Picture
The two examples we just covered demonstrate the drawback of becoming too focused on the details of specific Success/Failure Techniques. If we do this, we will miss the real purpose of the Success Criterion. Spending time and resources to force the issue in the situations covered above would result in the user experience suffering. How so? Because the non-visual users would have to hear this text repeat whereas the visual user would naturally glance past it since it is decorative!
Reviewing for WCAG Success Criterion 1.4.3 Contrast (Minimum)
Contrast is a criterion that seems straight forward. Minimum contrast between text and images of text should be at 4.5:1 or greater. Larger text has a lower minimum contrast requirement of at least 3:1. Where we see accessibility professionals sometimes get lost in the details is when dealing with images of text. This is like we highlighted earlier with our black WebAlign banner with blue text, which is shown again below for reference.
Success Criterion 1.4.3 Contrast (Minimum) specifically states that text that is part of a logo or brand name has no contrast requirements. Even so, when we are asked to review accessibility reports or web site accessibility legal complaints, we almost always see where a company logo that includes text and does not meet a 4.5:1 contrast ratio is called out as a failure to conform with Success Criterion 1.4.3. That is not to say having a logo that meets contrast requirements is not a good idea, it is just not required by WCAG.
This again is likely due to getting too focused on the details and failing to consider the larger objective. When testing for contrast, it is easy to see an image of text and automatically verify the contrast rather than pausing and considering how that image of text is being used. It may seem like a small oversight but consider the amount of time it can take to document the issue and have design or development take steps to redesign and code a fix – the result can lead to wasted resources as well as lessen the credibility of the accessibility professional should the oversight come to light! All because we became hyper-focused on the details rather than considering the big picture.
The examples we covered today hopefully demonstrate what we mean when we ask the question, "Are You Unable to See the Accessibility Forest for The Trees?"
While we currently need WCAG as a gauge to demonstrate an organization is doing something about accessibility, it is important to remember the primary goal of WCAG is to create accessible content that is part of a good user experience.
As accessibility professionals, we need to evaluate web content in its entirety, not just to ensure a specific WCAG Success Criterion’s Success Technique or Failure Technique can be flagged as passing. This means stepping back and seeing the whole picture, or "forest" in this case. All users of our web sites should be able to access our web content without having to struggle to discern what is on the page and/or encounter blocking issues. It also means focusing on the WCAG success criteria first before concluding that content violates WCAG. In the example that we reviewed above, our examples may violate a specific WCAG technique but they do not violate WCAG as a whole because the example is specifically exempted by the three success criteria that could potentially apply.
If you are seeking the help of an accessibility professional, you should also be concerned about those that have yet to grasp the concept of putting "accessibility" before "conformance". Obviously, being able to state that you are conforming with WCAG is important. Yet, it is more important know where looking too closely at the details to pass a specific WCAG Success/Failure Technique can hinder or muddy the water of accessible content and the user experience.
We would love to hear from you on this topic! Have you ever been too focused on the details and mispresented an accessibility issue? Have you ever received an accessibility report that caused you to redesign or fix an alleged WCAG failure that really was not a failure? If so, please let us know by leaving a comment below.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.