Adopt the IDRC's Preference Framework

[mgifford]

WET should really be looking at adopting something like the IDRC's https://build.fluidproject.org/infusion/demos/uiOptions/

This would improve WET for users who are low vision or have cognitive impairments like dyslexia.

[McEmily]

It seems like a good idea, but I'm not too keen on the option for "Times New Roman" as a font option. That being said, I work for the Accessibility, Accommodation, and Adaptive Computer Technology program at Shared Services Canada, and the documentation we have recommends using sans-serif fonts. But I can definitely see how this could have potential. I'll show it to my team on Monday and let you know what they think.

[mgifford]

That's great. Think it is kinda funny you noted Times New Roman & not Comic Sans (which is also an option).

That said, if a user prefers them and is able to better digest the information with their favorite font, why not. Why look for "the best" when you can actually deliver "the best for me".

Personalization is really the future of accessibility.

[mgifford]

Oh ya, forgot to mention, this list of fonts is totally adjustable. You could (and probably should) also give the option of OpenDyslexic for instance.

[bsouster]

I think it's cool but for the performance hit and utility I don't see it out-performing the users' personal tools already set to supplement their experience from the operating system level and onward.

I foresee diminishing returns; the more the user needs the formatting options of this tool, the more likely they will already be relying on other better tools.

@mgifford it's worth trying it anyway and record results, we might be surprised

[mgifford]

Ya, performance might be an issue, but the patterns are really what matter. They've got a good text to speech plugin too.

There has to be a way to load the JS only if the widget is selected. That's not how this specific library works, but that should be possible.

[RobJohnston]

My only preference is almost always to inverse the colours (light text on a dark background). I remember this was an option on the microfiche machine at the library to make it easier to read.

It's a popular option that I see around the web like on https://docs.microsoft.com/en-us/dotnet/csharp/ or https://www.reddit.com/.

[mgifford]

Plus there's Mac's Dark Mode - https://support.apple.com/en-us/HT208976 - which is a preference which is available to Safari browsers (not sure about other Mac browsers).

https://paulmillr.com/posts/using-dark-mode-in-css/

[juleskuehn]

I agree 100% with @bsouster. I don't think these kinds of tools should be integrated into individual websites. Rather, the website should be coded in standard, accessible ways so that the design doesn't interfere with accessibility tools. All of the demonstrated functionality can and should be provided by browser plugins, not to mention operating system tools. Lots of work is being done in terms of supporting user preferences through CSS and HTML microdata markup. See W3C personalization task force. I believe this is the correct approach.

The main issues I have with the "implement it on your own website ad-hoc" kind of approach (vs. simply ensuring non-interference with user/browser provided accessibility tools) are:

• Forcing the user to learn a different set of preference tools, and to set individual preferences, on many different web pages. This is a huge loss for usability vs. setting preferences in one place and having all websites respect them.
• Redundant, misplaced effort in terms of development for accessibility.

A better approach for personalization, if you simply must provide your own custom dark theme (etc) as a web dev, is to support some new features like:

• @media (prefers-color-scheme) as @mgifford mentions above
• @media (prefers-reduced-motion)
• I expect more of these to show up over time.

And to mark up items by functional roles, using some new ARIA markup:

• COGA (Cognitive and Learning Disabilities Accessibility) techniques to fulfill WCAG 2.1 AAA criterion Identify Purpose

[jobara]

I’m one of the developers working on the UI Options tool that @mgifford mentioned. I’m not here to advertise the tool at all, just wanted to add to the discussion.

I believe there is definitely value in having higher level tools that a user can use across sites. I’ve actually been working on a chrome extension, which can do something like you suggested. It even integrates with Morphic, which is a system for applying a user’s preferences across devices.

That being said there are also good reasons to have dedicated user preferences built into a site directly. For starters, we can’t assume that someone is accessing the site from their own personal machine, that they even own a device themselves, or that they have permission on the device they are using to install and configure browser extensions, the OS settings, or applications. A system like Morphic would address these issues, but until it is ubiquitous we still need to be aware of this case.

If you use the chrome extension I mentioned, you’ll notice that many sites are modifiable, but that the results will vary widely from site to site. Yes, adhering to standards and best practices will make such modifications much easier and provide a better user experience. However, the best experiences come when the site has been intentionally designed to handle such adaptations. Perhaps in time, with broader standardization around personalization, websites will all be structured with such considerations and the necessary hooks/listeners.

I guess what I’m arguing for here is allowing for a variety of approaches to be provided to the user, to employ across different contexts. Not unlike how their preferences for the site may change in differing contexts (night/day, loud/quiet environment, etc.).

[mgifford]

It is a pretty simple example, but it is interesting to see departments making "Accessibility Buttons" or display widgets - https://laws-lois.justice.gc.ca/eng/survey.html - are other departments trying something similar.

Note, there are pretty serious accessibility issues with the form, but just ignore that for now.

[bsouster]

I should have linked this earlier... If you're interested in customized formatting, I recommend looking at Dolphin's SuperNova. It has 24 colour schemes. You can change text colour, background colour, use large cursors, add focus highlights, magnify, and a lot more. If no two persons' requirements are the same, this tool will go a lot further to find each user's sweet spot. And it's not limited to the browser
https://yourdolphin.com/products/individuals/supernova-magnifier-screen-reader

[mgifford]

Thanks @bsouster I collected a bunch of widgets in a blog post here https://openconcept.ca/blog/mike/accessibility-widgets

Many widgets are proprietary. I suppose it might be possible for the GC to buy a government-wide license for it, but it still wouldn't make sense to put it into WET, if WET is attempting to be a platform that is bigger than the GC. It has to be open source.

The https://gpii.net has been trying to build something more comprehensive too.