E-mail List Archives

Thread: Testing philopsophy: opinions wanted

for

Number of posts in this thread: 6 (In chronological order)

From: Karl Groves
Date: Sat, Apr 26 2014 8:02AM
Subject: Testing philopsophy: opinions wanted
No previous message | Next message →

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/

From: Jared Smith
Date: Sat, Apr 26 2014 8:57AM
Subject: Re: Testing philopsophy: opinions wanted
← Previous message | Next message →

I think it's a fairly safe assumption that if content is hidden within
a page, then there is likely some circumstance in which that content
would not be hidden (why have it there if it is never utilized?). As
such, it's a good idea to test it.

Our approach with WAVE is to test the content regardless of its
visibility. We provide an indication in the sidebar for icons that
apply to elements that are hidden. And we provide a No Styles option
to reveal the hidden content in the page.

Jared

From: Denis Boudreau
Date: Sat, Apr 26 2014 12:26PM
Subject: Re: Testing philopsophy: opinions wanted
← Previous message | Next message →

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 ADDRESS 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/
> > >

From: Katie Haritos-Shea
Date: Sat, Apr 26 2014 9:14PM
Subject: Re: Testing philopsophy: opinions wanted
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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/
> > > > > > >
> > > >

From: Birkir R. Gunnarsson
Date: Sun, Apr 27 2014 5:08AM
Subject: Re: Testing philopsophy: opinions wanted
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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.

From: Sailesh Panchang
Date: Mon, Apr 28 2014 3:12PM
Subject: Re: Testing philopsophy: opinions wanted
← Previous message | No next message

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
> > > >