E-mail List Archives

Search E-mail List Archives for

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

From: Angela French
Date: Tue, Jul 19 2016 3:48PM
Subject: please test my accordions
No previous message | Next message →

Hello,
I am hoping one or two of you that use screen readers could test this simple test page<http://www.dev.sbctc.edu/_testing/test-anchor-asset-1.aspx>; I have made. I'm not sure that the aria attributes are correct.

I'd like to confirm that each accordion opens and that the content inside is revealed. Secondly, I'd like to know if the link that is inside of Accordion 11 reveals the content that it is linking to that is inside of Accordion 12. This depends on jquery to inject changes and I'm just not convinced it is all working correctly for screen readers.

As always, I'm grateful for your assistance.



Angela French
Internet/Intranet Specialist
Washington State Board for Community and Technical Colleges
360-704-4316
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
www.sbctc.edu<;http://www.sbctc.edu/>;

From: Birkir R. Gunnarsson
Date: Tue, Jul 19 2016 4:08PM
Subject: Re: please test my accordions
← Previous message | Next message →

Hi Angela

This very pattern is going through an ARIA Authoring Practices review
and we are proposing a much simpler implementation for accordions.
Not to assume the conclusion of the review, but here are the roles
that I have used and recommended for effective and accessible
accordion implementation.
1. REmove all the tablist and tab roles (when using role="tab" make
sure you use it on the focusable/actionable element, not on its
parent).
This bad:
<li role="tab"><a href="#">Do something</a></li>
THis better
<li><a href="#" role="tab">Do something</a></li>

For accordions you don't need the tab or tablist roles.
2. The actionable item to expand or collapse the tab shouldn't point
anywhere, it should be a toggle control (you click it to expand or
collapse the tabpanel content).
In fact it is best to use buttons, but links are ok to, as long as
they don't point anywhere.
The buttons/toggle controls should have aria-expanded and aria-controls.
Make sure aria-expanded="false" is present in the html by default when
button controls collapsed content. This will ensure that screen
readers announce the state and users realize the function of the
control.

3. Use the region role and aria-labelledby (not aria-expanded) on the
content controlled by the buttons (basically replace tabpanel with
region and remove aria-expanded).

Example:
<button id="b1" aria-expanded="false" aria-controls="r1">Toggle
control 1</button>
<div role="region" aria-labelledby="b1" class="hidden">
Content for the accordion controlled by b1.
</div>

When expanded you just set aria-expanded on the button to true and
remove class="hidden" (assuming that class is display: none;".
-B


On 7/19/16, Angela French < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
> I am hoping one or two of you that use screen readers could test this simple
> test page<http://www.dev.sbctc.edu/_testing/test-anchor-asset-1.aspx>; I have
> made. I'm not sure that the aria attributes are correct.
>
> I'd like to confirm that each accordion opens and that the content inside is
> revealed. Secondly, I'd like to know if the link that is inside of
> Accordion 11 reveals the content that it is linking to that is inside of
> Accordion 12. This depends on jquery to inject changes and I'm just not
> convinced it is all working correctly for screen readers.
>
> As always, I'm grateful for your assistance.
>
>
>
> Angela French
> Internet/Intranet Specialist
> Washington State Board for Community and Technical Colleges
> 360-704-4316
> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> www.sbctc.edu<;http://www.sbctc.edu/>;
>
> > > > >


--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Tue, Jul 19 2016 4:10PM
Subject: Re: please test my accordions
← Previous message | Next message →

Yes, please don't use ARIA Tabs for accordions.

The ARIA Tab markup is causing accessibility issues in this example.

The use of ARIA Tab roles is no longer going to be a recommendation by the W3C for Accordions as previously documented in APG 1.0 because it presents too many issues across differing disability types and ATs, and instead as of the ARIA Authoring Practices Guide 1.1 revision will use this new design pattern instead:
https://lists.w3.org/Archives/Public/public-aria/2016Jul/0143.html



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Angela French
Date: Tue, Jul 19 2016 4:18PM
Subject: Re: please test my accordions
← Previous message | Next message →

Well this is disappointing. We have role="tabs" on existing accordions throughout our site.

Besides this use of role, do the accordions work? Are they perceivable and operable?

I ask because I'm trying to gauge how much remediation I'm going to need to make.

We have many other pages on our site that use accordions. Here is an example on the live site: http://www.sbctc.edu/for-employers/centers-of-excellence.aspx .

Angela French

From: Bryan Garaventa
Date: Tue, Jul 19 2016 4:41PM
Subject: Re: please test my accordions
← Previous message | Next message →

Unfortunately these accordions have all the same issues I previously documented at
https://www.w3.org/Bugs/Public/show_bug.cgi?id&254

Also, as an FYI about ARIA Tabs, the 'tab' role doesn't support focusable children as used here, since they are 'children presentational' as of ARIA 1.1. This is exposed visually in red using Visual ARIA when tabbing through the focusable elements.
( http://whatsock.com/training/matrices/visual-aria.htm )

All the best,
Bryan



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Angela French
Date: Wed, Jul 20 2016 11:17AM
Subject: Re: please test my accordions
← Previous message | Next message →

Bryan,
Can you explain to me please what is actually occurring on my test page as a result of using role="tab".
Can you also tell me when the APG 1.1 revision will be released?

Thank you,
Angela French

From: Bryan Garaventa
Date: Wed, Jul 20 2016 5:28PM
Subject: Re: please test my accordions
← Previous message | No next message

Hi,
In looking at your tabs, the following description is the same as documented at
https://www.w3.org/Bugs/Public/show_bug.cgi?id&254

Specifically, the following sections apply:

The use of ARIA Tab markup for accordions conflicts with documented layout structure for actual ARIA Tabs.
From a screen reader perspective, both sound exactly the same regardless of markup differences, because both use ARIA Tab markup to convey functionality.
As a result, it is impossible for screen reader users to identify the differences between an Accordion where content is rendered inline with the triggering element, and a Tab group where content is rendered after or adjacent to a list of tab controls, because both are identified as "Tab".
This also presents reading order issues for screen reader users, where if a Tab is activated for an accordion and content is rendered inline, it pushes all other Tabs below that point in the DOM reading order, making it appear that orphaned Tab controls are located elsewhere on the page, causing further confusion if an expanded Accordion panel includes an actual Tab group that also includes ARIA Tab markup where its content is rendered after the Tablist according to spec.

Additionally, regarding the specific markup though, the following is the triggering element as extracted from the original demo:

<div class="panel-heading" id="headingaccordion11" role="tab">
<h2><a aria-expanded="true" aria-controls="collapseaccordion11" href="#collapseaccordion11" data-toggle="collapse" data-parent="#accordion1"><span class="glyphicon glyphicon-plus-minus no-print" aria-hidden="true"></span>ID accordion11</a></h2>
</div>
 
Within this markup there are three different role types, a tab, a heading, and an expandable link, and a tab cannot support any embedded focusable elements like a link. The reason being that a tab is an interactive widget that is meant to receive focus, and it cannot be a tab, a heading, and an expandable link all at the same time. The use of ARIA Tab markup for such a construct is going to complicate your ability to use it and make it scale properly as you embed different levels of accordions. Moreover all supporting attributes for role=tab such as aria-selected, aria-expanded, aria-controls, and so on are only valid on the element with role=tab that must be either directly focusable or directly referenceable via aria-activedescendant on the focusable container with role=tablist.

To experience the difference in action, please test your implementation using JAWS and NVDA in IE11, Firefox, and Chrome on Windows, and using VoiceOver on iOS and observe how it sounds when using basic navigation on Windows such as using the Down arrow to go from top to bottom of the page, as well as when tabbing. Then compare this when using touch on iOS.

Now, please do the same on the following demo and see how they differ:
http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm
You can also download this for viewing offline at
http://whatsock.com/test/w3c/ARIA%20Accordions.zip

You can also use Visual ARIA on the second demo to see how the new design pattern uses different ARIA attributes instead of ARIA Tab roles to achieve this control type more accessibly across devices and platforms.

This should help better illustrate the differences both visually and with real testing data to observe in action.

The ARIA Authoring Practices Guide 1.0 has officially been retired already, and all future references as noted for ARIA 1.1 will point to the following resource location instead:
http://www.w3.org/TR/wai-aria-practices-1.1/

The Accordion section is what we are currently working on, using the second demo above as the design pattern to base the new Accordion section on in the near future.

Hopefully this helps explain things a bit.

Kind regards,
Bryan


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com