WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Testing philopsophy: opinions wanted

for

From: Sailesh Panchang
Date: Apr 28, 2014 3:12PM

The validator flags duplicate id-issues even when one of the element
that shares the id is hidden.
This is fine and perhaps a good thing. It may uncover functionality
problems too.
(I do not see the point in aria-labelledby / describedby referencing
text that is hidden from view. The off-screen technique can also
provide access to text to benefit vision impaired users and will work
even when ARIA is not supported).
But, checking for poor contrast issues within content that is not
visible / rendered for sighted users is a waste.
Regards,
Sailesh


On 4/27/14, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> 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.
> > > >