Re: Suggestion for a new kind of cookie (in regards to accessibility)

Hi Tessa,
As an additional point we would not want to ever expose the following user preferences:

  *   Use of a screen reader: yes/no
  *   Use of a braille keyboard: yes/no

There is a w3c design principle https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech to not allow for authors to detect whether a user uses assistive technology so I would consider it unlikely that we would ever expose this information to web sites

Thanks,
James

From: Lola Odelola <lolaodelola@gmail.com>
Date: Tuesday, March 18, 2025 at 3:42 AM
To: Tessa <spookytessa@yahoo.com>
Cc: public-aria-practices@w3.org <public-aria-practices@w3.org>
Subject: Re: Suggestion for a new kind of cookie (in regards to accessibility)
Hi Tessa,

Thanks for your email. I'm Lola a member of the ARIA APG Task Force, but this email does not represent the task force.
I'm really happy to see that you're engaging with and contributing to this work! Reading your proposal though, I feel like we already have methods that do this, particularly in CSS.
For example `prefers-color-scheme` looks at the user's OS light/dark mode setting and allows developers to write CSS rules specifically for different OS themes. Similarly, `prefers-reduced-motion`, `prefers-contrast`, etc.
There is also a draft report, User Preference Media Features Client Hints Headers<https://wicg.github.io/user-preference-media-features-headers>, which includes definitions for new headers `sec-prefers-color-scheme`, `sec-prefers-reduced-motion`, etc (which are currently experimental in browsers). As it's a report it's not currently on the standards track but it doesn't mean it couldn't be. I think that this meets the problem you laid out in your proposal, i.e. getting user OS settings in the response object, but you have additional ideas that may be useful to share with the group developing this report. The Web Incubation Community Group is the group working on it, however, I can see there hasn't been any activity on the report since 2023: https://github.com/WICG/user-preference-media-features-headers.

If you'd like to learn more about this report, I'd encourage you to either have a read through their mailing list<https://lists.w3.org/Archives/Public/public-wicg/>, email the group, submit a GitHub issue<https://github.com/WICG/user-preference-media-features-headers> or better yet, join the group<https://www.w3.org/community/wicg/> if you have the capacity.

I hope this has been helpful to you.

Kindly,
Lola

On Tue, 18 Mar 2025 at 09:32, Tessa <spookytessa@yahoo.com<mailto:spookytessa@yahoo.com>> wrote:
Dear w3.org<http://w3.org>,

I am currently writing a course about accessibility and I’ve run into a dilemma.
I'm always contemplating the best way to present a website in such a way that it is fully accessible and user friendly.
It is very hard, if not impossible, to offer a website that is both 100% accessible and 100% user friendly, also for those not needing accessibility support.

I’d like to offer a best practice solution, but I’m not sure this is possible.
You either offer a fully accessible page, where user friendliness for users not needing accessibility support is wanting, or you offer multiple options, but someone has to make a choice of what to use at any point. This is not inclusive.
The current best practice (in my view) is: you compromise and offer as much accessible functionality as you can while keeping it user friendly for those not using that. No one will have an optimal experience in this case.

So I was thinking…

It would be very useful if websites could read (standardized) accessibility settings from a user, in the user agent string e.g., to define upfront what accessibility settings, if any, the user prefers and directly implement the correct settings accordingly when presenting the page, so that everyone will see the same page, but with their preferences already activated.

I think it would benefit everyone if this were a web standard.
I considered it being a browser setting that was made available to websites (if allowed by user), but a colleague suggested using a cookie or even a setting in the operating system instead as that is a more global level, meaning less hassle for the user as they only need to set the settings once.

If this were a cookie, it could be optional (e.g. under functional cookies?).
A user would then only specify their settings once and every website could make sure to read the cookie and adapt the page accordingly.
Or they could deny the cookie if they are worried about privacy and just make the choice on the (first) page that is presented to them.

If it were an OS setting, each OS would need a standardized set of settings and an option to allow browsers (or other platforms) to access and use this information. This would probably go beyond the scope of a web standard (this is not my area of expertise, so I don't know).

I know you usually deal in the other direction (how to make a site accessible), but my guess is you also have the authority to lobby to create new web standards or perhaps even higher up.
I think it would make web development easier in the long run as it would ensure that more variables were known at the time a page is created.
This in turn would make life for people who rely on accessible information also easier, as they would only need to set the settings once and have them applied to every website they visit, rather than having to specify this separately for each website in each different browser.
Of course anyone could locally update the settings and permission if/when required.

Some properties that could be included in this setting:

- Dark mode: on/off
- Zoom level
- Font sizes
- Font colors
- What to do with images
- Use of a screen reader: yes/no
- Use of a braille keyboard: yes/no
- etc.


I am sure I’m missing things here, but I wanted to plant a seed either way and hopefully you’ll think my idea is a good one.

Thank you for considering my suggestion.

Kind regards,
Tessa Carati