Following a discussion on the accessibility of links in the #xwiki chat room, I wanted to discuss the idea of:
- having extra accessibility enabled by default
- improving the discoverability of customization & accessibility features by providing a special icon in the navbar
I think we can all agree accessibility is important so I’m not gonna give arguments for that.
The question we need to answer is: Should we enable extra accessibility features by default?
I believe the answer is Yes. We have to take into consideration the fact that the accesability feature is not easily discoverable by normal users and neither is by admins.
Just because we have it and we have it documented, it doesn’t mean that any user will automatically think of searching Accessibility inside their instance or in our Documentation.
By having it enabled by default, it makes XWiki’s intention of being highly accessible clear and it makes the experience great for everyone, not only for the portion of people that have no vision problem or that somehow found our extra accesability features.
Obviously, the idea of easily understanding what an element’s purpose is is much more important than how that element looks. Thing is, when you have a lot of the same element in the same page, the overall feel of the interface will be impacted.
In our case, underline links can feel like they clutter the interface (they add detail) in places like:
- some panels
- live data
Alternative ways of styling a link would impact a bit much the cohesiveness of the interface, without escaping the cluttering factor (tried adding an icon to links, it just looks weird in tables and a bit disruptive in the main content).
For people that have good or mostly good vision, the accessible mode may feel… just a tiny bit oldish or cluttered.
While other knowledge management tools make use of underlined links by default, they mostly use them in the main content, still having non-decorated links on panels, navigations, tables of contents, etc. The rule seems to be:
- if the context explicitly implies that each of the text elements in the context have an action linked to them enabled by click → no underline
- if the context doesn’t clearly specify the purpose of a text elements → links will have underline
Doing that, we simplify most cases.
I’m also proposing improving how easy it is to configure appeareance & accessibility related features for a newly registered user in an instance.
- The idea would be to have a new icon in the navbar.
- The icon could be an eye or a pencil.
- Clicking on the icon will open a dropdown menu that will cover:
– Customizing the theme (only for admins). Maybe even choosing the theme if we want to open a dropdown in a dropdown.
– A link to all appearence settings (only for admins)
– A toggle for extra accessibility features
We can choose to have this icon only be present for a a few weeks from the registration of the user in the instance. Truth be told, after the theme is chosen & customized and you’ve chosen if you turn on or off the accessibility features… you won’t need to see this category of features for a good while, so no need of keeping them in the navigation bar forever.
The functionality of this dropdown and the fact that it will stay in the nav bar for a limited amount of time can be explained in the initial tour.
What do you think?
I am especially interested in:
- knowing if the idea of only having the icon present for a dynamically computed amount of time based on the registration date is a hard to implement one (or how hard it is)
- knowing if we ever had dropdowns opened in dropdowns implemented before (in an accessible way, too)
- knowing if all underlines present ATM are necessary to adhere to WCAG or could we simplify things more in some cases (in the future)? @CharpentierLucas , your opinion would help out a lot