The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Average Users and Accessibility

Or, why to design around misuse-cases.

The longer I use consumer computing, the more I’m convinced that it shouldn’t require much knowledge at all. They have familiarity with some aspects of consumer computers, while they are on average more ignorant of its underlying nature, and those who are interested will learn more about the bits behind the pixels. But it’s clear that we shouldn’t expect the user to know too much, as many will not.

It’s quite a challenge, and it deserves an example. One that comes to mind is Unicode and emoji. The average user saw something like Wordle and gladly spammed Twitter with a bunch of emoji boxes that made those tweets ugly to the ears of users with screenreaders. And in general, the misuse of emoji and unicode characters for purposes other than they’re intended are harmful to accessibility.

But the average user that just wants to make a cool looking thing doesn’t know about accessibility. And while learning about it is good, and it can lead to people supporting accessibility-first not just in computing but in general—which has the knock-on effect of making the world better regardless of abilities—we generally recognize people will only learn about what they want. If they find it interesting, they’ll learn, but most people are too busy or uncurious.

So we necessarily should design with the ideas:

  1. Lots of people will want to misuse the system.
  2. Fewer people will want to abuse the system.
  3. We need to design to defend against [2], but allow for [1].

(The distinction between misuse and abuse is one of malice. Using a fork to stick a note onto a cork board is misuse. Using a fork as a weapon is abuse.)

Going back to the unicode and emoji example, what does that mean? Let’s take the Wordle example. They want to paste their scores, and we don’t want to screw over screenreaders, and we also don’t want to have to design some extra input (e.g., alt text) that lots of people won’t use. What we want to do is have some way to let the text-meaning be included alongside the emoji, so the paster doesn’t have to do anything, but the screenreader can make the distinction. This would likely involve the use of the Javascript Clipboard API, adding an extra MIME type (something like text/srfriendly?), but where the consuming application requests paste data of both the text/plain and (if available) text/srfriendly.

The result could be the consuming application getting the collated data to enable the display version, but allowing screenreaders to fall back on the superior version for their application.

(We should still have alt text for fallback for images, of course. Indeed, there should be an initiative to let us embed alt text in the image file rather than needing to add it separately. [Actually! See Lexdis 2.0: 27 June 2022: “Exploring the embedding of accessible image descriptions into image metadata”, which links to and quotes from an announcement by the International Press Telecommunications Council (IPTC) that its photo metadata standard now includes fields for textual descriptions. Neat.] It would be more convenient for most people to add the alt text at the point when they create the image than when they embed it. (Though we should still let them provide an alternative alt text at point of embed. It can be prefilled with the version from the image.))


The addition of a MIME type for applications would help those cases, but contexts where users frequently misuse unicode should also allow for the alternate input to be added, whether by the original user, by tools meant to offer cleaned versions, or through crowd suggestions. The average misuser of unicode isn’t going to stop doing that. Only by giving the option to misuse while still filling in the gap misuse creates will cover all cases.

Cleaning the Other Side of the Browser

It’s a messy world. The new generation of browsers are cleaning it up a bit; they are actively pairing down the amount of administrative chrome that surrounds the content. And that’s great, because it makes half of the web better.

It’s a messy world.  The new generation of browsers are cleaning it up a bit; they are actively pairing down the amount of administrative chrome that surrounds the content.  And that’s great, because it makes half of the web better.

But it doesn’t make the web better, it only makes the browser better.  It’s still mostly the same web.

It’s the web with too many irrelevant advertisements.

Too many sites with clutter.

Too much bad typography.

Bad suggestion engines and search results.

So, accepting that each website is like a public toilet stall, with whatever has been scrawled on it, what happens if everyone is given a marker?

Some sites have tried that.

Readability tries to pare down any site to just the content.

There are also things like Greasemonkey and Stylish, allowing users to apply their own scripts and styles to pages.

But these things rely on the current version of sites.  They are subject to breakage, and the site owners want you to view it the way they say.

That’s an older problem.  Some religions wanted you to look at things their way, to the point where they controlled the availability of sacred texts or the ability to read them.   Kings used to have the power, but even when democracy took hold there were countless attempts to control who voted and ran for office.

It’s worth pondering though.  We need to clean the other side of the browser, from bad path design to clutter to typography.  Too much dictated design makes the web less useful, and it stifles the spread of information.

JQGTK+ Color Selector

Last month I wrote about the issues with color. Today I’ve put up a color selector based on the GTK+ Color Selector.

Last month I wrote about the issues with color.  Today I’ve put up a color selector based on the GTK+ Color Selector.  You can try a demo at Sequlr: Color.

The basic idea was to first recreate the GTK+ Color Selector with canvas, and then add a filter and the compliance information to it.

It’s decent, and although I found a few other color selectors that tried to improve the ability to choose compliant colors, I didn’t come across one that used this method.  Also, those that want to can use it as a widget in their own projects.

It should run okay on the newest browsers, though it may be sluggish on older ones, especially on slower computers.

Thanks for reading.