RE: Aria role="heading" and aria-level inside buttons

to disclose or not disclose is a choice that should ideally be content driven … that is, the volume and nature of the content , and the need’s’ of people reading it determine the presentation. 

 

The back and forth about Bernat’s originally proposed implementation is absolutely fair game for this forum as various inputs have clearly influenced its direction. 

 

I am similarly uncomfortable with the idea that so-called design decisions shouldn’t also be queried in this forum .. it may just be that its readers take this back to their nests too which may have a positive outcome.

 

And, if this list is to be ‘strictly’ about WCAG (whatever this might mean), then it is surely up to the moderator to pilot its direction? 

 

From: Marc Haunschild (Accessibility Consulting) <marc.haunschild@accessibility.consulting> 
Sent: Wednesday, July 10, 2024 10:19 PM
To: w3c-wai-ig@w3.org
Cc: w3c-wai-ig@w3.org
Subject: Re: Aria role="heading" and aria-level inside buttons

 

Hi Bernat and Patrick,

 

@Bernat: I completely understand you

 

@Patrick: if we leave aside all cons of your perspective you’re right of course. ;-)

 

But seriously: in reality there IS normally just one solution that has to fit for all. The people who made the decision for Bernat and tell him what to do don’t seem to be willing to look for best practice for everyone. Obviously it hast to be quick and as dirty as legally possible.

 

In this particular case it’s a waste of time of course. The decision is made.

 

But in general it makes absolutely sense to discuss possible alternatives. And I find it discouraging if we stop discussing pros and cons of possible best practices here.

 

Anyway: as a user I hate it and will go back to my DuckDuckGo SRP.

 

If you want to have a fully explanation of a complex topic, long information is what you need, no matter the type of media, be it a video, audio or text. If you search the web instead of YouTube you are probably looking for a text (maybe BECAUSE you want to search them semi-automatically instead of listening to lengthy explanation for read walls of texts.

 

Knowing myself that people don’t want or are not able to read long texts, taking away the search feature is the worst thing you can do to them. Yes there are people that are overwhelmed by long texts - but I don’t understand how increasing the necessary effort helps these people?!?

 

Obviously this is a very common opinion. Adrian Roselli writes: "I tend to avoid disclosure widgets within content because they break in-page search (Wikipedia on mobile being the most frustrating example). In testing with people, I also find they generally do not like disclosure widgets that arbitrarily hide content.“

https://adrianroselli.com/2020/05/disclosure-widgets.html

 

But one thing are disclosure widgets open by default (with a „close all“ button for those who might be overwhelmed) vs an accordion, that shows only one chunk of text at a time, so that there is no way at all to make the whole thing searchable.

 

Let the users at least choose if they want to hide content!

 

Just my 2 Cent

 

Mit freundlichen Grüßen,





Marc Haunschild 
https://accessibility.consulting/ - a web designed for ALL!





Am 10.07.2024 um 12:16 schrieb Patrick H. Lauke <redux@splintered.co.uk>:



On 10/07/2024 10:54, Marc Haunschild wrote:




You want to hide long texts, so users cannot search them with cmd+f?


Can we accept that "one size doesn't always fit all"? For every user that would prefer having all the text shown in full for various reasons, there will be users who would feel completely overwhelmed having a giant mass of text shoved in their face.

(leaving also aside the point that often, when questions are very specifically about "how can I achieve X", starting down a "have you considered not doing X in the first place?" line of discussion may be already far too late in the decision-making process / the person asking may not even be in a position to change the approach at that point).

P
-- 
Patrick H. Lauke

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