Two accordion examples, one basic and one of a group with only one open accordion

[smhigley]

Related to #1830

This is an example for the purpose of discussion: it demonstrates having two separate accordion examples; one is a basic set of independent accordions, and the other is a grouped accordion example with the restriction of only having one accordion open at a time.

This isn't ready to be merged or formally reviewed -- it's missing documentation updates and tests.

Basic accordion preview link
Group accordion preview link

Review checklist

• Editorial review by @mcking65
• Functional review by @shirsha
• Accessibility review on Windows by @shirsha
• Accessibility review on MacOS by @jongund
• Accessibility review on iOS/iPadOS by @jongund
• Accessibility review in general by @a11ydoer
• Code review by @jesdaigle
• Test review by @jesdaigle

---

Preview | Diff

---

Preview | Diff

[JAWS-test]

It seems to me that the Basic Example has no difference to Disclosure. I wonder if we need the same example under two different terms?

[shirsha]

Thanks @smhigley for the changes.
Following are few suggestion. These were existing from previous code

• Move the "+" and "-" before the accordion name so that users with screen magnifiers can see state easily.
• Place the accordions in an unorder list so that it improves the experience for screen reader users.
• Can we add note saying having the content under each accordion inside a labelled region is a best practice? Having too many landmarks will not help screen reader users. I recommend removing the markup related to region landmark.

[jongund]

@smhigley
On macOS BigSur (11.4) using Safari and VoiceOver, the button seems to be hidden inside the h3 when you use next or previous item commands. Basically it identifies the heading element and the label, but no information about the button or the state of aria-expanded. When I press the next item command I expected to go to the button, but instead it went to the region.

Works fine when you use the TAB key or using the rotor, just goes to the button element element, but no information about the button being disable when aria-disabled='true is set.

Also I think there needs to be some visual indication when the open region cannot be collapsed, since there is a visual affordance that it can be.

[shirsha]

I don't see aria-hidden attribute on Edge, Chrome browser (Windows OS). Jemma can see it in Mac OS.

[jongund]

@smhigley
Works fine on iOS 14.4.2, using VO with Safari. But like VO for macOS it does not provide information about the aria-disabled=true information.

[jongund]

@smhigley
At the APG meeting today is was suggested to remove the aria-required and aria-hidden from the standard form controls, since they are not needed for the accordion pattern and increase the amount of documentation and testing for the example.

I think we also need to add more of a description of the accordion behavior in each example, indicating whether one will always be open or not.

[jongund]

I don't see aria-hidden attribute on Edge, Chrome browser (Windows OS). Jemma can see it in Mac OS.

It is used to hide the "*" in the labels for the input[type=text'] controls in the Group accordion example.

[a11ydoer]

@smhigley will write the test procedure.

[a11ydoer]

@smhigley will complete testing code by early next week. Thanks so much, @smhigley

[a11ydoer]

@mcking65 I think this accordion would not be able to make it to APG 1.2. From quick testing using NVDA, there is mismatch between visual and screen reader annoucment. For example, the accordion was expanded visually but the screenreader says it is "unavailable expanded".

Furthermore, "Jump to" funtion was not implemented either.

[jongund]

@a11ydoer @mcking65 @smhigley There needs to be documentation of the use of aria-disabled and it should also be in the original source code for the group example.

Might want to change:
"The form can only have one step open at a time"
to
"The form has one step open at a time"

[JAWS-test]

@a11ydoer

For example, the accordion was expanded visually but the screenreader says it is "unavailable expanded".

This has to be that way because of aria-disabled=true, since it can only be opened but not closed. I don't see any error in this, but the match of screenreader output and visual representation.

The only problem is that the initial aria-disabled is missing. It is added only after the operation

[a11ydoer]

@JAWS-test thanks for great feedback! It makes sense. It seems that we need to work on aria-disabled more.

[smhigley]

@mcking65 I updated the roles, tests, and related example links. Let me know what you think of it now :)

[shirsha]

I will raise a separate issue for my suggestions.

[a11ydoer]

issue 974