WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Testing philopsophy: opinions wanted

for

From: Birkir R. Gunnarsson
Date: Apr 27, 2014 5:08AM

We need to be aware of any element referenced using the
aria-labelledby/aria-describedby labeling on form fields.
That elemenb's value is announced to screen reader users regardless of
its visibility.
display: none/
visibility: hidden/
aria-hidden="true"
are all ignored when calculating the accessible name per the ARIA spec.
So that is one situation where hidden content is announced to screen readers.



On 4/26/14, Katie Haritos-Shea < <EMAIL REMOVED> > wrote:
> GOOD question. I tend to agree with Jared. The potential for a hidden
> element to be unhidden is likely at some point, and, in the case of
> disabled elements, sometimes the visual user *sees* things (fields,
> default text in disabled elements and fields) that some AT user might not.
>
> But if auditing, and the answers to these kind of questions was simple and
> clearcut(with just one obvious answer) - well - methinks we might all be
> out of jobs.....:-)
>
> * katie *
>
> Katie Haritos-Shea @ GMAIL
> On Apr 26, 2014 2:28 PM, "Denis Boudreau" < <EMAIL REMOVED> > wrote:
>
>> 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/
>> > >> > >> > >>
>> >> >> >>
> > > >


--
Work hard. Have fun. Make history.