E-mail List Archives

Search E-mail List Archives for

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

From: Birkir R. Gunnarsson
Date: Sat, Aug 10 2013 1:17PM
Subject: aria-hidden and NVDA, isn't this a bug?
No previous message | Next message →

Greetings wise ones

Opinions needed and welcome.
I am experimenting with use of aria-hidden to hide lists/list items
and table cells.
This works nicely in Jaws, but not in NVDA.

Starting with lists.
Applying aria-hidden on a list item
<code>
<ul>
<li>List item #1</li>
<li aria-hidden="true">Hidden item 1</li>
<li aria-hidden="true">Hidden item #2</li>
</ul>
</code>
NVDA respects the aria-hidden use for the list items themselves, but
announces, in the list summary: "list with 3 items", even if the list
only contains one, and the quick key to jump to next list item does
not work.
This happens both in IE10 and FF22.
Using role="presentation" along with the aria-hidden does not have any effect.

Even if the latter two list items are wrapped up in a div with
aria-hidden set to true, NVDA still announces the list as having two
items.

Jaws recognizes both versions of the list as having just one item.
Similarly if a table cell is marked with aria-hidden Jaws ignores it,
but NVDA does not.
This can lead to serious navigation issues in tables with these cells,
since when inserted it forces an entire column and shifts all the
information to the right, creating a mismatch between column header
and the info they contain.
Just imagine a row with two columns.
First Name and Last Name.
If a td is inserted with aria-hidden="true", then the values, Jaws
announces the table as having two columns and two rows, and announces
values correctly.
NVDA announces table as having 3 columns and two rows and the table
navigation gets very messy actually.

So, basically, is it my misinterpretation that aria-hidden should hide
its element as well as all info inside that element.
Does aria hidden always have to be used on a container element such as a div?
A quick check on the ARIA specs did not really show me anything either
way, may be I was not interpreting something correctly.
Cheers
-Birkir

From: Bryan Garaventa
Date: Sat, Aug 10 2013 1:48PM
Subject: Re: aria-hidden and NVDA, isn't this a bug?
← Previous message | Next message →

This is sort of tricky.

JAWS' ability to reevaluate the elements removed from the accessibility tree
using aria-hidden may be useful, but it's also misleading.

The use of aria-hidden doesn't actually change the elements in the DOM at
all, meaning that they still exist within their native containers. Such as
lists having the same number of LIs, and tables having the same number of
TDs, regardless what is announced by the screen reader.

So, if you use aria-hidden to simulate a properly formed data table
structure by hiding extra cells, it is still an improperly formed data table
in the browser, and will likely have accessibility issues for other ATs.

The same is true for ULs, where lists are defined by the number of LIs
within, and surrounding the LI tags with different container elements inside
of the UL or OL may present different accessibility issues, regardless
whether aria-hidden is applied.

I suspect NVDA is evaluating the DOM directly for this information, which is
why it is announcing these values. Perhaps one of the NVDA guys here can
elaborate further to clarify.

The use of aria-hidden to hide an element including all child elements
should work on any element type, not just containers.

Keep in mind that this doesn't effect the tab order of active elements at
all. So, if you have an active element within the boundary of a container
hidden via aria-hidden, it will still be in the tab order regardless, and
will sound like a dead tab stop for screen reader users.


----- Original Message -----
From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, August 10, 2013 12:17 PM
Subject: [WebAIM] aria-hidden and NVDA, isn't this a bug?


> Greetings wise ones
>
> Opinions needed and welcome.
> I am experimenting with use of aria-hidden to hide lists/list items
> and table cells.
> This works nicely in Jaws, but not in NVDA.
>
> Starting with lists.
> Applying aria-hidden on a list item
> <code>
> <ul>
> <li>List item #1</li>
> <li aria-hidden="true">Hidden item 1</li>
> <li aria-hidden="true">Hidden item #2</li>
> </ul>
> </code>
> NVDA respects the aria-hidden use for the list items themselves, but
> announces, in the list summary: "list with 3 items", even if the list
> only contains one, and the quick key to jump to next list item does
> not work.
> This happens both in IE10 and FF22.
> Using role="presentation" along with the aria-hidden does not have any
> effect.
>
> Even if the latter two list items are wrapped up in a div with
> aria-hidden set to true, NVDA still announces the list as having two
> items.
>
> Jaws recognizes both versions of the list as having just one item.
> Similarly if a table cell is marked with aria-hidden Jaws ignores it,
> but NVDA does not.
> This can lead to serious navigation issues in tables with these cells,
> since when inserted it forces an entire column and shifts all the
> information to the right, creating a mismatch between column header
> and the info they contain.
> Just imagine a row with two columns.
> First Name and Last Name.
> If a td is inserted with aria-hidden="true", then the values, Jaws
> announces the table as having two columns and two rows, and announces
> values correctly.
> NVDA announces table as having 3 columns and two rows and the table
> navigation gets very messy actually.
>
> So, basically, is it my misinterpretation that aria-hidden should hide
> its element as well as all info inside that element.
> Does aria hidden always have to be used on a container element such as a
> div?
> A quick check on the ARIA specs did not really show me anything either
> way, may be I was not interpreting something correctly.
> Cheers
> -Birkir
> > >

From: Dave Merrill
Date: Sat, Aug 10 2013 6:15PM
Subject: Re: aria-hidden and NVDA, isn't this a bug?
← Previous message | Next message →

@Birkir: Minor point, but I'm pretty sure it's invalid HTML to put a div
inside a list with the intent of creating a container for some items that
you can apply an attribute to (aria-hidden). The only item container
allowed there is <optgroup>, but that will have a visual effect of its own.
The div strategy may still "work", but it wouldn't surprise me if its
behavior was browser dependent.

@Bryan: I'm a developer, not by any means an accessibility expert, but your
last paragraph surprises me. Are you saying that if a section of a form is
hidden according to the business rules in effect at the time, that's not
sufficient to remove the fields inside it from the tab order? If so, what
are you supposed to do, disable those fields too? I've never done that, and
I've never seen that behavior in standard browsers.

Dave Merrill


On Sat, Aug 10, 2013 at 3:48 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> This is sort of tricky.
>
> JAWS' ability to reevaluate the elements removed from the accessibility
> tree
> using aria-hidden may be useful, but it's also misleading.
>
> The use of aria-hidden doesn't actually change the elements in the DOM at
> all, meaning that they still exist within their native containers. Such as
> lists having the same number of LIs, and tables having the same number of
> TDs, regardless what is announced by the screen reader.
>
> So, if you use aria-hidden to simulate a properly formed data table
> structure by hiding extra cells, it is still an improperly formed data
> table
> in the browser, and will likely have accessibility issues for other ATs.
>
> The same is true for ULs, where lists are defined by the number of LIs
> within, and surrounding the LI tags with different container elements
> inside
> of the UL or OL may present different accessibility issues, regardless
> whether aria-hidden is applied.
>
> I suspect NVDA is evaluating the DOM directly for this information, which
> is
> why it is announcing these values. Perhaps one of the NVDA guys here can
> elaborate further to clarify.
>
> The use of aria-hidden to hide an element including all child elements
> should work on any element type, not just containers.
>
> Keep in mind that this doesn't effect the tab order of active elements at
> all. So, if you have an active element within the boundary of a container
> hidden via aria-hidden, it will still be in the tab order regardless, and
> will sound like a dead tab stop for screen reader users.
>
>
> ----- Original Message -----
> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Saturday, August 10, 2013 12:17 PM
> Subject: [WebAIM] aria-hidden and NVDA, isn't this a bug?
>
>
> > Greetings wise ones
> >
> > Opinions needed and welcome.
> > I am experimenting with use of aria-hidden to hide lists/list items
> > and table cells.
> > This works nicely in Jaws, but not in NVDA.
> >
> > Starting with lists.
> > Applying aria-hidden on a list item
> > <code>
> > <ul>
> > <li>List item #1</li>
> > <li aria-hidden="true">Hidden item 1</li>
> > <li aria-hidden="true">Hidden item #2</li>
> > </ul>
> > </code>
> > NVDA respects the aria-hidden use for the list items themselves, but
> > announces, in the list summary: "list with 3 items", even if the list
> > only contains one, and the quick key to jump to next list item does
> > not work.
> > This happens both in IE10 and FF22.
> > Using role="presentation" along with the aria-hidden does not have any
> > effect.
> >
> > Even if the latter two list items are wrapped up in a div with
> > aria-hidden set to true, NVDA still announces the list as having two
> > items.
> >
> > Jaws recognizes both versions of the list as having just one item.
> > Similarly if a table cell is marked with aria-hidden Jaws ignores it,
> > but NVDA does not.
> > This can lead to serious navigation issues in tables with these cells,
> > since when inserted it forces an entire column and shifts all the
> > information to the right, creating a mismatch between column header
> > and the info they contain.
> > Just imagine a row with two columns.
> > First Name and Last Name.
> > If a td is inserted with aria-hidden="true", then the values, Jaws
> > announces the table as having two columns and two rows, and announces
> > values correctly.
> > NVDA announces table as having 3 columns and two rows and the table
> > navigation gets very messy actually.
> >
> > So, basically, is it my misinterpretation that aria-hidden should hide
> > its element as well as all info inside that element.
> > Does aria hidden always have to be used on a container element such as a
> > div?
> > A quick check on the ARIA specs did not really show me anything either
> > way, may be I was not interpreting something correctly.
> > Cheers
> > -Birkir
> > > > > > >
> > > >



--
Dave Merrill

From: Bryan Garaventa
Date: Sat, Aug 10 2013 6:46PM
Subject: Re: aria-hidden and NVDA, isn't this a bug?
← Previous message | Next message →

I'm not really sure what you mean by "a section of a form is hidden
according to the business rules in effect at the time".

If you want to hide something visually as well as from screen readers, the
best way is to use CSS such as "display:none", which also prevents all
active elements within the container from appearing in the tab order as
expected.

The ARIA attribute aria-hidden however is entirely different, and only hides
the content from screen readers, but does nothing visually by itself, and
doesn't change the keyboard accessibility of any active elements.

E.G

<div aria-hidden="true">
<form>
<input title="Test" type="text" />
</form>
</div>

Even though screen readers can't detect anything within the Div when
arrowing in the Virtual Buffer, you can still tab to the form field
regardless, which is not announced because there is nothing in the
accessibility tree to identify what the active element is. This causes a
dead tab stop for screen reader users.

If you want to truly prevent something from receiving focus when combined
with aria-hidden, then you need to set tabindex="-1" on all active elements
within that container as well.

You could also bind the attribute with CSS, such as:

*[aria-hidden="true"] {
display: none;
}

Which will hide it visually as well.

But, if you need the content to remain visible, then tabindex is the only
way to prevent keyboard focus from going into these areas.

----- Original Message -----
From: "Dave Merrill" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, August 10, 2013 5:15 PM
Subject: Re: [WebAIM] aria-hidden and NVDA, isn't this a bug?


> @Birkir: Minor point, but I'm pretty sure it's invalid HTML to put a div
> inside a list with the intent of creating a container for some items that
> you can apply an attribute to (aria-hidden). The only item container
> allowed there is <optgroup>, but that will have a visual effect of its
> own.
> The div strategy may still "work", but it wouldn't surprise me if its
> behavior was browser dependent.
>
> @Bryan: I'm a developer, not by any means an accessibility expert, but
> your
> last paragraph surprises me. Are you saying that if a section of a form is
> hidden according to the business rules in effect at the time, that's not
> sufficient to remove the fields inside it from the tab order? If so, what
> are you supposed to do, disable those fields too? I've never done that,
> and
> I've never seen that behavior in standard browsers.
>
> Dave Merrill
>
>
> On Sat, Aug 10, 2013 at 3:48 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> This is sort of tricky.
>>
>> JAWS' ability to reevaluate the elements removed from the accessibility
>> tree
>> using aria-hidden may be useful, but it's also misleading.
>>
>> The use of aria-hidden doesn't actually change the elements in the DOM at
>> all, meaning that they still exist within their native containers. Such
>> as
>> lists having the same number of LIs, and tables having the same number of
>> TDs, regardless what is announced by the screen reader.
>>
>> So, if you use aria-hidden to simulate a properly formed data table
>> structure by hiding extra cells, it is still an improperly formed data
>> table
>> in the browser, and will likely have accessibility issues for other ATs.
>>
>> The same is true for ULs, where lists are defined by the number of LIs
>> within, and surrounding the LI tags with different container elements
>> inside
>> of the UL or OL may present different accessibility issues, regardless
>> whether aria-hidden is applied.
>>
>> I suspect NVDA is evaluating the DOM directly for this information, which
>> is
>> why it is announcing these values. Perhaps one of the NVDA guys here can
>> elaborate further to clarify.
>>
>> The use of aria-hidden to hide an element including all child elements
>> should work on any element type, not just containers.
>>
>> Keep in mind that this doesn't effect the tab order of active elements at
>> all. So, if you have an active element within the boundary of a container
>> hidden via aria-hidden, it will still be in the tab order regardless, and
>> will sound like a dead tab stop for screen reader users.
>>
>>
>> ----- Original Message -----
>> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>> Sent: Saturday, August 10, 2013 12:17 PM
>> Subject: [WebAIM] aria-hidden and NVDA, isn't this a bug?
>>
>>
>> > Greetings wise ones
>> >
>> > Opinions needed and welcome.
>> > I am experimenting with use of aria-hidden to hide lists/list items
>> > and table cells.
>> > This works nicely in Jaws, but not in NVDA.
>> >
>> > Starting with lists.
>> > Applying aria-hidden on a list item
>> > <code>
>> > <ul>
>> > <li>List item #1</li>
>> > <li aria-hidden="true">Hidden item 1</li>
>> > <li aria-hidden="true">Hidden item #2</li>
>> > </ul>
>> > </code>
>> > NVDA respects the aria-hidden use for the list items themselves, but
>> > announces, in the list summary: "list with 3 items", even if the list
>> > only contains one, and the quick key to jump to next list item does
>> > not work.
>> > This happens both in IE10 and FF22.
>> > Using role="presentation" along with the aria-hidden does not have any
>> > effect.
>> >
>> > Even if the latter two list items are wrapped up in a div with
>> > aria-hidden set to true, NVDA still announces the list as having two
>> > items.
>> >
>> > Jaws recognizes both versions of the list as having just one item.
>> > Similarly if a table cell is marked with aria-hidden Jaws ignores it,
>> > but NVDA does not.
>> > This can lead to serious navigation issues in tables with these cells,
>> > since when inserted it forces an entire column and shifts all the
>> > information to the right, creating a mismatch between column header
>> > and the info they contain.
>> > Just imagine a row with two columns.
>> > First Name and Last Name.
>> > If a td is inserted with aria-hidden="true", then the values, Jaws
>> > announces the table as having two columns and two rows, and announces
>> > values correctly.
>> > NVDA announces table as having 3 columns and two rows and the table
>> > navigation gets very messy actually.
>> >
>> > So, basically, is it my misinterpretation that aria-hidden should hide
>> > its element as well as all info inside that element.
>> > Does aria hidden always have to be used on a container element such as
>> > a
>> > div?
>> > A quick check on the ARIA specs did not really show me anything either
>> > way, may be I was not interpreting something correctly.
>> > Cheers
>> > -Birkir
>> > >> > >> > >>
>> >> >> >>
>
>
>
> --
> Dave Merrill
> > >

From: Sailesh Panchang
Date: Sat, Aug 10 2013 7:36PM
Subject: Re: aria-hidden and NVDA, isn't this a bug?
← Previous message | Next message →

Dave,
If one uses <input type=hidden .../>, the form is not available to
anyone including AT users.
Bryan's reference is to use of aria-hidden on a form element or a link.
This only emphasizes the need to recognize when to use WAI-ARIA:
Use ARIA when something is not possible using native HTML simply
because the feature is not there / is not supported by browsers and
AT.
It should not be used as a hack or a quick fix for an accessibility
problem by the developer.
Accessibility issues that are the result of deficient design / coding
should be fixed by fixing the design / code.
One should not regard ARIA as a way to circumvent such changes.

A column with empty cells really has no place in a data table. It is
an example of poor design.
If developers are using it for housekeeping / other chores, it is
quite wrong: they are introducing structural markup in a page without
realizing how different users / technologies are interpreting that
content even though it may make no difference visually.
If number of columns / rows depend on data to be displayed, they
should introduce rows / columns as needed programmatically and not use
a fixed table design.
It is alright for some cells in a row / column to be empty: it
correctly represents semantics and data relationships.

Some may argue that some AT do not render empty columns. Even a column
whose cells contain images with null alt or no alt go unreported.
That's a problem too.
Should the AT take on the role of guessing what the content author
intends? It does that sometimes after all AT is meant to mitigate
problems in the environment for the end user.
But developers should not burden the AT by poor design / coding practices.
Regards,
Sailesh Panchang
Deque Systems

On 8/10/13, Dave Merrill < = EMAIL ADDRESS REMOVED = > wrote:
> @Birkir: Minor point, but I'm pretty sure it's invalid HTML to put a div
> inside a list with the intent of creating a container for some items that
> you can apply an attribute to (aria-hidden). The only item container
> allowed there is <optgroup>, but that will have a visual effect of its own.
> The div strategy may still "work", but it wouldn't surprise me if its
> behavior was browser dependent.
>
> @Bryan: I'm a developer, not by any means an accessibility expert, but your
> last paragraph surprises me. Are you saying that if a section of a form is
> hidden according to the business rules in effect at the time, that's not
> sufficient to remove the fields inside it from the tab order? If so, what
> are you supposed to do, disable those fields too? I've never done that, and
> I've never seen that behavior in standard browsers.
>
> Dave Merrill
>
>
> On Sat, Aug 10, 2013 at 3:48 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> This is sort of tricky.
>>
>> JAWS' ability to reevaluate the elements removed from the accessibility
>> tree
>> using aria-hidden may be useful, but it's also misleading.
>>
>> The use of aria-hidden doesn't actually change the elements in the DOM at
>> all, meaning that they still exist within their native containers. Such
>> as
>> lists having the same number of LIs, and tables having the same number of
>> TDs, regardless what is announced by the screen reader.
>>
>> So, if you use aria-hidden to simulate a properly formed data table
>> structure by hiding extra cells, it is still an improperly formed data
>> table
>> in the browser, and will likely have accessibility issues for other ATs.
>>
>> The same is true for ULs, where lists are defined by the number of LIs
>> within, and surrounding the LI tags with different container elements
>> inside
>> of the UL or OL may present different accessibility issues, regardless
>> whether aria-hidden is applied.
>>
>> I suspect NVDA is evaluating the DOM directly for this information, which
>> is
>> why it is announcing these values. Perhaps one of the NVDA guys here can
>> elaborate further to clarify.
>>
>> The use of aria-hidden to hide an element including all child elements
>> should work on any element type, not just containers.
>>
>> Keep in mind that this doesn't effect the tab order of active elements at
>> all. So, if you have an active element within the boundary of a container
>> hidden via aria-hidden, it will still be in the tab order regardless, and
>> will sound like a dead tab stop for screen reader users.
>>
>>
>> ----- Original Message -----
>> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>> Sent: Saturday, August 10, 2013 12:17 PM
>> Subject: [WebAIM] aria-hidden and NVDA, isn't this a bug?
>>
>>
>> > Greetings wise ones
>> >
>> > Opinions needed and welcome.
>> > I am experimenting with use of aria-hidden to hide lists/list items
>> > and table cells.
>> > This works nicely in Jaws, but not in NVDA.
>> >
>> > Starting with lists.
>> > Applying aria-hidden on a list item
>> > <code>
>> > <ul>
>> > <li>List item #1</li>
>> > <li aria-hidden="true">Hidden item 1</li>
>> > <li aria-hidden="true">Hidden item #2</li>
>> > </ul>
>> > </code>
>> > NVDA respects the aria-hidden use for the list items themselves, but
>> > announces, in the list summary: "list with 3 items", even if the list
>> > only contains one, and the quick key to jump to next list item does
>> > not work.
>> > This happens both in IE10 and FF22.
>> > Using role="presentation" along with the aria-hidden does not have any
>> > effect.
>> >
>> > Even if the latter two list items are wrapped up in a div with
>> > aria-hidden set to true, NVDA still announces the list as having two
>> > items.
>> >
>> > Jaws recognizes both versions of the list as having just one item.
>> > Similarly if a table cell is marked with aria-hidden Jaws ignores it,
>> > but NVDA does not.
>> > This can lead to serious navigation issues in tables with these cells,
>> > since when inserted it forces an entire column and shifts all the
>> > information to the right, creating a mismatch between column header
>> > and the info they contain.
>> > Just imagine a row with two columns.
>> > First Name and Last Name.
>> > If a td is inserted with aria-hidden="true", then the values, Jaws
>> > announces the table as having two columns and two rows, and announces
>> > values correctly.
>> > NVDA announces table as having 3 columns and two rows and the table
>> > navigation gets very messy actually.
>> >
>> > So, basically, is it my misinterpretation that aria-hidden should hide
>> > its element as well as all info inside that element.
>> > Does aria hidden always have to be used on a container element such as
>> > a
>> > div?
>> > A quick check on the ARIA specs did not really show me anything either
>> > way, may be I was not interpreting something correctly.
>> > Cheers
>> > -Birkir
>> > >> > >> > >>
>> >> >> >>
>
>
>
> --
> Dave Merrill
> > > >

From: Dave Merrill
Date: Sun, Aug 11 2013 5:38AM
Subject: Re: aria-hidden and NVDA, isn't this a bug?
← Previous message | Next message →

Thanks for the clarification Bryan. As you can tell, my accessibility
knowledge is limited. Among other things, the major project I work on
doesn't support ARIA other than landmark roles, which I had to fight to get
included, so I'm inexperienced with it.

And what you're actually saying makes much more sense than what I thought
you were saying :)

Dave


On Sat, Aug 10, 2013 at 8:46 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> I'm not really sure what you mean by "a section of a form is hidden
> according to the business rules in effect at the time".
>
> If you want to hide something visually as well as from screen readers, the
> best way is to use CSS such as "display:none", which also prevents all
> active elements within the container from appearing in the tab order as
> expected.
>
> The ARIA attribute aria-hidden however is entirely different, and only
> hides
> the content from screen readers, but does nothing visually by itself, and
> doesn't change the keyboard accessibility of any active elements.
>
> E.G
>
> <div aria-hidden="true">
> <form>
> <input title="Test" type="text" />
> </form>
> </div>
>
> Even though screen readers can't detect anything within the Div when
> arrowing in the Virtual Buffer, you can still tab to the form field
> regardless, which is not announced because there is nothing in the
> accessibility tree to identify what the active element is. This causes a
> dead tab stop for screen reader users.
>
> If you want to truly prevent something from receiving focus when combined
> with aria-hidden, then you need to set tabindex="-1" on all active elements
> within that container as well.
>
> You could also bind the attribute with CSS, such as:
>
> *[aria-hidden="true"] {
> display: none;
> }
>
> Which will hide it visually as well.
>
> But, if you need the content to remain visible, then tabindex is the only
> way to prevent keyboard focus from going into these areas.
>
> ----- Original Message -----
> From: "Dave Merrill" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Saturday, August 10, 2013 5:15 PM
> Subject: Re: [WebAIM] aria-hidden and NVDA, isn't this a bug?
>
>
> > @Birkir: Minor point, but I'm pretty sure it's invalid HTML to put a div
> > inside a list with the intent of creating a container for some items that
> > you can apply an attribute to (aria-hidden). The only item container
> > allowed there is <optgroup>, but that will have a visual effect of its
> > own.
> > The div strategy may still "work", but it wouldn't surprise me if its
> > behavior was browser dependent.
> >
> > @Bryan: I'm a developer, not by any means an accessibility expert, but
> > your
> > last paragraph surprises me. Are you saying that if a section of a form
> is
> > hidden according to the business rules in effect at the time, that's not
> > sufficient to remove the fields inside it from the tab order? If so, what
> > are you supposed to do, disable those fields too? I've never done that,
> > and
> > I've never seen that behavior in standard browsers.
> >
> > Dave Merrill
> >
> >
> > On Sat, Aug 10, 2013 at 3:48 PM, Bryan Garaventa <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> This is sort of tricky.
> >>
> >> JAWS' ability to reevaluate the elements removed from the accessibility
> >> tree
> >> using aria-hidden may be useful, but it's also misleading.
> >>
> >> The use of aria-hidden doesn't actually change the elements in the DOM
> at
> >> all, meaning that they still exist within their native containers. Such
> >> as
> >> lists having the same number of LIs, and tables having the same number
> of
> >> TDs, regardless what is announced by the screen reader.
> >>
> >> So, if you use aria-hidden to simulate a properly formed data table
> >> structure by hiding extra cells, it is still an improperly formed data
> >> table
> >> in the browser, and will likely have accessibility issues for other ATs.
> >>
> >> The same is true for ULs, where lists are defined by the number of LIs
> >> within, and surrounding the LI tags with different container elements
> >> inside
> >> of the UL or OL may present different accessibility issues, regardless
> >> whether aria-hidden is applied.
> >>
> >> I suspect NVDA is evaluating the DOM directly for this information,
> which
> >> is
> >> why it is announcing these values. Perhaps one of the NVDA guys here can
> >> elaborate further to clarify.
> >>
> >> The use of aria-hidden to hide an element including all child elements
> >> should work on any element type, not just containers.
> >>
> >> Keep in mind that this doesn't effect the tab order of active elements
> at
> >> all. So, if you have an active element within the boundary of a
> container
> >> hidden via aria-hidden, it will still be in the tab order regardless,
> and
> >> will sound like a dead tab stop for screen reader users.
> >>
> >>
> >> ----- Original Message -----
> >> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> >> Sent: Saturday, August 10, 2013 12:17 PM
> >> Subject: [WebAIM] aria-hidden and NVDA, isn't this a bug?
> >>
> >>
> >> > Greetings wise ones
> >> >
> >> > Opinions needed and welcome.
> >> > I am experimenting with use of aria-hidden to hide lists/list items
> >> > and table cells.
> >> > This works nicely in Jaws, but not in NVDA.
> >> >
> >> > Starting with lists.
> >> > Applying aria-hidden on a list item
> >> > <code>
> >> > <ul>
> >> > <li>List item #1</li>
> >> > <li aria-hidden="true">Hidden item 1</li>
> >> > <li aria-hidden="true">Hidden item #2</li>
> >> > </ul>
> >> > </code>
> >> > NVDA respects the aria-hidden use for the list items themselves, but
> >> > announces, in the list summary: "list with 3 items", even if the list
> >> > only contains one, and the quick key to jump to next list item does
> >> > not work.
> >> > This happens both in IE10 and FF22.
> >> > Using role="presentation" along with the aria-hidden does not have any
> >> > effect.
> >> >
> >> > Even if the latter two list items are wrapped up in a div with
> >> > aria-hidden set to true, NVDA still announces the list as having two
> >> > items.
> >> >
> >> > Jaws recognizes both versions of the list as having just one item.
> >> > Similarly if a table cell is marked with aria-hidden Jaws ignores it,
> >> > but NVDA does not.
> >> > This can lead to serious navigation issues in tables with these cells,
> >> > since when inserted it forces an entire column and shifts all the
> >> > information to the right, creating a mismatch between column header
> >> > and the info they contain.
> >> > Just imagine a row with two columns.
> >> > First Name and Last Name.
> >> > If a td is inserted with aria-hidden="true", then the values, Jaws
> >> > announces the table as having two columns and two rows, and announces
> >> > values correctly.
> >> > NVDA announces table as having 3 columns and two rows and the table
> >> > navigation gets very messy actually.
> >> >
> >> > So, basically, is it my misinterpretation that aria-hidden should hide
> >> > its element as well as all info inside that element.
> >> > Does aria hidden always have to be used on a container element such as
> >> > a
> >> > div?
> >> > A quick check on the ARIA specs did not really show me anything either
> >> > way, may be I was not interpreting something correctly.
> >> > Cheers
> >> > -Birkir
> >> > > >> > > >> > > >>
> >> > >> > >> > >>
> >
> >
> >
> > --
> > Dave Merrill
> > > > > > >
> > > >



--
Dave Merrill

From: Dave Merrill
Date: Sun, Aug 11 2013 5:41AM
Subject: Re: aria-hidden and NVDA, isn't this a bug?
← Previous message | No next message

Thanks for your reply Sailesh. As I said to Bryan, ARIA isn't my area of
expertise. Since it's not currently part of the major project I work on,
have no fear that we'll be abusing it.

Dave Merrill


On Sat, Aug 10, 2013 at 9:36 PM, Sailesh Panchang <
= EMAIL ADDRESS REMOVED = > wrote:

> Dave,
> If one uses <input type=hidden .../>, the form is not available to
> anyone including AT users.
> Bryan's reference is to use of aria-hidden on a form element or a link.
> This only emphasizes the need to recognize when to use WAI-ARIA:
> Use ARIA when something is not possible using native HTML simply
> because the feature is not there / is not supported by browsers and
> AT.
> It should not be used as a hack or a quick fix for an accessibility
> problem by the developer.
> Accessibility issues that are the result of deficient design / coding
> should be fixed by fixing the design / code.
> One should not regard ARIA as a way to circumvent such changes.
>
> A column with empty cells really has no place in a data table. It is
> an example of poor design.
> If developers are using it for housekeeping / other chores, it is
> quite wrong: they are introducing structural markup in a page without
> realizing how different users / technologies are interpreting that
> content even though it may make no difference visually.
> If number of columns / rows depend on data to be displayed, they
> should introduce rows / columns as needed programmatically and not use
> a fixed table design.
> It is alright for some cells in a row / column to be empty: it
> correctly represents semantics and data relationships.
>
> Some may argue that some AT do not render empty columns. Even a column
> whose cells contain images with null alt or no alt go unreported.
> That's a problem too.
> Should the AT take on the role of guessing what the content author
> intends? It does that sometimes after all AT is meant to mitigate
> problems in the environment for the end user.
> But developers should not burden the AT by poor design / coding practices.
> Regards,
> Sailesh Panchang
> Deque Systems
>
> On 8/10/13, Dave Merrill < = EMAIL ADDRESS REMOVED = > wrote:
> > @Birkir: Minor point, but I'm pretty sure it's invalid HTML to put a div
> > inside a list with the intent of creating a container for some items that
> > you can apply an attribute to (aria-hidden). The only item container
> > allowed there is <optgroup>, but that will have a visual effect of its
> own.
> > The div strategy may still "work", but it wouldn't surprise me if its
> > behavior was browser dependent.
> >
> > @Bryan: I'm a developer, not by any means an accessibility expert, but
> your
> > last paragraph surprises me. Are you saying that if a section of a form
> is
> > hidden according to the business rules in effect at the time, that's not
> > sufficient to remove the fields inside it from the tab order? If so, what
> > are you supposed to do, disable those fields too? I've never done that,
> and
> > I've never seen that behavior in standard browsers.
> >
> > Dave Merrill
> >
> >
> > On Sat, Aug 10, 2013 at 3:48 PM, Bryan Garaventa <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> This is sort of tricky.
> >>
> >> JAWS' ability to reevaluate the elements removed from the accessibility
> >> tree
> >> using aria-hidden may be useful, but it's also misleading.
> >>
> >> The use of aria-hidden doesn't actually change the elements in the DOM
> at
> >> all, meaning that they still exist within their native containers. Such
> >> as
> >> lists having the same number of LIs, and tables having the same number
> of
> >> TDs, regardless what is announced by the screen reader.
> >>
> >> So, if you use aria-hidden to simulate a properly formed data table
> >> structure by hiding extra cells, it is still an improperly formed data
> >> table
> >> in the browser, and will likely have accessibility issues for other ATs.
> >>
> >> The same is true for ULs, where lists are defined by the number of LIs
> >> within, and surrounding the LI tags with different container elements
> >> inside
> >> of the UL or OL may present different accessibility issues, regardless
> >> whether aria-hidden is applied.
> >>
> >> I suspect NVDA is evaluating the DOM directly for this information,
> which
> >> is
> >> why it is announcing these values. Perhaps one of the NVDA guys here can
> >> elaborate further to clarify.
> >>
> >> The use of aria-hidden to hide an element including all child elements
> >> should work on any element type, not just containers.
> >>
> >> Keep in mind that this doesn't effect the tab order of active elements
> at
> >> all. So, if you have an active element within the boundary of a
> container
> >> hidden via aria-hidden, it will still be in the tab order regardless,
> and
> >> will sound like a dead tab stop for screen reader users.
> >>
> >>
> >> ----- Original Message -----
> >> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> >> Sent: Saturday, August 10, 2013 12:17 PM
> >> Subject: [WebAIM] aria-hidden and NVDA, isn't this a bug?
> >>
> >>
> >> > Greetings wise ones
> >> >
> >> > Opinions needed and welcome.
> >> > I am experimenting with use of aria-hidden to hide lists/list items
> >> > and table cells.
> >> > This works nicely in Jaws, but not in NVDA.
> >> >
> >> > Starting with lists.
> >> > Applying aria-hidden on a list item
> >> > <code>
> >> > <ul>
> >> > <li>List item #1</li>
> >> > <li aria-hidden="true">Hidden item 1</li>
> >> > <li aria-hidden="true">Hidden item #2</li>
> >> > </ul>
> >> > </code>
> >> > NVDA respects the aria-hidden use for the list items themselves, but
> >> > announces, in the list summary: "list with 3 items", even if the list
> >> > only contains one, and the quick key to jump to next list item does
> >> > not work.
> >> > This happens both in IE10 and FF22.
> >> > Using role="presentation" along with the aria-hidden does not have any
> >> > effect.
> >> >
> >> > Even if the latter two list items are wrapped up in a div with
> >> > aria-hidden set to true, NVDA still announces the list as having two
> >> > items.
> >> >
> >> > Jaws recognizes both versions of the list as having just one item.
> >> > Similarly if a table cell is marked with aria-hidden Jaws ignores it,
> >> > but NVDA does not.
> >> > This can lead to serious navigation issues in tables with these cells,
> >> > since when inserted it forces an entire column and shifts all the
> >> > information to the right, creating a mismatch between column header
> >> > and the info they contain.
> >> > Just imagine a row with two columns.
> >> > First Name and Last Name.
> >> > If a td is inserted with aria-hidden="true", then the values, Jaws
> >> > announces the table as having two columns and two rows, and announces
> >> > values correctly.
> >> > NVDA announces table as having 3 columns and two rows and the table
> >> > navigation gets very messy actually.
> >> >
> >> > So, basically, is it my misinterpretation that aria-hidden should hide
> >> > its element as well as all info inside that element.
> >> > Does aria hidden always have to be used on a container element such as
> >> > a
> >> > div?
> >> > A quick check on the ARIA specs did not really show me anything either
> >> > way, may be I was not interpreting something correctly.
> >> > Cheers
> >> > -Birkir
> >> > > >> > > >> > > >>
> >> > >> > >> > >>
> >
> >
> >
> > --
> > Dave Merrill
> > > > > > > >
> > > >



--
Dave Merrill