E-mail List Archives

Search E-mail List Archives for

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

From: Alastair Campbell
Date: Thu, Aug 01 2013 2:41AM
Subject: building accessible javascript accordions?
No previous message | Next message →

Sorry to pickup an old thread, but I ran into some issues with the
accordion pattern.

Patrick H. Lauke wrote:
> it's worth having a look at the WAI ARIA authoring practices
> document, in particular the description of the accordion design pattern
> http://www.w3.org/WAI/PF/aria-practices/#accordion and the example
> provided http://www.oaa-accessibility.org/examplep/accordian1/

That seems to work well in an application context (where the 'content'
of the accordion is a form), but I'm getting issues when people need
to read the contents of each panel.

Taking that example, if you remove role="application" and have regular
HTML content in the panels, it works ok on VoiceOver (iOS/OSX), but
with NVDA (and I assume JAWs?) it is more difficult.

For example, you can browse (down arrow) to the accordion, you can
press down to go through all the headings and visible content (which
seems normal).You can select options, and as long as you avoid hitting
tab, all is good.

However, press tab and you invoke forms mode, where everything
changes. Arrowing down only moves between the tab headings, and you
have to navigate the 'content' with the tab key, which is only really
applicable for forms that don't have content.

Is this another case of: "ARIA is only indented for applications"?

That would be a shame, as show/hide in an accordion style is very
common and screen-reader users would benefit from the announcements
like 'expanded', but the switch of interaction style is very
confusing.

-Alastair

From: Paul J. Adam
Date: Thu, Aug 01 2013 8:06AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Role=application should likely be avoided. NVDA can manually ESCape from forms mode using the ESC key. Really all you need is aria-expanded=true/false.

Paul J. Adam
Accessibility Evangelist
www.deque.com

On Aug 1, 2013, at 3:41 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:

> Sorry to pickup an old thread, but I ran into some issues with the
> accordion pattern.
>
> Patrick H. Lauke wrote:
>> it's worth having a look at the WAI ARIA authoring practices
>> document, in particular the description of the accordion design pattern
>> http://www.w3.org/WAI/PF/aria-practices/#accordion and the example
>> provided http://www.oaa-accessibility.org/examplep/accordian1/
>
> That seems to work well in an application context (where the 'content'
> of the accordion is a form), but I'm getting issues when people need
> to read the contents of each panel.
>
> Taking that example, if you remove role="application" and have regular
> HTML content in the panels, it works ok on VoiceOver (iOS/OSX), but
> with NVDA (and I assume JAWs?) it is more difficult.
>
> For example, you can browse (down arrow) to the accordion, you can
> press down to go through all the headings and visible content (which
> seems normal).You can select options, and as long as you avoid hitting
> tab, all is good.
>
> However, press tab and you invoke forms mode, where everything
> changes. Arrowing down only moves between the tab headings, and you
> have to navigate the 'content' with the tab key, which is only really
> applicable for forms that don't have content.
>
> Is this another case of: "ARIA is only indented for applications"?
>
> That would be a shame, as show/hide in an accordion style is very
> common and screen-reader users would benefit from the announcements
> like 'expanded', but the switch of interaction style is very
> confusing.
>
> -Alastair
> > >

From: Alastair Campbell
Date: Thu, Aug 01 2013 8:19AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Paul J. Adam wrote:
> Role=application should likely be avoided.

Yep, I took it off for the example I was testing with.


> NVDA can manually ESCape from forms mode using the ESC key.

Yes (and I'm used to the sound effects for that now!), but even
without a role of application, it enters forms mode if you tab to an
accordion-heading. Then everything changes.


> Really all you need is aria-expanded=true/false.

Perhaps, but then you wouldn't be following the authoring practices
which dictate the actions for the arrow and tab keys.

-Alastair

From: Paul J. Adam
Date: Thu, Aug 01 2013 9:30AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

There's no WCAG requirement that says you have to follow certain keyboard interactions for your ARIA widgets right?

What's required is full keyboard control and updating the state. So as long as a user can focus on the UI element that controls the expanding/collapsing content and as long as you update the state of that element using whatever method you like, visually hidden text or aria-expanded, then you've met WCAG.

If the NVDA user does not need to be in forms mode then they can ESCape it.

Paul J. Adam
Accessibility Evangelist
www.deque.com

On Aug 1, 2013, at 9:19 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:

> Paul J. Adam wrote:
>> Role=application should likely be avoided.
>
> Yep, I took it off for the example I was testing with.
>
>
>> NVDA can manually ESCape from forms mode using the ESC key.
>
> Yes (and I'm used to the sound effects for that now!), but even
> without a role of application, it enters forms mode if you tab to an
> accordion-heading. Then everything changes.
>
>
>> Really all you need is aria-expanded=true/false.
>
> Perhaps, but then you wouldn't be following the authoring practices
> which dictate the actions for the arrow and tab keys.
>
> -Alastair
> > >

From: Alastair Campbell
Date: Thu, Aug 01 2013 10:09AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Paul J. Adam wrote:
> There's no WCAG requirement that says you have to follow certain keyboard interactions for your
> ARIA widgets right?

Personally I agree, but others believe that creating 'non standard'
implementations (according to the design patterns) will create more
confusion long term:
http://webaim.org/discussion/mail_thread?threadY14

I'm hoping we can get to some agreement about what to do for
non-application sites that use interactive features that benefit from
ARIA.

At the moment the best suggestion has been to include instructions at
the beginning of the widget, but I've had a hard time getting dev
teams to accept that, it looks hacky.

Perhaps we need a set of design patterns for non-application use of
ARIA attributes? For use in specific cases where it does not clash
with the application version.

-Alastair

From: Bryan Garaventa
Date: Thu, Aug 01 2013 10:45AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

I'm not really sure what the difficulty here is, an accordion is actually a
pretty simple component type, and it's not an ARIA widget. You can use ARIA
to make an accordion, but there is no such thing as an ARIA Accordion.

For example, I typically recommend making each triggering element either an
ARIA Toggle using role=button, aria-pressed=true/false, and
aria-expanded=true/false, or use offscreen text to indicate the role and
state, both of which work reliably.

You can see an example of this at
http://whatsock.com/tsg/Coding%20Arena/Accordions/Accordion%20(Internal%20Content)/demo.htm

Personally I'm not a fan of making an accordion have only one tab stop,
because it doesn't make any sense from a usability perspective. For example,
if the accordion includes form fields, you have to shift+tab all the way
back to the accordion in order to arrow to the next accordion node, in order
to begin the whole process over after expanding that node. It makes more
sense to simply keep the standard tab order of native active elements, and
just tab through the active elements of an accordion panel, then when you
reach the next accordion link, to either choose to expand that node or
continue past it.

It doesn't have to be complicated.







----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, August 01, 2013 9:09 AM
Subject: Re: [WebAIM] building accessible javascript accordions?


> Paul J. Adam wrote:
>> There's no WCAG requirement that says you have to follow certain keyboard
>> interactions for your
>> ARIA widgets right?
>
> Personally I agree, but others believe that creating 'non standard'
> implementations (according to the design patterns) will create more
> confusion long term:
> http://webaim.org/discussion/mail_thread?threadY14
>
> I'm hoping we can get to some agreement about what to do for
> non-application sites that use interactive features that benefit from
> ARIA.
>
> At the moment the best suggestion has been to include instructions at
> the beginning of the widget, but I've had a hard time getting dev
> teams to accept that, it looks hacky.
>
> Perhaps we need a set of design patterns for non-application use of
> ARIA attributes? For use in specific cases where it does not clash
> with the application version.
>
> -Alastair
> > >

From: Birkir R. Gunnarsson
Date: Thu, Aug 01 2013 1:11PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Another example can be found at:
http://www.3needs.org/en/testing/code/aria-expanded.html#

I don't think a keyboard interaction model is necessary for simple
accordian style menus, user simply activates a link or a button in the
usual way and it displays or hides content based on that interaction.
Cheers
-Birkir
Birkir Gunnarsson
Accessibility Subject Matter Expert | Deque Systems
www.deque.com

On 8/1/13, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> I'm not really sure what the difficulty here is, an accordion is actually a
>
> pretty simple component type, and it's not an ARIA widget. You can use ARIA
>
> to make an accordion, but there is no such thing as an ARIA Accordion.
>
> For example, I typically recommend making each triggering element either an
>
> ARIA Toggle using role=button, aria-pressed=true/false, and
> aria-expanded=true/false, or use offscreen text to indicate the role and
> state, both of which work reliably.
>
> You can see an example of this at
> http://whatsock.com/tsg/Coding%20Arena/Accordions/Accordion%20(Internal%20Content)/demo.htm
>
> Personally I'm not a fan of making an accordion have only one tab stop,
> because it doesn't make any sense from a usability perspective. For example,
>
> if the accordion includes form fields, you have to shift+tab all the way
> back to the accordion in order to arrow to the next accordion node, in order
>
> to begin the whole process over after expanding that node. It makes more
> sense to simply keep the standard tab order of native active elements, and
> just tab through the active elements of an accordion panel, then when you
> reach the next accordion link, to either choose to expand that node or
> continue past it.
>
> It doesn't have to be complicated.
>
>
>
>
>
>
>
> ----- Original Message -----
> From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, August 01, 2013 9:09 AM
> Subject: Re: [WebAIM] building accessible javascript accordions?
>
>
>> Paul J. Adam wrote:
>>> There's no WCAG requirement that says you have to follow certain keyboard
>>>
>>> interactions for your
>>> ARIA widgets right?
>>
>> Personally I agree, but others believe that creating 'non standard'
>> implementations (according to the design patterns) will create more
>> confusion long term:
>> http://webaim.org/discussion/mail_thread?threadY14
>>
>> I'm hoping we can get to some agreement about what to do for
>> non-application sites that use interactive features that benefit from
>> ARIA.
>>
>> At the moment the best suggestion has been to include instructions at
>> the beginning of the widget, but I've had a hard time getting dev
>> teams to accept that, it looks hacky.
>>
>> Perhaps we need a set of design patterns for non-application use of
>> ARIA attributes? For use in specific cases where it does not clash
>> with the application version.
>>
>> -Alastair
>> >> >> >
> > > >

From: Alastair Campbell
Date: Thu, Aug 01 2013 3:22PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Bryan Garaventa wrote:
> For example, I typically recommend making each triggering element either an
> ARIA Toggle using role=button, aria-pressed=true/false, and
> aria-expanded=true/false, or use offscreen text to indicate the role and
> state, both of which work reliably.

Thanks, that makes sense.


> Personally I'm not a fan of making an accordion have only one tab stop,
> because it doesn't make any sense from a usability perspective.

Agree, but for a regular user I would apply the same logic to tabs as
well though. You know the difference, but what signals the change of
model for a regular user?

Cheers,

-Alastair

From: Bryan Garaventa
Date: Thu, Aug 01 2013 4:36PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

I agree that Tabs have a similar concept, at least as far as expanding and
collapsing goes, but there are differences. For instance, a group of Tabs
should be grouped together and share an insertion point, or at least have
the insertion points be adjacent to the Tab group of triggering elements,
such as directly after.

E.G

*Group of tab links*
*Insertion point container*

As opposed to an Accordion where insertion points are inline with the
triggering element.

E.G

*Accordion link one*
*Accordion one content container*
*Accordion link two*
*Accordion two content container*

The first makes more sense with one tab stop, because you can make your
selection then press tab to navigate directly into your desired content.

The second does not, because you are using the native DOM order to control
the focus movement in a logical manner between each section.


----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, August 01, 2013 2:22 PM
Subject: Re: [WebAIM] building accessible javascript accordions?


> Bryan Garaventa wrote:
>> For example, I typically recommend making each triggering element either
>> an
>> ARIA Toggle using role=button, aria-pressed=true/false, and
>> aria-expanded=true/false, or use offscreen text to indicate the role and
>> state, both of which work reliably.
>
> Thanks, that makes sense.
>
>
>> Personally I'm not a fan of making an accordion have only one tab stop,
>> because it doesn't make any sense from a usability perspective.
>
> Agree, but for a regular user I would apply the same logic to tabs as
> well though. You know the difference, but what signals the change of
> model for a regular user?
>
> Cheers,
>
> -Alastair
> > >

From: Roger Hudson
Date: Thu, Aug 01 2013 5:20PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Very interesting discussion.

If a button (accordion) causes a section of a page to be displayed (or
hidden) should you advise a screen reader user that this is going to happen?
This would clearly seem to be a good idea, but I am curious to know where a
failure to provide this information would sit in WCAG 2.0. I can see how
knowing if something is selected or not (or expanded/collapsed) falls under
4.1.2, but what about providing advanced warning of this behaviour?

Thanks,

Roger

From: Steve Green
Date: Thu, Aug 01 2013 6:39PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

There is a difference between accordion menus and accordion content. Our experience of user testing is that screen reader users can usually cope with accordion menus, if only because they can ignore the menu and select the top-level menu item as long as the resulting page contains the same links that are in the menu.

However, such redundancy does not exist with accordion content, and users frequently have no idea what is happening when they operate an accordion link. We have yet to test any accordion content that has ARIA markup so I cannot comment on how effective this might be. However, the previous discussions are not encouraging.

Steve Green

From: Léonie Watson
Date: Fri, Aug 02 2013 2:39AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Alastair Campbell wrote:
"Agree, but for a regular user I would apply the same logic to tabs as well
though. You know the difference, but what signals the change of model for a
regular user?"

Isn't that down to the design and the visual cues? The ARIA should provide
the same cues, so everyone understands the necessary interaction.

Taking a simple example, if it looks like a button, or your AT tells you
it's a button, you hit it like a button.

This is the real crux of the matter. Everyone knows what a button is and
what to do with it. People are far more confused by the more complex design
patterns like tabs or accordions though.

The real question (to my mind) is how do we arrive at the point where people
are familiar with these interactions? Most people don't bat an eyelid at a
tabbed UI in a software application, but put it in the middle of a website
and it becomes a problem.

So in some respects we're back at one of the oldest UX conundrums. Do we
expect people to learn for themselves, do we provide educational materials
to help them learn, or do we provide easier ways of accomplishing the task
at hand? Then, whichever of those we choose, how do we do it effectively?

Léonie.

From: Alastair Campbell
Date: Fri, Aug 02 2013 2:40AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Hi Bryan,

I see your point, I guess I'm trying to work out how a user would know
what they have encountered (imagine getting to a site the first time),
and therefore how they should interact with it. Both of your scenarios
start off as a bunch of links (which may have aria-pressed or
expanded), but act quite differently.
Tab and arrows work differently in each case, how does a user know what to do?

Steve: I'm not sure what you mean by accordion menus vs content? I
think it would be worth testing an ARIA example before concluding
anything, if it is still problematic then moving the keyboard focus to
the newly opened content would probably overcome that issue.

Roger: Good point, it seems like there could be an equivalent to 4.1.2
under the "understandable" principle in WCAG for this, or, perhaps it
is something for the UA guidelines instead?

My concern at the moment is that it's very easy for developers to
(rightly or wrongly) use ARIA markup at several levels, from easy-wins
like landmarks, through minor uses of things like has-poppup, to the
full design patterns.

Firstly, there doesn't seem to be much guidance on 'how much' ARIA to
use for different cases (although I might be missing something, please
let me know!). For example, when Patrick pointed to the accordion
example, I fell into the trap of thinking I should use the full tabs
design pattern. (No criticism Patrick, I fell for it!)

Secondly, there doesn't seem to be a way of signalling to users when
the (current) standard keyboard controls change. This is especially an
issue for keyboard-only sighted users who use up/down to scroll the
screen, and screen readers where up/down arrows are used for browsing.
It isn't such an issue for VoiceOver users as the browse controls use
modifier keys.

Cheers,

-Alastair

From: Alastair Campbell
Date: Fri, Aug 02 2013 4:06AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Léonie Watson wrote:
> Isn't that down to the design and the visual cues? The ARIA should provide
> the same cues, so everyone understands the necessary interaction.
>
> Taking a simple example, if it looks like a button, or your AT tells you
> it's a button, you hit it like a button.

Agreed, but alot of the ARIA patterns are for non-standard
interactions. Taking the tabs example, in the visual + mouse scenario
you click a tab and see something open.

In the screen reader scenario you either:
- Browse to the tabs via arrows or tabbing, and select a tab, which
may then do nothing noticeable without you browsing around to find the
new content. (Non-ARIA)
- Browse to the tabs, get notified that it is a tabset and has
expandable content, and select one. At that point the arrow keys now
switch tabs instead of browsing, and the tab key may take you past the
new content, or not, depending on where the next focusable element is.

There doesn't seem to be a middle ground, or if there is, it is not
clear when to use what.


> The real question (to my mind) is how do we arrive at the point where people
> are familiar with these interactions? Most people don't bat an eyelid at a
> tabbed UI in a software application, but put it in the middle of a website
> and it becomes a problem.

I think the problem is the switch of interaction style, or rather,
knowing when it has switched. I don't use much software with screen
readers (apart from VO which works differently), how does the 'browse'
interaction work for software?
Do you get situations where you read content using arrows, and then
those same controls work differently in a different widget?

Maybe I'm being harsh on this because I use VoiceOver more which uses
modifier keys when browsing (so doesn't trigger the switch of
interface) and it's then more confusing for me on Windows
screenreaders.

However, I've seen regular users get very confused by this as well, so
I think it's a real issue.


> So in some respects we're back at one of the oldest UX conundrums. Do we
> expect people to learn for themselves, do we provide educational materials
> to help them learn, or do we provide easier ways of accomplishing the task
> at hand? Then, whichever of those we choose, how do we do it effectively?

I would be all for education if we could say when it applies, but
there doesn't seem to be a consistent answer for developers or users.

-Alastair

From: Bryan Garaventa
Date: Fri, Aug 02 2013 11:02AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

I understand the confusion, and unfortunately it doesn't help that many
public references use these terms inappropriately.

An ARIA Widget is a component that is specifically mapped in the
accessibility tree within the browser, and all valid ARIA Widget types are
defined at
http://www.w3.org/TR/wai-aria/roles
Which include Menu, Tab, Slider, Listbox, Radio, Button, Checkbox, etc. If a
particular widget type is not listed with a specific role here, for a
specific interaction type, then it's not an ARIA Widget.

The link you referenced at
http://www.w3.org/WAI/PF/aria-practices/#accordion
Is actually an interaction design, also known as a pattern design, that
simply outlines how a particular component type can be constructed. This
component is not explicitly mapped in the accessibility tree however, so it
is not an ARIA Widget.

Unfortunately the W3C documentation for building the accordion using
role=tablist and role=tab is totally incorrect, and is guaranteed to cause
accessibility issues for screen reader users, because it breaks the paradigm
that delineates the differing functionalities between a Tab control versus
an Accordion control, which are not the same thing. When role=tab is used
for an accordion, it is literally impossible for screen reader users to
detect the difference between them, when the accordion appears to be a
broken Tab control, since both say "tab". The problem with accordions is
that, for them to work effectively, they cannot have one tab stop, because
the accordion content is inline with the triggering element, effectively
breaking up any so called Tab association grouping between them in the
reading order.

These misconceptions are largely why we have so many implementations that
don't work properly for Assistive Technology users.

I discuss this issue in both the Accordion and ARIA Tab sections at
http://whatsock.com/tsg
Where all of the AccDC TSG interaction designs have successfully been tested
using:
The keyboard with no screen reader running.
NVDA and JAWS 11 through 14 in IE8 using Win XP.
NVDA and JAWS 12 through 14 in IE 9 and 10 using Win7.
NVDA and JAWS 14 in IE 10 using Win8.
NVDA and JAWS 12 through 14 in FF using Win XP, Win7, and Win8.
Voiceover in Safari using iOS on iPhone/iPad.

There are always going to be some differences, such as JAWS working best in
IE, and NVDA working best in FF, but these are the most reliable interaction
designs I was able to construct, which is a culmination of four years of
constant testing and development.

I'll include the WebAim group if anyone wants to add feedback.



----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, August 02, 2013 3:12 AM
Subject: Re: [WebAIM] building accessible javascript accordions?


> Bryan Garaventa wrote:
>> I'm not really sure what the difficulty here is, an accordion is actually
>> a
>> pretty simple component type, and it's not an ARIA widget. You can use
>> ARIA
>> to make an accordion, but there is no such thing as an ARIA Accordion.
>
> Hi Bryan,
>
> Minor point (so off list), but if there is an accordion pattern do you
> not consider that an ARIA widget?
> http://www.w3.org/WAI/PF/aria-practices/#accordion
>
> It seems that it is distinguished by a role of tablist and having
> aria-multiselectable="true".
>
> In most cases I prefer the approach you suggested, it's just when to
> recommend each approach that I'm struggling with...
>
> -Alastair

From: Alastair Campbell
Date: Fri, Aug 02 2013 4:42PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Wow, thanks Bryan.

Did I manage to stumble into the worst case straight off, or are there
plenty more?? ;-)

I've been in user-research land for a couple of years but I'm getting
stuck into the docs again now, I'll be sure to keep AccDC TSG to hand
as I do.

When you say testing, do you mean UAT style "does it work as
expected", and/or regular users trying tasks?

Both are useful, I'm just trying to gauge where the core interaction
issues might be, separately from the confusion for developers.

Kind regards,

-Alastair

From: Bryan Garaventa
Date: Sat, Aug 03 2013 12:37PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

No problem. I found that, if the interactive coding for particular design
patterns isn't provided, it is extremely difficult to accurately gage the
accessibility and usability of the component.

So, this is what the AccDC TSG is designed to do, to establish a functional
baseline that is proven to be accessible through comprehensive accessibility
testing.

When I refer to testing, I mean accessibility testing for screen reader and
keyboard only users, for voice navigation users via common keyboard
interaction commands, and for standard sighted users, all of which are
accounted for.

The live pages are all linked within the component sections, so they can
easily be tested by others as well.

----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, August 02, 2013 3:42 PM
Subject: Re: [WebAIM] building accessible javascript accordions?


> Wow, thanks Bryan.
>
> Did I manage to stumble into the worst case straight off, or are there
> plenty more?? ;-)
>
> I've been in user-research land for a couple of years but I'm getting
> stuck into the docs again now, I'll be sure to keep AccDC TSG to hand
> as I do.
>
> When you say testing, do you mean UAT style "does it work as
> expected", and/or regular users trying tasks?
>
> Both are useful, I'm just trying to gauge where the core interaction
> issues might be, separately from the confusion for developers.
>
> Kind regards,
>
> -Alastair
> > >

From: James Nurthen
Date: Mon, Aug 05 2013 12:23PM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Bryan,
As you are stating that the information in the W3C document is totally
incorrect have you submitted a comment to the W3C with this information?
Regards,
James


On Fri, Aug 2, 2013 at 10:02 AM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> I understand the confusion, and unfortunately it doesn't help that many
> public references use these terms inappropriately.
>
> An ARIA Widget is a component that is specifically mapped in the
> accessibility tree within the browser, and all valid ARIA Widget types are
> defined at
> http://www.w3.org/TR/wai-aria/roles
> Which include Menu, Tab, Slider, Listbox, Radio, Button, Checkbox, etc. If
> a
> particular widget type is not listed with a specific role here, for a
> specific interaction type, then it's not an ARIA Widget.
>
> The link you referenced at
> http://www.w3.org/WAI/PF/aria-practices/#accordion
> Is actually an interaction design, also known as a pattern design, that
> simply outlines how a particular component type can be constructed. This
> component is not explicitly mapped in the accessibility tree however, so it
> is not an ARIA Widget.
>
> Unfortunately the W3C documentation for building the accordion using
> role=tablist and role=tab is totally incorrect, and is guaranteed to cause
> accessibility issues for screen reader users, because it breaks the
> paradigm
> that delineates the differing functionalities between a Tab control versus
> an Accordion control, which are not the same thing. When role=tab is used
> for an accordion, it is literally impossible for screen reader users to
> detect the difference between them, when the accordion appears to be a
> broken Tab control, since both say "tab". The problem with accordions is
> that, for them to work effectively, they cannot have one tab stop, because
> the accordion content is inline with the triggering element, effectively
> breaking up any so called Tab association grouping between them in the
> reading order.
>
> These misconceptions are largely why we have so many implementations that
> don't work properly for Assistive Technology users.
>
> I discuss this issue in both the Accordion and ARIA Tab sections at
> http://whatsock.com/tsg
> Where all of the AccDC TSG interaction designs have successfully been
> tested
> using:
> The keyboard with no screen reader running.
> NVDA and JAWS 11 through 14 in IE8 using Win XP.
> NVDA and JAWS 12 through 14 in IE 9 and 10 using Win7.
> NVDA and JAWS 14 in IE 10 using Win8.
> NVDA and JAWS 12 through 14 in FF using Win XP, Win7, and Win8.
> Voiceover in Safari using iOS on iPhone/iPad.
>
> There are always going to be some differences, such as JAWS working best in
> IE, and NVDA working best in FF, but these are the most reliable
> interaction
> designs I was able to construct, which is a culmination of four years of
> constant testing and development.
>
> I'll include the WebAim group if anyone wants to add feedback.
>
>
>
> ----- Original Message -----
> From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
> Sent: Friday, August 02, 2013 3:12 AM
> Subject: Re: [WebAIM] building accessible javascript accordions?
>
>
> > Bryan Garaventa wrote:
> >> I'm not really sure what the difficulty here is, an accordion is
> actually
> >> a
> >> pretty simple component type, and it's not an ARIA widget. You can use
> >> ARIA
> >> to make an accordion, but there is no such thing as an ARIA Accordion.
> >
> > Hi Bryan,
> >
> > Minor point (so off list), but if there is an accordion pattern do you
> > not consider that an ARIA widget?
> > http://www.w3.org/WAI/PF/aria-practices/#accordion
> >
> > It seems that it is distinguished by a role of tablist and having
> > aria-multiselectable="true".
> >
> > In most cases I prefer the approach you suggested, it's just when to
> > recommend each approach that I'm struggling with...
> >
> > -Alastair
>
> > > >

From: Alastair Campbell
Date: Tue, Aug 06 2013 5:33AM
Subject: Re: Fwd: building accessible javascript accordions?
← Previous message | Next message →

Léonie Watson wrote:
> The role of tab causes screen readers (with appropriate ARIA support) to
> announce "tab". That's the cue to switch to using the left/right cursor keys
> to navigate.

I've been reading up on the JAWs and NVDA docs to try and find any
reference to that, and I'm struggling. How would regular users know
about it?

Left/right generally reads by character, and the only reference to
"tabs" in the user-docs that I can find is for the tab key.

Admittedly I have a very web-focused outlook, but it's no wonder that
a regular (non technical NVDA) user in testing exclaimed "it said tab,
so I pressed tab!".

After reading the Freedom Scientific ARIA doc, the ARIA tab-pattern
should definitely not be used for accordions unless you use
role="document" for any non-form content, as it doesn't expect content
in that scenario.


> It's the same cue that screen readers give when encountering a
> tabbed interface in a software application.

Perhaps a different cue is needed, as it might be people are not
expecting that in a website?

-Alastair

From: Léonie Watson
Date: Tue, Aug 06 2013 7:16AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Alastair Campbell wrote:
"Léonie Watson wrote:
> The role of tab causes screen readers (with appropriate ARIA support)
> to announce "tab". That's the cue to switch to using the left/right
> cursor keys to navigate.

I've been reading up on the JAWs and NVDA docs to try and find any reference
to that, and I'm struggling. How would regular users know about it?"

There is definitely much more that all the screen reader vendors could do to
help people learn about these features.

"Admittedly I have a very web-focused outlook, but it's no wonder that a
regular (non technical NVDA) user in testing exclaimed "it said tab, so I
pressed tab!"."

Which is interesting because it was taken as an instruction. Most screen
readers report a link as a link, a table as a table, a list as a list and so
forth. It's logical that a tab would therefore be reported as a tab isn't
it?

"Perhaps a different cue is needed, as it might be people are not expecting
that in a website?"

I'd be cautious about suggesting that. It would be difficult to find a
suitable cue, it almost certainly wouldn't be consistently applied across
screen readers, and it probably wouldn't match with the visual manifestation
which would lead to confusion when collaborating with sighted people.

The problem is how do people learn about these features? Typical
experimentation strategies aren't always successful, there is little
documentation available and people rarely read it when it is.

This isn't a new problem. Do we put a text resizer on the page, do we
provide information on using the browser to resize text, do we look to AT
vendors or third parties to provide the information on how to resize text.

Léonie.

From: Birkir R. Gunnarsson
Date: Tue, Aug 06 2013 7:19AM
Subject: Re: Fwd: building accessible javascript accordions?
← Previous message | Next message →

I believe there are more general problems with the labeling and
recognition of widgets and other UI components on webpages in general,
and that it is something that requires clarity all the way from coding
to end user experience.
Tabs on websites, as I understand it, look like tabs on desktop apps,
which look like tabs on physical folders.
I had never heard the word tab as a Jaws/NVDA user in the desktop
environment, at least not that I noticed, the word "menu" is always
used for your typical desktop menus.
I still do not know the difference between tabs and a menubar.

Similarly sliders are visual things that, I believe, indicate how to
interact with them, probably because visually they remind people of
how to work physical sliders. screen readers do not announce them as
sliders, so how is the blind end user to know it is a slider and get
the subsequent idea that using the arrow keys is the natural way to
select values on the sliding scale.

It wasn't until Bryan's excellent explanation on the AccDC website
that I fully understood the difference between tabs and accordians.
I have never com across a spin button so I am not sure how they are
handled by screen readers, but I would be surprised if they are
announced as such.
A screen reader cannot know about carousels, there is no specific
carousel role, but may be they can use heuristics to warn the user
that they are entering a section of what appears to be auto updating
content (when it is auto updating).

As for simpler examples of this disconnect between visual appearance
and screen reader presentation:
Often we might let it slide, as accessibility testers, when a button
is implemented and presented as a link to screen readers, even when it
is clearly styled to look like a button. at a glance this may seem
like a non-issue, they functionally work the same way, are keyboard
accessible and are trigger the same way (at lesat for people who
default to the enter key to activate all components, that includes
myself).
But imagine a blind customer calling in to web support or customer
service and using the screen reader's to search for buttons (say the
"b" key), it won't work.
Similarly the role of a button is slightly different from a link, and
there are fewer buttons on a website, which makes it easier for the
user to, say, sign up for the email list, order the flight or check
out of the shopping card. When these are presented as links they blend
in with the other 984 links on the page.

aria-expanded is announced as expanded by Jaws, "open" by NVDA.

All of these individually may be small things, but when taken
together, it is hard for us to expect the end user armed with nothing
but a screen reader (and according to our survey of 350 users in the
spring only 20% of these people get any formal training on how to
browse the web with their screen reader) to understand and interact
with all of these awesome components, despite the best efforts of the
developers to make them keyboard accessible and aria-enabled.

This is my motivation for creating the Cognosco project, something
that will be advertised later on and hopefully will be online within a
couple of months. I am hoping that an online resource can help educate
users about these components, explain the most common ones, their
origin, their visual appearance and how they are announced, or not, by
screenreaders.
It is up to the vendors to interpret aria roles consistently and
clearly, such as announcing sliders as sliders (I have not seen that).
For the author, I am often tempted, and I do it as a best practice or
usability, to recommend that appropriate role is used and even that
authors place a div with an area region with a descriptive aria-label
be used (such as "carousel" "slider" "spintbutton" etc.) around the
widget to indicate the type of the UI component being used
non-visually.
The web is getting more powerful, but also more complex and it places
more demands on all of us.
I still believe that the end user and the end user training are
powerful components that may have been under represented in the
business of making the web accessible. We cannot place all the
accessibility burden on the mainstream developers who have a thousand
other things to worry about. The best they can do is code to standards
and make sure the a.t. software has access to the information.
Cheers
-Birkir

Birkir Gunnarsson
Accessibility Subject Matter Expert | Deque Systems
http://www.deque.com

On 8/6/13, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
> Léonie Watson wrote:
>> The role of tab causes screen readers (with appropriate ARIA support) to
>> announce "tab". That's the cue to switch to using the left/right cursor
>> keys
>> to navigate.
>
> I've been reading up on the JAWs and NVDA docs to try and find any
> reference to that, and I'm struggling. How would regular users know
> about it?
>
> Left/right generally reads by character, and the only reference to
> "tabs" in the user-docs that I can find is for the tab key.
>
> Admittedly I have a very web-focused outlook, but it's no wonder that
> a regular (non technical NVDA) user in testing exclaimed "it said tab,
> so I pressed tab!".
>
> After reading the Freedom Scientific ARIA doc, the ARIA tab-pattern
> should definitely not be used for accordions unless you use
> role="document" for any non-form content, as it doesn't expect content
> in that scenario.
>
>
>> It's the same cue that screen readers give when encountering a
>> tabbed interface in a software application.
>
> Perhaps a different cue is needed, as it might be people are not
> expecting that in a website?
>
> -Alastair
> > > >

From: Bryan Garaventa
Date: Tue, Aug 06 2013 10:43AM
Subject: Re: Fwd: building accessible javascript accordions?
← Previous message | Next message →

Hi, just to clarify "I had never heard the word tab as a Jaws/NVDA user in
the desktop"

The logic behind this component is based on the Windows MSAA/UIA Tab
component type, which is what the functionality is supposed to mimic.

You can see an example of this in the desktop environment by opening
Internet Options through the Control Panel, or by opening Options from the
Tools menu in Internet Explorer.

You will see the Tab group there, such as "General", "Security", etc, all of
which are identified as 'tab' when you use the arrow keys to navigate
between them.



----- Original Message -----
From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 06, 2013 6:19 AM
Subject: Re: [WebAIM] Fwd: building accessible javascript accordions?


I believe there are more general problems with the labeling and
recognition of widgets and other UI components on webpages in general,
and that it is something that requires clarity all the way from coding
to end user experience.
Tabs on websites, as I understand it, look like tabs on desktop apps,
which look like tabs on physical folders.
I had never heard the word tab as a Jaws/NVDA user in the desktop
environment, at least not that I noticed, the word "menu" is always
used for your typical desktop menus.
I still do not know the difference between tabs and a menubar.

Similarly sliders are visual things that, I believe, indicate how to
interact with them, probably because visually they remind people of
how to work physical sliders. screen readers do not announce them as
sliders, so how is the blind end user to know it is a slider and get
the subsequent idea that using the arrow keys is the natural way to
select values on the sliding scale.

It wasn't until Bryan's excellent explanation on the AccDC website
that I fully understood the difference between tabs and accordians.
I have never com across a spin button so I am not sure how they are
handled by screen readers, but I would be surprised if they are
announced as such.
A screen reader cannot know about carousels, there is no specific
carousel role, but may be they can use heuristics to warn the user
that they are entering a section of what appears to be auto updating
content (when it is auto updating).

As for simpler examples of this disconnect between visual appearance
and screen reader presentation:
Often we might let it slide, as accessibility testers, when a button
is implemented and presented as a link to screen readers, even when it
is clearly styled to look like a button. at a glance this may seem
like a non-issue, they functionally work the same way, are keyboard
accessible and are trigger the same way (at lesat for people who
default to the enter key to activate all components, that includes
myself).
But imagine a blind customer calling in to web support or customer
service and using the screen reader's to search for buttons (say the
"b" key), it won't work.
Similarly the role of a button is slightly different from a link, and
there are fewer buttons on a website, which makes it easier for the
user to, say, sign up for the email list, order the flight or check
out of the shopping card. When these are presented as links they blend
in with the other 984 links on the page.

aria-expanded is announced as expanded by Jaws, "open" by NVDA.

All of these individually may be small things, but when taken
together, it is hard for us to expect the end user armed with nothing
but a screen reader (and according to our survey of 350 users in the
spring only 20% of these people get any formal training on how to
browse the web with their screen reader) to understand and interact
with all of these awesome components, despite the best efforts of the
developers to make them keyboard accessible and aria-enabled.

This is my motivation for creating the Cognosco project, something
that will be advertised later on and hopefully will be online within a
couple of months. I am hoping that an online resource can help educate
users about these components, explain the most common ones, their
origin, their visual appearance and how they are announced, or not, by
screenreaders.
It is up to the vendors to interpret aria roles consistently and
clearly, such as announcing sliders as sliders (I have not seen that).
For the author, I am often tempted, and I do it as a best practice or
usability, to recommend that appropriate role is used and even that
authors place a div with an area region with a descriptive aria-label
be used (such as "carousel" "slider" "spintbutton" etc.) around the
widget to indicate the type of the UI component being used
non-visually.
The web is getting more powerful, but also more complex and it places
more demands on all of us.
I still believe that the end user and the end user training are
powerful components that may have been under represented in the
business of making the web accessible. We cannot place all the
accessibility burden on the mainstream developers who have a thousand
other things to worry about. The best they can do is code to standards
and make sure the a.t. software has access to the information.
Cheers
-Birkir

Birkir Gunnarsson
Accessibility Subject Matter Expert | Deque Systems
http://www.deque.com

On 8/6/13, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
> Léonie Watson wrote:
>> The role of tab causes screen readers (with appropriate ARIA support) to
>> announce "tab". That's the cue to switch to using the left/right cursor
>> keys
>> to navigate.
>
> I've been reading up on the JAWs and NVDA docs to try and find any
> reference to that, and I'm struggling. How would regular users know
> about it?
>
> Left/right generally reads by character, and the only reference to
> "tabs" in the user-docs that I can find is for the tab key.
>
> Admittedly I have a very web-focused outlook, but it's no wonder that
> a regular (non technical NVDA) user in testing exclaimed "it said tab,
> so I pressed tab!".
>
> After reading the Freedom Scientific ARIA doc, the ARIA tab-pattern
> should definitely not be used for accordions unless you use
> role="document" for any non-form content, as it doesn't expect content
> in that scenario.
>
>
>> It's the same cue that screen readers give when encountering a
>> tabbed interface in a software application.
>
> Perhaps a different cue is needed, as it might be people are not
> expecting that in a website?
>
> -Alastair
> > > >

From: Bourne, Sarah (ITD)
Date: Wed, Aug 07 2013 9:18AM
Subject: Re: building accessible javascript accordions?
← Previous message | Next message →

Alastair Campbell wrote:
Admittedly I have a very web-focused outlook, but it's no wonder that a regular (non technical NVDA) user in testing exclaimed "it said tab, so I pressed tab!".
Léonie Watson wrote:
Which is interesting because it was taken as an instruction. Most screen readers report a link as a link, a table as a table, a list as a list and so forth. It's logical that a tab would therefore be reported as a tab isn't it?

I think the difference here is that "tab" is both a noun and a verb. Think of how many instructions say "Tab to [some location]." Without doing some elaborate research project, I suspect the verb (to tab) is used more than the noun (a tab). Silly English language! Perhaps screen readers need to have a more verbose label: "a tab"? "tab link"? "content tab"?

("Link" is used as a verb, too, but only by content-creator types. A regular user is not likely to think that a SR announcing "link" meant they had to create a link.)

sb
Sarah E. Bourne
Director of Assistive Technology &
Mass.Gov Chief Technology Strategist
Information Technology Division
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/itd

From: Alastair Campbell
Date: Wed, Aug 07 2013 10:51AM
Subject: Re: building accessible javascript accordions?
← Previous message | No next message

Sarah Bourne wrote:
> I think the difference here is that "tab" is both a noun and a verb.

That certainly exacerbates the issue, but I think there is a core
issue that users are not expecting a different set of controls.

I'm somewhat reminded of accesskeys as the default controls of the
screenreader are being over-ridden. VoiceOver of OSX (generally)
avoids the issues because you navigate with modifier keys as well as
the arrow keys, so you sort of bypass the imposed controls.

I'm not trying to be critical of the WAI-ARIA design patterns (I'm not
sure how else it could be done), but there is a *massive* gap in
understanding at the moment. Both for developers (how much to apply)
and users (when do the controls change).

I sense a documentation project coming on...

-Alastair