E-mail List Archives

Search E-mail List Archives for

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

From: Steve Green
Date: Thu, Jun 15 2023 6:20AM
Subject: Accordion design patterns
No previous message | Next message →

I have been looking at numerous accordion design patterns such as W3C, GOV.UK Design System and Whatsock, and they are all very similar. Each accordion section looks pretty much like this:

<h2><button id="foo" aria-expanded="true" aria-controls="bar">Section name</button></h2>
<div id="bar" role="region" aria-labelledby="foo">Section content</div>

Can anyone explain the rationale or requirement for the role="region" aria-labelledby="foo" attributes? I can't find anything in the ARIA specification that requires them.

In terms of the screen reader user experience, after opening an accordion section the section name is announced before the section content. This behaviour is caused by the "aria-labelledby" attribute and seems unnecessary since the section name would have been announced before the button was operated. If the section name is more than a few words, this behaviour is extremely annoying.

My inclination is to advise clients to omit the role="region" aria-labelledby="foo" attributes, but I want to be sure this would not introduce a WCAG non-conformance or impair the user experience.

Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
 
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2

From: Patrick H. Lauke
Date: Thu, Jun 15 2023 7:27AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

On 15/06/2023 13:20, Steve Green wrote:
...
> Can anyone explain the rationale or requirement for the role="region" aria-labelledby="foo" attributes? I can't find anything in the ARIA specification that requires them.

I wouldn't say this is *required* (neither by the ARIA spec, nor WCAG),
but it's more about best practice.

> In terms of the screen reader user experience, after opening an accordion section the section name is announced before the section content. This behaviour is caused by the "aria-labelledby" attribute and seems unnecessary since the section name would have been announced before the button was operated. If the section name is more than a few words, this behaviour is extremely annoying.
>
> My inclination is to advise clients to omit the role="region" aria-labelledby="foo" attributes, but I want to be sure this would not introduce a WCAG non-conformance or impair the user experience.

The role and explicit accessible name for the expanded panel do help in
delineating exactly where it starts/ends. Consider an accordion (or even
just a single disclosure widget) that is followed by "regular" other
text. Without delineating the expanded panel somehow, an SR user reading
through the panel content won't know once they've reached the end of the
panel and are now back in the "regular" part of the text. Depending on
the nature of the content in that panel, this may be quite confusing, as
they may assume the "regular" text that they're now on still just refers
to/relates to whatever accordion/disclosure widget option they opened.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Thu, Jun 15 2023 7:32AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

On 15/06/2023 14:27, Patrick H. Lauke wrote:
[...]
> The role and explicit accessible name for the expanded panel do help in
> delineating exactly where it starts/ends. Consider an accordion (or even
> just a single disclosure widget) that is followed by "regular" other
> text. Without delineating the expanded panel somehow, an SR user reading
> through the panel content won't know once they've reached the end of the
> panel and are now back in the "regular" part of the text. Depending on
> the nature of the content in that panel, this may be quite confusing, as
> they may assume the "regular" text that they're now on still just refers
> to/relates to whatever accordion/disclosure widget option they opened.

For completeness, I should probably clarify: instead, if using the role
and accName for the region, SRs will generally (depending on the
specific SR/settings/etc) announce when you enter/exit a region, when
you cross the threshold.

Same also if an SR user navigates in reverse through the page, they'll
hear again when they crossed from the "regular" text into "this is text
that is part of a region, labelled X"

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

From: Priti Rohra
Date: Thu, Jun 15 2023 7:34AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

Hi Steve,

Use of role region is optional at least as per the APG. As a native screen
reader user I find the region role along with its name annoying to listen
to because:
- When multiple accordions are present, it kind of affects my ability to
navigate quickly using landmark navigation.
- Listening to the accessible names for each role region adds to the noise
for me. Accordions are used a lot in FAQs and the Accordion panel is
available after the header. As a user I have read the question and again I
have to listen to it in the form of accessible name for the region which
kind of irritates me.

From a conformance perspective, I don't see it as a challenge either.
I think role region should be used for accordion panel in case of a long
form and if each section of the form is implemented as an accordion.

Always BPositive!
Priti Rohra


On Thu, Jun 15, 2023 at 5:50 PM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:

> I have been looking at numerous accordion design patterns such as W3C,
> GOV.UK Design System and Whatsock, and they are all very similar. Each
> accordion section looks pretty much like this:
>
> <h2><button id="foo" aria-expanded="true" aria-controls="bar">Section
> name</button></h2>
> <div id="bar" role="region" aria-labelledby="foo">Section content</div>
>
> Can anyone explain the rationale or requirement for the role="region"
> aria-labelledby="foo" attributes? I can't find anything in the ARIA
> specification that requires them.
>
> In terms of the screen reader user experience, after opening an accordion
> section the section name is announced before the section content. This
> behaviour is caused by the "aria-labelledby" attribute and seems
> unnecessary since the section name would have been announced before the
> button was operated. If the section name is more than a few words, this
> behaviour is extremely annoying.
>
> My inclination is to advise clients to omit the role="region"
> aria-labelledby="foo" attributes, but I want to be sure this would not
> introduce a WCAG non-conformance or impair the user experience.
>
> Regards,
> Steve Green
> Managing Director
> Test Partners Ltd
> 020 3002 4176 (direct)
> 0800 612 2780 (switchboard)
> 07957 246 276 (mobile)
> 020 7692 5517 (fax)
> Skype: testpartners
> = EMAIL ADDRESS REMOVED =
> www.testpartners.co.uk
>
> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>
> > > > >

From: Peter Weil
Date: Thu, Jun 15 2023 7:47AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

Thanks Priti — it’s very interesting to read this.

I’ve always been under the impression that it can be annoying to add multiple landmarks (e.g., regions) to accordions, so I generally leave them out unless there’s a specific reason to have them (as in a form).

Peter

> On Jun 15, 2023, at 8:34 AM, Priti Rohra < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi Steve,
>
> Use of role region is optional at least as per the APG. As a native screen
> reader user I find the region role along with its name annoying to listen
> to because:
> - When multiple accordions are present, it kind of affects my ability to
> navigate quickly using landmark navigation.
> - Listening to the accessible names for each role region adds to the noise
> for me. Accordions are used a lot in FAQs and the Accordion panel is
> available after the header. As a user I have read the question and again I
> have to listen to it in the form of accessible name for the region which
> kind of irritates me.
>
> From a conformance perspective, I don't see it as a challenge either.
> I think role region should be used for accordion panel in case of a long
> form and if each section of the form is implemented as an accordion.
>
> Always BPositive!
> Priti Rohra
>
>
> On Thu, Jun 15, 2023 at 5:50 PM Steve Green < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> I have been looking at numerous accordion design patterns such as W3C,
>> GOV.UK Design System and Whatsock, and they are all very similar. Each
>> accordion section looks pretty much like this:
>>
>> <h2><button id="foo" aria-expanded="true" aria-controls="bar">Section
>> name</button></h2>
>> <div id="bar" role="region" aria-labelledby="foo">Section content</div>
>>
>> Can anyone explain the rationale or requirement for the role="region"
>> aria-labelledby="foo" attributes? I can't find anything in the ARIA
>> specification that requires them.
>>
>> In terms of the screen reader user experience, after opening an accordion
>> section the section name is announced before the section content. This
>> behaviour is caused by the "aria-labelledby" attribute and seems
>> unnecessary since the section name would have been announced before the
>> button was operated. If the section name is more than a few words, this
>> behaviour is extremely annoying.
>>
>> My inclination is to advise clients to omit the role="region"
>> aria-labelledby="foo" attributes, but I want to be sure this would not
>> introduce a WCAG non-conformance or impair the user experience.
>>
>> Regards,
>> Steve Green
>> Managing Director
>> Test Partners Ltd



--
Peter Weil
Web Developer
University Marketing, University of Wisconsin–Madison
608-220-3089

From: Sandy Feldman
Date: Thu, Jun 15 2023 7:47AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

https://sandyfeldman.com/panels/

what do people think of this thing that looks like an accordion? Still
tinkering, would love feedback.

Sandy
https://sandyfeldman.com
https://www.a11yready.com


On 2023-06-15 9:34 a.m., Priti Rohra wrote:
> Hi Steve,
>
> Use of role region is optional at least as per the APG. As a native screen
> reader user I find the region role along with its name annoying to listen
> to because:
> - When multiple accordions are present, it kind of affects my ability to
> navigate quickly using landmark navigation.
> - Listening to the accessible names for each role region adds to the noise
> for me. Accordions are used a lot in FAQs and the Accordion panel is
> available after the header. As a user I have read the question and again I
> have to listen to it in the form of accessible name for the region which
> kind of irritates me.
>
> From a conformance perspective, I don't see it as a challenge either.
> I think role region should be used for accordion panel in case of a long
> form and if each section of the form is implemented as an accordion.
>
> Always BPositive!
> Priti Rohra
>
>
> On Thu, Jun 15, 2023 at 5:50 PM Steve Green < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> I have been looking at numerous accordion design patterns such as W3C,
>> GOV.UK Design System and Whatsock, and they are all very similar. Each
>> accordion section looks pretty much like this:
>>
>> <h2><button id="foo" aria-expanded="true" aria-controls="bar">Section
>> name</button></h2>
>> <div id="bar" role="region" aria-labelledby="foo">Section content</div>
>>
>> Can anyone explain the rationale or requirement for the role="region"
>> aria-labelledby="foo" attributes? I can't find anything in the ARIA
>> specification that requires them.
>>
>> In terms of the screen reader user experience, after opening an accordion
>> section the section name is announced before the section content. This
>> behaviour is caused by the "aria-labelledby" attribute and seems
>> unnecessary since the section name would have been announced before the
>> button was operated. If the section name is more than a few words, this
>> behaviour is extremely annoying.
>>
>> My inclination is to advise clients to omit the role="region"
>> aria-labelledby="foo" attributes, but I want to be sure this would not
>> introduce a WCAG non-conformance or impair the user experience.
>>
>> Regards,
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>> 020 3002 4176 (direct)
>> 0800 612 2780 (switchboard)
>> 07957 246 276 (mobile)
>> 020 7692 5517 (fax)
>> Skype: testpartners
>> = EMAIL ADDRESS REMOVED =
>> www.testpartners.co.uk
>>
>> Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
>>
>> >> >> >> >>
> > > >

From: Stegemann, Susan
Date: Thu, Jun 15 2023 8:06AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

I wouldn’t consider tab panels accordions at all.

Confused.

-Susan


----------------------------------------------------------------------------------------------------------------------------------------------------------------

The information contained in this e-mail message may be privileged and confidential information and is intended only for the use of the individual and/or entity
identified in the alias address of this message. If the reader of this message is not the intended recipient, or an employee or agent responsible to deliver it
to the intended recipient, you are hereby requested not to distribute or copy this communication.

If you have received this communication in error, please notify us immediately by telephone or return e-mail and delete the original message from your system.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

From: Sandy Feldman
Date: Thu, Jun 15 2023 8:20AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

are you finding this confusing?

https://sandyfeldman.com/panels/

That's good to know. Thanks for taking the time to tell me. What's not
making sense?

Sandy
https://sandyfeldman.com
https://www.a11yready.com


On 2023-06-15 10:06 a.m., Stegemann, Susan wrote:
> I wouldn’t consider tab panels accordions at all.
>
> Confused.
>
> -Susan
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> The information contained in this e-mail message may be privileged and confidential information and is intended only for the use of the individual and/or entity
> identified in the alias address of this message. If the reader of this message is not the intended recipient, or an employee or agent responsible to deliver it
> to the intended recipient, you are hereby requested not to distribute or copy this communication.
>
> If you have received this communication in error, please notify us immediately by telephone or return e-mail and delete the original message from your system.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> > > >

From: Geethavani.Shamanna
Date: Thu, Jun 15 2023 8:26AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

That is correct, most screen readers announce when you enter/exit a region, and the accordion text is well demarcated. As a screen reader user, this is precisely why I like having regions associated with accordions. It is important to note that these regions are not visible when an accordion is collapsed. So if there are five accordions on a page but only one is expanded, only one accordion region is visible. Also, if all accordions on a page are collapsed, these regions are not displayed in the landmarks list. So unlike general landmarks which can be annoying if there are too many of them on a page, regions associated with accordions are nonintrusive.

Geetha
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: 15 June 2023 14:32
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Accordion design patterns

CAUTION: This mail comes from outside the University. Please consider this before opening attachments, clicking links, or acting on the content.

On 15/06/2023 14:27, Patrick H. Lauke wrote:
[...]
> The role and explicit accessible name for the expanded panel do help
> in delineating exactly where it starts/ends. Consider an accordion (or
> even just a single disclosure widget) that is followed by "regular"
> other text. Without delineating the expanded panel somehow, an SR user
> reading through the panel content won't know once they've reached the
> end of the panel and are now back in the "regular" part of the text.
> Depending on the nature of the content in that panel, this may be
> quite confusing, as they may assume the "regular" text that they're
> now on still just refers to/relates to whatever accordion/disclosure widget option they opened.

For completeness, I should probably clarify: instead, if using the role and accName for the region, SRs will generally (depending on the specific SR/settings/etc) announce when you enter/exit a region, when you cross the threshold.

Same also if an SR user navigates in reverse through the page, they'll hear again when they crossed from the "regular" text into "this is text that is part of a region, labelled X"

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

From: glen walker
Date: Thu, Jun 15 2023 10:39AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

It sounds like two screen reader users posted their preferences, one likes
regions and one doesn't. Such is the life of UX and accessibility.

I would lean on the side of having the region and label so that if the
accordion is expanded, you can hear when you enter/exit the expanded panel,
whether you're navigating forward or backwards.

Probably the most common way that interaction will happen is tabbing to the
expandable button in the accordion and deciding whether to open it, then
navigating to the newly expanded panel. That would give the potential
annoyance of having just announced the button label and then the button
label again as the region label. But if the user navigates away from the
accordion, leaving it expanded, peruses other parts of the page, then comes
back to the accordion, having the region label will be helpful.

To make everyone happy, you almost have to add the aria-labelledby
dynamically *after* the panel is open, so that it doesn't announce
initially but then announces if you navigate back to it. I'm not sure I'd
recommend that approach but it might be a creative solution.

But setting it dynamically might (?) cause it to be announced? I seem to
recall an answer from Patrick to another question about changing a label
(can't remember if it was a <label> element or aria-label attribute or
similar) and changing the value mapped to a live event and was announced.
I have bookmarks to both the

HTML Accessibility API Mappings 1.0 - https://www.w3.org/TR/html-aam-1.0/
Core Accessibility API Mappings 1.2 - https://www.w3.org/TR/core-aam-1.2/

but I don't remember which API mapping documented the "live" announcement.
I remember it being buried in the API mapping somewhere and was surprised
to find that changing a value caused a live announcement.

From: Peter Weil
Date: Thu, Jun 15 2023 11:18AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

I wonder whether using native disclosures (details/summary) instead of (javascript) accordions would have any bearing on the usefulness of applying role=region to the disclosed content containers. I’ve never seen a recommendation to use regions with native disclosures… but does their being native negate the need for these aria attributes ?

Peter

> On Jun 15, 2023, at 11:39 AM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
> It sounds like two screen reader users posted their preferences, one likes
> regions and one doesn't. Such is the life of UX and accessibility.
>
> I would lean on the side of having the region and label so that if the
> accordion is expanded, you can hear when you enter/exit the expanded panel,
> whether you're navigating forward or backwards.
>
> Probably the most common way that interaction will happen is tabbing to the
> expandable button in the accordion and deciding whether to open it, then
> navigating to the newly expanded panel. That would give the potential
> annoyance of having just announced the button label and then the button
> label again as the region label. But if the user navigates away from the
> accordion, leaving it expanded, peruses other parts of the page, then comes
> back to the accordion, having the region label will be helpful.
>
> To make everyone happy, you almost have to add the aria-labelledby
> dynamically *after* the panel is open, so that it doesn't announce
> initially but then announces if you navigate back to it. I'm not sure I'd
> recommend that approach but it might be a creative solution.
>
> But setting it dynamically might (?) cause it to be announced? I seem to
> recall an answer from Patrick to another question about changing a label
> (can't remember if it was a <label> element or aria-label attribute or
> similar) and changing the value mapped to a live event and was announced.
> I have bookmarks to both the
>
> HTML Accessibility API Mappings 1.0 - https://www.w3.org/TR/html-aam-1.0/
> Core Accessibility API Mappings 1.2 - https://www.w3.org/TR/core-aam-1.2/
>
> but I don't remember which API mapping documented the "live" announcement.
> I remember it being buried in the API mapping somewhere and was surprised
> to find that changing a value caused a live announcement.
> > > >

From: Steve Green
Date: Fri, Jun 16 2023 1:44AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

I have just started some proof of concept work on precisely this. Everything you need is baked into the native elements, so no need for "aria-expanded", "aria-controls" or any JavaScript. I have never seen anyone suggest adding "aria-labelledby" or role="region" to the native details/summary elements either, which is another reason why I question their need in any accordion design.

As far as I can tell so far, there are no downsides to using details/summary elements for accordions, but there are clearly some benefits.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Peter Weil
Sent: Thursday, June 15, 2023 6:18 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accordion design patterns

I wonder whether using native disclosures (details/summary) instead of (javascript) accordions would have any bearing on the usefulness of applying role=region to the disclosed content containers. I’ve never seen a recommendation to use regions with native disclosures… but does their being native negate the need for these aria attributes ?

Peter

> On Jun 15, 2023, at 11:39 AM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
> It sounds like two screen reader users posted their preferences, one
> likes regions and one doesn't. Such is the life of UX and accessibility.
>
> I would lean on the side of having the region and label so that if the
> accordion is expanded, you can hear when you enter/exit the expanded
> panel, whether you're navigating forward or backwards.
>
> Probably the most common way that interaction will happen is tabbing
> to the expandable button in the accordion and deciding whether to open
> it, then navigating to the newly expanded panel. That would give the
> potential annoyance of having just announced the button label and then
> the button label again as the region label. But if the user navigates
> away from the accordion, leaving it expanded, peruses other parts of
> the page, then comes back to the accordion, having the region label will be helpful.
>
> To make everyone happy, you almost have to add the aria-labelledby
> dynamically *after* the panel is open, so that it doesn't announce
> initially but then announces if you navigate back to it. I'm not sure
> I'd recommend that approach but it might be a creative solution.
>
> But setting it dynamically might (?) cause it to be announced? I seem
> to recall an answer from Patrick to another question about changing a
> label (can't remember if it was a <label> element or aria-label
> attribute or
> similar) and changing the value mapped to a live event and was announced.
> I have bookmarks to both the
>
> HTML Accessibility API Mappings 1.0 -
> https://www.w3.org/TR/html-aam-1.0/
> Core Accessibility API Mappings 1.2 -
> https://www.w3.org/TR/core-aam-1.2/
>
> but I don't remember which API mapping documented the "live" announcement.
> I remember it being buried in the API mapping somewhere and was
> surprised to find that changing a value caused a live announcement.
> > > archives at http://webaim.org/discussion/archives
>

From: Patrick H. Lauke
Date: Fri, Jun 16 2023 4:49AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

On 16/06/2023 08:44, Steve Green wrote:
> As far as I can tell so far, there are no downsides to using
> details/summary elements for accordions

Worth having a squint over this
https://www.scottohara.me/blog/2022/09/12/details-summary.html

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

From: Steve Green
Date: Fri, Jun 16 2023 6:36AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

I really like how Scott does such in-depth testing, but his articles always reach the same conclusion. If you want a website to work on a wide variety of platforms, you can't use most of the important "new" HTML elements or ARIA roles created in the last ten years or so, that we have been waiting so long for. It's the same with the <dialog> element, role="tooltip" and others. You have to wonder if they will ever be properly supported.

It almost makes me yearn for the good old days of browser-specific hacks (remember the "underscore hack", the "holly hack", the "asterisk hack" etc.?). At least we could code things properly and target the hacks at the crappy user agents that don't support standards properly. Remember how we used to refer to Chrome, Firefox and Safari as being standards compliant (as opposed to Internet Explorer, which wasn't). It seems that nothing is now. Such is progress.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Friday, June 16, 2023 11:50 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Accordion design patterns



On 16/06/2023 08:44, Steve Green wrote:
> As far as I can tell so far, there are no downsides to using
> details/summary elements for accordions

Worth having a squint over this
https://www.scottohara.me/blog/2022/09/12/details-summary.html

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke

From: Peter Weil
Date: Fri, Jun 16 2023 7:12AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

I know what you mean, Steve. But I find the most recent ones about <details-summary> and <dialog> pretty encouraging. Yes, there are some bugs and weirdness with how browsers treat <details-summary> and the specs about which role they should take, etc. still need work — or clarification, or something.

But if you are ok with avoiding headings (h1, h2, etc.) and don’t care much about customizing the triangle, <details-summary> offers enough benefits to use over hand-rolled show-hide/accordion thingies for all kinds of things, including FAQs..

Scott’s report on the improved browser support for <dialog> is encouraging, too. I’ve recently started using the native <dialog> for modals on a few sites, and it’s pretty nice. It has a lot of built-in functionality, and eliminates a boatload of javascript.

Peter

> On Jun 16, 2023, at 7:36 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>
> I really like how Scott does such in-depth testing, but his articles always reach the same conclusion. If you want a website to work on a wide variety of platforms, you can't use most of the important "new" HTML elements or ARIA roles created in the last ten years or so, that we have been waiting so long for. It's the same with the <dialog> element, role="tooltip" and others. You have to wonder if they will ever be properly supported.
>
> It almost makes me yearn for the good old days of browser-specific hacks (remember the "underscore hack", the "holly hack", the "asterisk hack" etc.?). At least we could code things properly and target the hacks at the crappy user agents that don't support standards properly. Remember how we used to refer to Chrome, Firefox and Safari as being standards compliant (as opposed to Internet Explorer, which wasn't). It seems that nothing is now. Such is progress.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
> Sent: Friday, June 16, 2023 11:50 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Accordion design patterns
>
>
>
> On 16/06/2023 08:44, Steve Green wrote:
>> As far as I can tell so far, there are no downsides to using
>> details/summary elements for accordions
>
> Worth having a squint over this
> https://www.scottohara.me/blog/2022/09/12/details-summary.html
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke > > > > > >

From: Steve Green
Date: Fri, Jun 16 2023 7:39AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

At least <dialog> can be used and you just need to do a few other things to make it work with mobile browsers. Admittedly, that includes making the dialog a direct child of the <body> element so you can apply aria-hidden="true" to everything else when the dialog is displayed.

That's not the case with <details> and <summary. For instance, you need to add role="button" to the <summary> element to get it to work with Dragon. However, doing so causes Voiceover not to announce the expanded / collapsed state. Maybe you can fix that by adding an "aria-expanded" attribute - I haven't tried. And if you want to hide the triangle (which you always want to do), Firefox now doesn't work properly. To fix all these user agent bugs, you would end up adding just as much ARIA and JavaScript as if you had built the thing from a pile of divs.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Peter Weil
Sent: Friday, June 16, 2023 2:13 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accordion design patterns

I know what you mean, Steve. But I find the most recent ones about <details-summary> and <dialog> pretty encouraging. Yes, there are some bugs and weirdness with how browsers treat <details-summary> and the specs about which role they should take, etc. still need work — or clarification, or something.

But if you are ok with avoiding headings (h1, h2, etc.) and don’t care much about customizing the triangle, <details-summary> offers enough benefits to use over hand-rolled show-hide/accordion thingies for all kinds of things, including FAQs..

Scott’s report on the improved browser support for <dialog> is encouraging, too. I’ve recently started using the native <dialog> for modals on a few sites, and it’s pretty nice. It has a lot of built-in functionality, and eliminates a boatload of javascript.

Peter

> On Jun 16, 2023, at 7:36 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>
> I really like how Scott does such in-depth testing, but his articles always reach the same conclusion. If you want a website to work on a wide variety of platforms, you can't use most of the important "new" HTML elements or ARIA roles created in the last ten years or so, that we have been waiting so long for. It's the same with the <dialog> element, role="tooltip" and others. You have to wonder if they will ever be properly supported.
>
> It almost makes me yearn for the good old days of browser-specific hacks (remember the "underscore hack", the "holly hack", the "asterisk hack" etc.?). At least we could code things properly and target the hacks at the crappy user agents that don't support standards properly. Remember how we used to refer to Chrome, Firefox and Safari as being standards compliant (as opposed to Internet Explorer, which wasn't). It seems that nothing is now. Such is progress.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Patrick H. Lauke
> Sent: Friday, June 16, 2023 11:50 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Accordion design patterns
>
>
>
> On 16/06/2023 08:44, Steve Green wrote:
>> As far as I can tell so far, there are no downsides to using
>> details/summary elements for accordions
>
> Worth having a squint over this
> https://www.scottohara.me/blog/2022/09/12/details-summary.html
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
>

From: Peter Weil
Date: Fri, Jun 16 2023 9:31AM
Subject: Re: Accordion design patterns
← Previous message | Next message →

If you’re doing a modal, <dialog> does both of these things for you with showModal(). In addition to offering automatic focus, it also — anecdotally, since I haven’t seen it documented — returns the focus to the original trigger automatically when the modal dialog is closed.

But to get back on-topic, I agree that <details - summary> is far from perfect. But in a lot of situations, it’s a reasonable choice.

Peter

> On Jun 16, 2023, at 8:39 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>
> At least <dialog> can be used and you just need to do a few other things to make it work with mobile browsers. Admittedly, that includes making the dialog a direct child of the <body> element so you can apply aria-hidden="true" to everything else when the dialog is displayed.
>
> That's not the case with <details> and <summary. For instance, you need to add role="button" to the <summary> element to get it to work with Dragon. However, doing so causes Voiceover not to announce the expanded / collapsed state. Maybe you can fix that by adding an "aria-expanded" attribute - I haven't tried. And if you want to hide the triangle (which you always want to do), Firefox now doesn't work properly. To fix all these user agent bugs, you would end up adding just as much ARIA and JavaScript as if you had built the thing from a pile of divs.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Peter Weil
> Sent: Friday, June 16, 2023 2:13 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accordion design patterns
>
> I know what you mean, Steve. But I find the most recent ones about <details-summary> and <dialog> pretty encouraging. Yes, there are some bugs and weirdness with how browsers treat <details-summary> and the specs about which role they should take, etc. still need work — or clarification, or something.
>
> But if you are ok with avoiding headings (h1, h2, etc.) and don’t care much about customizing the triangle, <details-summary> offers enough benefits to use over hand-rolled show-hide/accordion thingies for all kinds of things, including FAQs..
>
> Scott’s report on the improved browser support for <dialog> is encouraging, too. I’ve recently started using the native <dialog> for modals on a few sites, and it’s pretty nice. It has a lot of built-in functionality, and eliminates a boatload of javascript.
>
> Peter
>
>> On Jun 16, 2023, at 7:36 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> I really like how Scott does such in-depth testing, but his articles always reach the same conclusion. If you want a website to work on a wide variety of platforms, you can't use most of the important "new" HTML elements or ARIA roles created in the last ten years or so, that we have been waiting so long for. It's the same with the <dialog> element, role="tooltip" and others. You have to wonder if they will ever be properly supported.
>>
>> It almost makes me yearn for the good old days of browser-specific hacks (remember the "underscore hack", the "holly hack", the "asterisk hack" etc.?). At least we could code things properly and target the hacks at the crappy user agents that don't support standards properly. Remember how we used to refer to Chrome, Firefox and Safari as being standards compliant (as opposed to Internet Explorer, which wasn't). It seems that nothing is now. Such is progress.
>>
>> Steve
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> Patrick H. Lauke
>> Sent: Friday, June 16, 2023 11:50 AM
>> To: = EMAIL ADDRESS REMOVED =
>> Subject: Re: [WebAIM] Accordion design patterns
>>
>>
>>
>> On 16/06/2023 08:44, Steve Green wrote:
>>> As far as I can tell so far, there are no downsides to using
>>> details/summary elements for accordions
>>
>> Worth having a squint over this
>> https://www.scottohara.me/blog/2022/09/12/details-summary.html
>>
>> P
>> --
>> Patrick H. Lauke
>>



--
Peter Weil
Web Developer
University Marketing, University of Wisconsin–Madison
608-220-3089

From: Steve Green
Date: Fri, Jun 16 2023 9:57AM
Subject: Re: Accordion design patterns
← Previous message | No next message

<dialog> does those things on desktop browsers, but not on mobile. I checked this only a week ago.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Peter Weil
Sent: Friday, June 16, 2023 4:32 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accordion design patterns

If you’re doing a modal, <dialog> does both of these things for you with showModal(). In addition to offering automatic focus, it also — anecdotally, since I haven’t seen it documented — returns the focus to the original trigger automatically when the modal dialog is closed.

But to get back on-topic, I agree that <details - summary> is far from perfect. But in a lot of situations, it’s a reasonable choice.

Peter

> On Jun 16, 2023, at 8:39 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>
> At least <dialog> can be used and you just need to do a few other things to make it work with mobile browsers. Admittedly, that includes making the dialog a direct child of the <body> element so you can apply aria-hidden="true" to everything else when the dialog is displayed.
>
> That's not the case with <details> and <summary. For instance, you need to add role="button" to the <summary> element to get it to work with Dragon. However, doing so causes Voiceover not to announce the expanded / collapsed state. Maybe you can fix that by adding an "aria-expanded" attribute - I haven't tried. And if you want to hide the triangle (which you always want to do), Firefox now doesn't work properly. To fix all these user agent bugs, you would end up adding just as much ARIA and JavaScript as if you had built the thing from a pile of divs.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Peter Weil
> Sent: Friday, June 16, 2023 2:13 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accordion design patterns
>
> I know what you mean, Steve. But I find the most recent ones about <details-summary> and <dialog> pretty encouraging. Yes, there are some bugs and weirdness with how browsers treat <details-summary> and the specs about which role they should take, etc. still need work — or clarification, or something.
>
> But if you are ok with avoiding headings (h1, h2, etc.) and don’t care much about customizing the triangle, <details-summary> offers enough benefits to use over hand-rolled show-hide/accordion thingies for all kinds of things, including FAQs..
>
> Scott’s report on the improved browser support for <dialog> is encouraging, too. I’ve recently started using the native <dialog> for modals on a few sites, and it’s pretty nice. It has a lot of built-in functionality, and eliminates a boatload of javascript.
>
> Peter
>
>> On Jun 16, 2023, at 7:36 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> I really like how Scott does such in-depth testing, but his articles always reach the same conclusion. If you want a website to work on a wide variety of platforms, you can't use most of the important "new" HTML elements or ARIA roles created in the last ten years or so, that we have been waiting so long for. It's the same with the <dialog> element, role="tooltip" and others. You have to wonder if they will ever be properly supported.
>>
>> It almost makes me yearn for the good old days of browser-specific hacks (remember the "underscore hack", the "holly hack", the "asterisk hack" etc.?). At least we could code things properly and target the hacks at the crappy user agents that don't support standards properly. Remember how we used to refer to Chrome, Firefox and Safari as being standards compliant (as opposed to Internet Explorer, which wasn't). It seems that nothing is now. Such is progress.
>>
>> Steve
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>> Of Patrick H. Lauke
>> Sent: Friday, June 16, 2023 11:50 AM
>> To: = EMAIL ADDRESS REMOVED =
>> Subject: Re: [WebAIM] Accordion design patterns
>>
>>
>>
>> On 16/06/2023 08:44, Steve Green wrote:
>>> As far as I can tell so far, there are no downsides to using
>>> details/summary elements for accordions
>>
>> Worth having a squint over this
>> https://www.scottohara.me/blog/2022/09/12/details-summary.html
>>
>> P
>> --
>> Patrick H. Lauke
>>



--
Peter Weil
Web Developer
University Marketing, University of Wisconsin–Madison
608-220-3089