Press "Enter" to skip to content

Tag: web standards

Usability and Accessibility Focus Groups

Roger at 456bereastreet illustrates how to usefully enact a small scale usability test. I commented there; the expansion follows.

I think it’s important to stress how much usability norms can differ across different audiences and regions, and how much adaptability and approachability after publication should be more of a factor in determining requirements. A company/organisation/community with no prior experience of its audience will have no conception of the capabilities permissible, and so would have to offer the bottom line. It may turn out that that’s insufficient, because your majority audience turns out to be extremely competent and technologically advanced – they may desire the complexity, because they can use it.

See the (admittedly badly formed) article at The Register on Google and scope for some brief comments on the different perceptions that east and western cultures have of what the internet itself means, let alone usability of it.

Any designer should aim to follow the simplest approach possible, adding on optional extras as the user goes through the process, without complexifying things too much. Usability in such a case might therefore be reducible to a set of criteria, or dare I say it, standards.

But it can’t, of course, and we know why. Usability, and accessibility, are individual characteristics particular to each and every user, and so depend on a combination of user knowledge and education, and designer prediction and “leeway” to allow a vaguely balanced experience. (let’s exclude perhaps one of the least usable sites on the web, Jakob’s, which fails not by structure but by design)

All of which brings me to: usability and accessibility studies which involve “real life” users are immensely important until the designer gets it. At that point, unless they pay no attention to web trends and societal change, they have a reasonable – while not expert – understanding of what to provide.

We can try to appoint a representative council of “disabled people” to test our websites, but have we considered the depth of experience that different blind people have with different screen readers? Have we considered the lack of knowledge of basic computer usage, that many disadvantaged people may have, or the misinterpreted functions of lacklustre browsers and operating systems (alt = tooltip being a relatively minor one)?

Each person is an individual. A person is impaired by the barriers placed on them; as a designer, it is therefore critical to ensure that a website contains as few barriers as possible, without even considering the type of user who may stumble across it. It isn’t about testing whether a blind person with an advanced knowledge of JAWS can use a site: of course they can, they’ve persevered for the past 8 years trying to make sense of it all, so they can work out your silly little code. It’s about the baseline, the average user who has a very slim understanding of the internet, of the way a browser works, of the way a computer works. We have a project which looks at the way people from different backgrounds may face challenges using a VLE, but it can apply equally to websites.

In fact, in a lot of cases, you may find that disabled users are more competent than their counterparts, purely because they’ve had to try harder. That’s not a problem, but worry less about the specifics of how a particular screen reader may respond to a certain type of list, and worry more about whether the harsh black on white text you have will cause people with specific learning difficulties, people with a tendency for migraines, and people with even marginally poor vision, to react badly to your site and may even force them away.

Furthermore, reasonable is perhaps the best stage to be at. Nielsen may have an excellent understanding of usability, but he has no idea how to implement it. Joe Clark has a fabulous understanding of captioning and many accessibility issues, yet he still frightens everyone off by being Joe Clark, hence prohibiting access. Experts are absolutely necessary, but not in proliferation; here the jack of all trades is more or less enough.

Comment Spam: Some Thoughts On Accessibility

Aggregated from posts at

Tommy Ollsen has had some trouble with spam comments on his blog. I can’t sympathise, because nobody visits here. 🙂 But in patience for the day, some accessibility and usability concerns…

I’ve always been very confused by blogs which have allowed comments, but not when you come across them (months later). It’s not intuitive or usable, particularly where discussion boards are based around the whole idea of years-long threads. So if you do go ahead with, make it very explicit that there’s a reason for no-comment, otherwise you get users looking around the page for the comment form, or thinking they’ve been banned.

If you’re going to close comments, make it clear on the page – it would particularly ne usefulwhen located in the same area/style division as the comment box would usually be, so that if you’re already aware of the site design it’s clear that something’s different on this page.

There’s an argument for closing comments, but there’s also a flipside. I’ve come across various important discussions (Mezzo/Malarkey spring to mind) by searching for them, and where there are still “gaps” in the conversation. That’s why the “bumping” feature of forums is a very useful feature, in that it can reignite debates which haven’t properly concluded. However, as a blog/journal it’s clearly a different matter, but you could argue that a “Ten recent comments” list could include all comments from all entries, rather than just the open ones, so that any user would see that the old/archived ones were still in use, and thus reflect/comment further on the new entries.

Consider whether it is worth pairing the timeout (based on the original post date + x days) with some sort of activity figure (if comments made in past 28 days > 2) which flags the entry for human intervention, to work out whether the conversation really is going on for months and months (and so where it’d be a shame for the timeout to apply), or whether a sneaky comment spam has just held it open.

In the end, I think at the moment – without resorting to some extreme filtering/AI techniques – in order to allow the blog to be sufficiently useful over a wide range of people and over a reasonable length of time, it’s going to have to be the compromise involving a machine making broad decisions and flagging up things it’s concerned about to a human, in the same way as simple email spam filters work. Sad but true.

Acronym vs. Abbr!

A long debacle has plagued the web standards community: that of ABBR vs. ACRONYM.

Let’s get one thing straight, to begin with: an acronym is still an abbreviation. Everything that is a contraction of a fuller version is an abbreviation. Acronyms, initialisms, 2nd-class-initialisms, communist-initialisms – they’re all still abbreviations.

HTML tags exist for the purpose of alerting the user agent to do something different. CSS exists to illustrate to the user how things are done differently.

This means that use of abbr at a base level is more than enough, because the user agent (including assistive technology) is aware that the content within the tags is not to be treated as standard text, and it can therefore work out from the tag you used what your intention was. A screen reader relies on an extensive dictionary to be able to pronounce any word, and it will/should rely on this dictionary to work out whether it feels a set of characters, marked up as an abbreviation, should be pronounced in a different way (either as letters, or as a word but with the option of also saying the expanded meaning).

Where there is ambiguity, there will be ambiguity for everyone, and so the content author should learn to write content better. (for example, logically, IE and i.e. could be equivalents, depending on the individual and/or the localisation norm. But it may seem clear to the content author which is which).

Assumptions will always have to be made about the user, and the user agent, analysing content. That’s why well written content will also include an expansion of an acronym/initialism in parentheses, unless it can be safely assumed that the anticipated audience will already have this knowledge. The benefit in expanding etc. into etcetera by use of any tag is slim, since it still makes the assumption that the user knows what etcetera means, that the user-agent/AT will be better at saying/reading etcetera than it will be by intelligently interpreting etc. and it makes the assumption that AT developers aren’t capable of making the technology intellegient and/or localised, with UK and US dictionaries usually being the first stage.

There is far too long a chain of possibilities to be able to reliably pick either ABBR or ACRONYM or another tag. You may use a colon to introduce a list, as you grammatically should, but another person may use a colon-hyper combo to do it. What are you able to do to ensure that the screen reader delivers the correct length of pause in order to indicate it’s a list? (and before you answer, do you really advocate marking up:

Western languages make extensive use of acronyms such as “GmbH”, “NATO”, and “F.B.I.”


Western languages make extensive use of acronyms such as [ul class=”inline”][li]”GmbH”,[/li][li] “NATO”,[/li][li]and “F.B.I.”[/li][/ul]

and perhaps using CSS’ :before and :after to insert the commas and ‘and’s for a list item with the class ‘last’? Semantically, it’s a lot more meaningful and less ambiguous than what we had before.)

Anyway: there are too many nuances of too many languages, and dialects of languages, to be able to provide appropriate tags for them all. All that is required is for the content author to ensure that pieces of content which are not standard words – i.e. use formatting (capital initials) or punctuation (etc.) – are marked up to indicate to the user agent that something different needs to happen here. The user agent and the user themselves are then responsible for interpreting how this content should be broadcast. Use of localised assistive technology, with frequent dictionary updates to follow current language fashions and trends, would ensure that the user is receiving a reasonable interpretation of what the author is trying to say. It’s then up to the user to keep educated enough to understand what the user agent is offering to them.

Solutions? Gez Lemon suggests using this for print stylesheets, or for people with poor mobility in their alternative stylesheet:

content: ” (” attr(title) “) “;

Finally, on repetition of acronyms, users and UAs should handle this in their own way – if a user doesn’t understand an acronym because they’ve hit the 3rd usage of it, common convention (and the guidelines) will indicate to them that it might be somewhere else on the page, and so will be encouraged to look for it.

Either that, or they google it like I do when I don’t understand something. I then ignore the google results and click on the definition to go to, then click on the acronym link to go to But that’s just for bandwidth abusers!

It’s entirely conceivable that a UA should provide a context menu for acronyms/abbreviations that give you a number of choices – one of these would be very simply to get the UA to look at the rest of the page for you, and identify the first (or better, previous to the current) instance of the acronym, and take the title from there. If it just shows you this in the menu, even better. Another option could be exactly the above – search for the acronym in the predefined website/dictionary of the user’s choice etc.

And we could end up with limitless resource and pamper everyone…. 🙂

Final word: use of the ABBR tag is the most generic possible in the current W3C specifications, and is the only one which should be used unless there is certainty that it’s an acronym as well. In this case, the abbreviation should perhaps be wrapped in both – a nightmare of tag soup, but the standards (and Microsoft’s absurd understanding of them) do not serve us well. Semantically neutral tags don’t really help us, because this is semantic. Ideally, duplicate the effort by providing the expansion of the abbreviation in an alternate form, so you’ve got all bases covered. Any comments from any users as to whether this has ever actually mattered to them, would be most enlightening to, and may help put the matter to rest….