Add a section to the user profile to store accessibility preferences

Created on 11 October 2023, 8 months ago
Updated 12 October 2023, 8 months ago

Problem/Motivation

There is no single configuration that works best for all users. WCAG is a great effort to do this, but ultimately, some users will be able to more effectively communicate if they are able to personalize the sites that they are using. Whether that is the font, spacing, or how interactive elements are engaged.

There have been a few modules to address this sort of activity:

These are ok, but are really aimed at anonymous users, and not for our Drupal users. We can support them better.

This initially came up when thinking about how to support prefers-reduced-motion. Animation done right can help users, but it needs to be built so that it respects user choice.

Proposed resolution

I'd like to see something like /user/1/personalization which allows for us to start collecting user personalizations.

Remaining tasks

User interface changes

The authoring interface will need to change.

API changes

None

Data model changes

Release notes snippet

✨ Feature request
Status

Active

Version

11.0 πŸ”₯

Component
User moduleΒ  β†’

Last updated 1 day ago

Created by

πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

Sign in to follow issues

Comments & Activities

  • Issue created by @mgifford
  • πŸ‡©πŸ‡ͺGermany rkoller NΓΌrnberg, Germany

    Thanks for the write up @mgifford!

    Aside the animation setting, the other one that would be reasonable to add to this user profile page would be the ability to select if you want to alter lists by drag and drop or by assign weight values.

  • πŸ‡¨πŸ‡¦Canada mgifford Ottawa, Ontario
  • πŸ‡ΊπŸ‡ΈUnited States benjifisher Boston area

    I am fixing a typo in the issue summary.

    To me, "personalization" suggests marketers who are trying to target ads based on what they know about me. I prefer to avoid that. I suggest using "preferences" instead. It is also shorter, at least in English. (4 characters, or 2 syllables, shorter)

    How are the user's choices going to be stored, and how will we make them available to modules and themes?

    If we store the data in a new base field, then that is a data model change. If we store it in one or more new fields, or a related entity, then it is not. Now that I think of it, the Profile β†’ module does exactly that: it creates the Profile entity type, and then each user can have one or more Profile entities (of different types) attached to it.

    We will need some sort of way for modules and themes to access the preferences. If we add a public method to AccountInterface, then that is an API addition.

    So far, I think the contrib Profile module already does what you have suggested. It would be easy to create a contrib Preferences module, requiring Profile, that creates a Preferences profile type and provides an API to access the preferences. The only disadvantage I can see is that core modules and themes would not be able to use it.

  • πŸ‡¬πŸ‡§United Kingdom catch

    There is the existing user data storage which is already used for preferences, we used to use that for whether admin descriptions are collapsed or not. That API is not ideal, but it's probably the right place even if the entire thing needs refactoring.

    https://api.drupal.org/api/drupal/core%21modules%21user%21src%21UserData...

Production build 0.69.0 2024