WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Testing philopsophy: opinions wanted

for

From: Denis Boudreau
Date: Apr 26, 2014 12:26PM

Hey list, Karl,

I hope I’m not over simplifying everything, but my take would be that if I can’t make the invisible, or hidden stuff appear as I manipulate the content/objects in the page, chances are that users won’t either. So I test everything that I can see or hear, and make sure I report everything that I find. If I can’t figure out how to make the hidden or invisible content display at some point, I just move on. There’s only so much time you can dedicate to a single page when you have to audit 100 more.

Now agreed, there are elements in WCAG that I test, purely based on faith in the wisdom of the WCAG WG. SC 4.1.1 is one of those. Whether we think of duplicate attributes inside a single element or not providing closing tags for self closing elements for example, I could never demonstrate that such issues can indeed create real problems for end users. But because it’s there, I look for it and report it. Based on that same faith, I trust that there can be potential issues with duplicate IDs because as the objects are called, I trust that only one object can have a specific name - but even for that, I have never actually experienced the damage in a real life situation.

So I still think that we can safely assume that anything that cannot be “experienced” by the user isn’t a problem. I wish I could be proven wrong, however. So if this could be demonstrated, enabling an option to test for hidden stuff would certainly bring value to the work that I do. Because ultimately, the only thing that matters is uncovering the road blocks, no matter how well hidden they are.

/Denis



On Apr 26, 2014, at 10:02 AM, Karl Groves < <EMAIL REMOVED> > wrote:

> Warning: Somewhat geeky stuff follows
>
> For a long time I've felt that anything in document source that cannot be
> "experienced" by the user isn't a problem. Specifically what I mean is
> stuff that has a CSS declaration of display: none. Because screen readers
> ignore such content and because such content is made "invisible" to the
> DOM, the content cannot be experienced, controls that would otherwise be
> actionable, etc. are not and therefore users of other ATs like screen
> magnifiers and voice dictation software cannot get to the content either.
>
> So, like a Koan: if the user can't get to the content, is it a problem?
>
> Turns out there might be an argument for testing such content. For those
> who read multiple lists, I posted to PFWG and WAI-IG about an interesting
> issue with hidden form labels. [1] The existence of duplicated use of the
> same ID value within the hidden content - or aria-labelledby/
> aria-describedby in the hidden content - seems to be the exception. Such
> content *can* be experienced by the user and those IDs can, in some cases,
> be referenced by ATs.
>
>
> Here's what I'm wondering (in the context of automated testing):
>
> In general, should hidden content be tested? Before answering, I agree that
> if/ when it comes into view it must be tested. But in its hidden state, is
> it relevant to test?
>
> Or, should that testing only be limited to looking for specific things,
> such as duplicate use of IDs, or external references to hidden IDs?
>
> What value would you find in the ability to enable an option to test the
> hidden stuff?
>
>
>
>
>
> 1 - http://lists.w3.org/Archives/Public/w3c-wai-ig/2014AprJun/0090.html
> --
>
> Karl Groves
> www.karlgroves.com
> @karlgroves
> http://www.linkedin.com/in/karlgroves
> Phone: +1 410.541.6829
>
> www.tenon.io
>
> What is this thing and what does it do?
> http://vimeo.com/84970341
>
> http://lanyrd.com/profile/karlgroves/
> > >