colorbox icon indicating copy to clipboard operation
colorbox copied to clipboard

Accessibility issues

Open XhmikosR opened this issue 8 years ago • 6 comments

The latest version throws a few accessibility errors. An example is your first one using html_codesniffer using WCAG2AA:

This button element does not have a name available to an accessibility API. Valid names are: title attribute, element content.
Principle: Robust
Techniques: H91

XhmikosR avatar Jan 03 '16 09:01 XhmikosR

Of the warnings, the only one I am personally concerned about fixing is the one you quoted. The rest are styling concerns that I'll leave up to the user and their CSS.

The error you quoted has to do with buttons that are hidden, without content, but still exist in the DOM. When the buttons are visible there is no error because they meet the criteria at that point (have content that counts as a name).

So the real fix here would be for me to rework things so that the buttons aren't in the DOM at all when they are not being used. The reason for the hidden buttons in the DOM is so that the browser will go ahead and load the background images, avoiding the flash of unstyled content when Colorbox is first opened. I assume screen readers are intelligent enough not to read out hidden elements, so I doubt fixing the error would help anyone in practice.

jackmoore avatar Jan 05 '16 20:01 jackmoore

True that but at the moment there are not so tech savvy people (bosses and customers) who just look at the reports without knowing what happens behind the scenes.

So, I wonder if you could apply the same fix for all buttons. If you think it's a bug we could open an issue with html_codesniffer.

Thanks! On Jan 5, 2016 22:22, "Jack Moore" [email protected] wrote:

Of the warnings, the only one I am personally concerned about fixing is the one you quoted. The rest are styling concerns that I'll leave up to the user and their CSS.

The error you quoted has to do with buttons that are hidden, without content, but still exist in the DOM. When the buttons are visible there is no error because they meet the criteria at that point (have content that counts as a name).

So the real fix here would be for me to rework things so that the buttons aren't in the DOM at all when they are not being used. The reason for the hidden buttons in the DOM is so that the browser will go ahead and load the background images, avoiding the flash of unstyled content when Colorbox is first opened. I assume screen readers are intelligent enough not to read out hidden elements, so I doubt fixing the error would help anyone in practice.

— Reply to this email directly or view it on GitHub https://github.com/jackmoore/colorbox/issues/765#issuecomment-169120569.

XhmikosR avatar Jan 05 '16 20:01 XhmikosR

Does anyone have a patch, hack or instructions for eliminating this accessibility error? I'm in the public sector here, and our site has received a complaint letter. At this point I need to fix these errors, or I have to replace Colorbox altogether. Thanks for any help.

trussd avatar Aug 10 '16 14:08 trussd

@jackmoore Would you consider a pull request to just add content to those buttons? This is a quick 5 minute fix, and a lot of people in universities and other public sector would be thankful. As @trussd @XhmikosR have mentioned, some of us work in the public sector and it's better to report no accessibility.

The appropriate smart loading fix would take significant time to study the whole codebase. The other one I already have a quick fix.

thanks

mxcosu avatar Nov 29 '16 00:11 mxcosu

I've just created two PRs that address this issue in different ways:

#821 - Does the bare minimum. Adds button text to pass both the original HTML_CodeSniffer test reported here as well as the similar test on http://wave.webaim.org

#822 - Implements improved Accessibility with proper Aria attributes. This solution actually does not pass HTML_CodeSniffer, but passes the http://wave.webaim.org I guess the proper solution would maybe be a combination of these two, but since they both touch the same lines, there will be a merge conflict on the second one, after the first is merged.

Edit: #822 has been fixed to pass both HTML_CodeSniffer and http://wave.webaim.org , I'll close #821 .

Edit 2: #832 adds upon #822 with some additional accessibility tweaks.

jameswilson avatar Mar 28 '17 23:03 jameswilson

I assume screen readers are intelligent enough not to read out hidden elements

Unless the item is display: none, it will get read. I just got a complaint from a screen reader user about these buttons being read out.

lkmorlan avatar May 10 '18 14:05 lkmorlan