Equal Entry Website Mistakenly Called Out as Inaccessible

On July 2, 2020, a visitor to the Equal Entry website left us the following message: 

This accessibility Comment Web page May have 2 errors and 5 Alerts Suggested Screen TOOL and This Web Page [wave.webaim.org/report#/https://equalentry.com/accessibility/]

The visitor went on to explain that they had received prior guidance that the WAVE Web Accessibility Evaluation Tool tool should be used to assess issues of accessibility with a website. 

As you might imagine, we take the accessibility of our site very seriously, so this launched an immediate investigation. You can read the Appendix for our detailed technical investigation, but to ensure I don’t ‘bury the lede’… , No, the Equal Entry Accessibility page did not have any accessibility issues. Each of the Errors and Alerts that were reported were false positives. While this could have been the end of this, we decided to share this publicly as a best practice to show you the value of taking accessibility feedback seriously and digging in.  

Despite the holiday weekend, we reached out to the individual that left the comment to assure them that they were heard and that we were investigating the concern. We then brought them into that investigation by sharing an early version of this blog post. What follows is a step-by-step breakdown of our investigation and conclusion.

Step 1: Do a detailed analysis

The first thing we did was test the page with Microsoft Insights for Web. We already use this tool as part of our regular process of developing and updating our website. Because we focus so much on accessibility testing of our site as it develops, we strive to keep accessibility issues at zero. 

We were happy to have Microsoft Insights report that there were no automated failures on our site. 

Next, we ran our own WAVE scan of the page. We confirmed that WAVE does find 2 errors and 5 Alerts on the Accessibility page that are similar in number to what our site visitor reported to us. 

Then came the hard work of understanding the results WAVE was showing us.  The appendix of this document has our detailed review.   

Step 2: Address any issues you can

Being an accessibility company, Equal Entry includes accessibility within our site update planning and testing. We do routine accessibility audits on our own site, and test with individuals with disabilities. As such, we weren’t surprised that there were no issues for us to address.

If you can address an issue quickly, do so. It shows an extreme dedication to accessibility and that your company takes feedback about accessibility seriously.

Step 3: Follow up with outside companies that can take action on issues you can’t address

In our case, this is where all reported issues fell. By engaging with WebAIM, the producers of WAVE, we were able to provide them with our insight to improve their product. It will be up to them to decide if they will make adjustments or not, but on each point we did get their documented agreement that in our case they were false positive results.  

Conclusion

Despite the fact that we could make code changes to pass WAVE, we have opted not to. We would be happy to revisit these issues if we have a customer reported issue with a described user impact. 

While automated accessibility testing tools are a valuable tool to provide quick assessments, they should not be used as the only way to judge a website’s accessibility.  Tools that ask for work to be done to pass their test are taking effort away from fixes that truly improve the experience for individuals with disabilities, and create a culture where it’s more important to pass a test than to be accessible.  

While a perfect conformance statement might feel good, it can act as a target to disprove. Having an honest, up to date conformance statement with a plan to address issues over time can prove immensely valuable when addressing accessibility inquiries.

Appendix

Missing form label

WAVE reported 2 instances of this issue.

The code for the first reported Error is provided below:

<p class="comment-form-comment"><label for="comment">
Comment
</label>
<textarea id="comment" cols="45" maxlength="65525" name="eb9da0b69f" required="required" rows="8"></p>
<p>   <textarea id="adcb7b59fa4264441d3d79b4eedd2844" aria-hidden="true" name="comment" autocomplete="new-password" style="padding: 0px; clip: rect(1px, 1px, 1px, 1px); white-space: nowrap; height: 1px; width: 1px; overflow: hidden; position: absolute !important;" tabindex="-1"></textarea>

The visual label “Comment” just before the textarea is also coded to be the programmatic label for the text area below it, however, there is a second textarea that has aria-hidden=”true” making it invisible to assistive technologies. Based on the padding and content, it appears to be an element being used for visual spacing and no value, so it’s appropriate to be hidden programmatically just as it is hidden visually. For testing, I modified the HTML on the page to remove the aria-hidden=”true” and re-ran Microsoft Insights, then it too found the issue with “label: Ensures every form element has a label.”

The second reported WAVE Error was a bit harder to find. WAVE’s Code panel must be opened, to find this one.

<!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
<div style="position: absolute; left: -5000px;" aria-hidden="true"><input tabindex="-1" name="b_86f65109ae55afde9c98215a9_4c9185c668" type="text" value="" /></div>

Again, the tagged element is within an element with the aria-hidden=”true” attribute, so again not exposed to assistive technologies. From the comments, it’s clear the element is kept to prevent bot signups. With no visual elements it’s also appropriate to be programmatically hidden.

Conclusion: False positive as both WAVE errors are being reported on elements within aria-hidden=”true” elements.

 WebAIM’s Response to False Positive conclusion

… text input that is hidden with aria-hidden=”true” and tabindex=”-1″. This field does not appear to be presented to users, so the error can be ignored …
In WAVE we have chosen to identify potential errors and issues with all page elements, even if they are hidden. We’ve found that in the vast majority of cases where hidden elements have identifiable issues, these issues are at some point presented to end users (such as via dynamic page changes, by the user disabling styles, etc.). We know that there are sometimes exceptions (such as yours) where hidden elements may not be presented to users via aria-hidden and/or tabindex. In the somewhat rare cases where such elements are hidden in an accessible manner, they can often be removed entirely from the page or the accessibility can readily be added to them. In your case if you can add aria-hidden and tabindex, then it’s probably reasonable to assume you can also add a or aria-label to address the detectable error pattern.
…
We do understand and hear your concern about additional effort being expended to pass an accessibility test. On the other hand, because we can’t know if the detected issues might be presented to users at some point (and our experience suggests this is more common), it would also be problematic for end users for us to ignore or downplay them. It’s a difficult balance for us to maintain, and one that we will consider again for future updates.

Underlined text

WAVE reported 4 instances of this issue. WAVE says this issue matters because “Underlines almost universally indicates linked text. Consider removing the underline from the non-link text. Other styling (e.g., bold or italics) can be used to differentiate the text.” All 4 of these issues are within the footer and after a social media link.

Conclusion: Not an accessibility issue, as the underlined text are links.

WebAIM’s response to Alerts on underlined links

These are not errors, but are simply alerting you to the presence of the underlined text so you can verify that they are links or are not potentially confused with links … I’ve added a feature request for us to review and (probably) add this to our evaluation logic. I think it can still be useful to know if the underline styles are defined separate from the default link styles, but it probably doesn’t make sense for us to have an alert for underline on or within links.

Redundant title text

WAVE tagged this issue as on, or after, the link “Make WordPress Accessible.”

Within the Equal Entry website, internal links can be activated to update the current browser instance, but external links are opened in a new tab/window. To ensure visitors know if they will be moved to a new tab/window before activation, Equal Entry follows the best practice of providing both visual and programmatic information.

NVDA users reading the Accessibility page will hear

Screen Reader Announces: We track new features and functionality at visited link Make WordPress Accessible graphic External .

While no accessibility issue was found with other tools or NVDA as a screen reader, the next step was still to review the code.

<a href="https://make.wordpress.org/Accessibility/" target="_blank" rel="external noopener">
Make WordPress Accessible
</a>

The SVG graphical element is using aria-labelledby to reference the title element within the SVG, the title tag on the SVG element is therefore ignored by assistive technologies, and is not redundant.

Conclusion: Not an accessibility issue, we tested with assistive technology tools and did not hear the information repeated.

 WebAIM’s Response to Alerts on Redundant Titles

Title attribute text may be read by screen reader users, and in this case it would repeat information – thus the alert. In other cases title attribute is not made accessible to users. We generally recommend against using title attribute… I’ll do some testing, but I believe that this is just the case in certain screen reader/browser combinations that do not re-read the duplicate text. This is not the case in other combinations. Again, this is only an alert, so if we determine that even if there is potential for duplication of this content, this is not a WCAG failure or highly impactful issue for users.

Heather Burns

Accessibility Consultant | Charlotte, NC

Visit Profile