Accessibility improvements for user-agents

I’ve written about the accessibility-gap on the user-agent side before (back in 2007!), I thought it a useful time for an update. I’m trying to answer the question: What could user-agents (primarily browsers in this case) do to improve the experience of websites for people with disabilities?

You never know, maybe there will be someone at a browser provider who notices.

Unfortunately there is no good way to prioritise these suggestions – everything is important to some people. The order below is my guestimate of how popular they would be.

Some of these suggestions rely on a having a profile and/or setup page, where you answer questions like “Do you want web sites to be higher-contrast? No / Somewhat / Hell-yes”

The description for profiles is at the end.

If you have any additions / corrections / updates, please comment or email me (ac at this domain), I’d like to refine the list.

High (or other) contrast

There are two levels to this:

1. Themes which the site can provide (e.g. dark-mode).
2. Over-rides that the user applies to some or all websites.

These are separate in terms of interface, but there is overlap in how people use them.

Contrast – Themes

prefers-contrast is good, but suffers from discoverability on both the user and developer ends.

I.e. many users who would use it, don’t know that it exists. If contrast preference were part of a profile selection process, that would help.

It is also a bit blunt, as some users will want a light-on-dark high contrast, or vice-versa, and there isn’t an easy option for that choice.

Suggestion: Include a setting (and profile option) for enabling the site-defined high-contrast theme.

Contrast – overrides

Many sites (99%?) don’t implement themes, either due to lack of awareness or lack of resource. (Including this one, I haven’t updated the CSS since 2013, sorry). Therefore people who need higher (or lower) contrast have to override the site – if they can work out how.

There are mechanisms for overriding the colours on a website, but due to the infinite variety of how websites are put together, it’s easy to break things.

If forced-colors were more widely available than in Windows it could be something asked for by guidelines to implement more widely.

There are pluggins such as ‘high contrast‘, which are useful for some, but (according to an overlay vendor) it’s the most popular feature provided, it could be part of the browser.

Suggestions:

• Promote colour themes to something that is part of the Browser UI. Ideally with customisable schemes, but at least with two high-contrast themes (light on dark, and dark on light), and a lower-contrast theme using a pastel background.

Default focus indicators

Needing to see your current location is vital for people who can’t use a mouse or tap a touchscreen.

It is something that (until the relative recent work by the Edge team) had not been addressed by browsers well. In WCAG 2.2 we tried to ensure that focus indicators would be highly visible, and we were happy with the metrics required to do that. Unfortunately the complexity of testing those metrics across complex websites proved too much . It could be better resolved by the browser, we would love it if the author guidance could be: Don’t touch the outline. That isn’t the case yet.

The Edge/Chrome default indicator is a dark border and white outline, which works well in most cases, unless the component has a dark internal background on a white external background.

Suggestion: Update the default indicator to remove edge cases, e.g. move the indicator outside of the component, or use a filter colour that automatically has contrast.

Enhanced focus indicators

Edge and Chrome have a feature which adds an animated and very large blue focus-indicator for a few seconds around the thing that has just been tabbed to. That’s good, but if a user looks away and comes back, there may be no indicator. It is also blue which can get lost on blue backgrounds.

Some sites remove the indicator (or have a very feint one), so it would be great to add/incorporate an over-ride for the site’s indicator which is persistent.

Suggestion: Add an option (or incorporate into the animated focus indicator) for the browser’s default outline to be used when the animated one fades out.

One-column / variable column view

Media queries have been very useful in providing good access for zoom, as the author (designers/developers) can manage content for smaller screens (and therefore higher levels of zoom).

However, some folks have tunnel vision (or something like it) and would like a one-column view without zooming, so it is regular size but narrow.

Suggestion: An option (ideally with a browser control) to resize the viewport width to a desired size, without changing the whole window size.

Fixed headers/footers

Related to zoom, there is often a fixed header of 50-150px that is fine for mobile usage (portrait), but in a high-zoom scenario your effective screen height can be under 300px. (E.g. desktop screen, 1400 x 900 native res but browser zoom to 400% gives just over 100px height.)

A sticky header and/or footer can block your view of the content. Also, a modal or overlay which prevents scrolling can block access.

My advise to devs is to use vertical media queries to detect the height and un-stick the content when there isn’t enough space.

Suggestion: An option (ideally a toggle in the browser controls, or option to show one) which unsticks elements from the viewport.

Moving content (mainly layout-jank)

Scrolling down pages with dynamic adverts (you know the ones, they load in and move all the content down randomly) are even more painful for people with cognitive disabilities.

Suggestion: A ‘freeze content’ button (or other wording). A bit like the reader view, but instead of converting the page into another format, it just stops all animation and loading of new content.

Autoplaying videos

For people who struggle with distractions, auto-playing videos (even if muted) are difficult to deal with.

I’m sure there are (or have been) preferences around video, e.g. “Control if audio and video play automatically on sites” Allow/limit/block in Edge. However,  I had to search for it, and look at the permissions grouping. It’s not easy.

This may need more research/testing, but I *think* there are ad videos which get around this.

Suggestions:

• If an auto-playing video is detected, include a button on one side of it called ‘prevent auto-play’.
• If there is a profile, include video auto-play with the animation / distraction options.

Cursor size adjustment

Adjusting the cursor tends to done via the operating system or with assistive tech. However, it can also be affected by authored CSS, and some indicators (e.g. over text-entry) can be hard to see. Also, buttons (by default) don’t change the cursor to show that it is interactive which has always puzzled me.

Suggestion: Provide an option for a highly-visible cursor.

UI for keyboard navigation of Headings and Landmarks

Screenreader users can access landmarks and headings to navigate around the page, but other people who use switch-access, voice-input, or other non-mouse/SR inputs cannot.

There is a plugin for SkipTo Landmarks and Headings, but it’s virtually unknown to the people who actually need it and it’s hard to work out the keyboard comments. If there were a profile where you ask questions to work out the needed adaptations and provide the keyboard access, it would be much more useful.

Suggestion (with a profile): Include keyboard commands and documentation for skipping to headings and landmarks.

Keyboard access to tooltips

Authors often hide information behind standard title attributes and custom tooltips that are only available on hover.

Due to abuse / the volume of these features, it would be counter-productive to enable them by default, or show them all the time.

Suggestions:

• An option to show on-hover tooltips when focused with the keyboard.
• A toggle in the browser chrome for showing all tooltips.

User profiles (for adaptations)

No-one wants the options that are not relevant to them. But, there’s a lot of possible adaptations people make, and that browsers could support.

Ideally the user’s adaptations would be part of their profile with the browser, where it asks the user on first-install whether they would like to set preferences to make sites easier to use (or words to that effect).

It could be part of the default user-settings, which is then shared across the user’s signed-in instances of that browser. The missing piece a UI for this during setup, ensuring users know what is available and what it means in practice.

Suggestion: On first install (or next update of the browser, after adaptation settings are introduced), a browser-window asks the user what (if any) adaptations they would like.

I assume this would be a bit further down the line, after more settings are included, but it would get over the biggest problem: Awareness.