Brain on Fire » Blog Tim McCormack says words

I'd like to talk a bit about why 1) image descriptions on Fedi are so great, and 2) why I sometimes reply to people's posts with a description of the image they posted without one. I was worried the latter might come across as passive aggressive, hence this explainy-post. This was originally a series of toots, but it got too long, so it's over here. Also, I want to be able to find it again, ever.

(This post is intended for an audience of people using Mastodon or other Fedi clients, but most of it also applies to image descriptions on the internet in general.)

After upgrading Ubuntu Linux from Dapper Drake to Edgy Eft, I found that the login screen would malfunction with the message "The greeter application appears to be crashing. Attempting to use a different one." A different login screen would appear (which worked just fine), but it was still irritating.

WCAG2 is, I believe, a blow against both accessiblity and web standards. Joe Clark writes his review of the draft guidelines in a recent ALA article -- more of a scathing burn than a report, really. And I would tend to agree.

Quite simply, the new guidelines, as the stand now in draft form, are impossible or impractical to follow in any realistic environment. They create obstacles for "normal" readers, actively dismiss web standards, restrict creative design, and obfuscate the basic principles of accessiblity (allowing everyone to access content in a reasonable manner). The guidelines are unclear, ambiguous, vague, and dense. Dense in that bad way, not just in that information-rich way.

In my next redesign, I think I'll use my common sense instead, thank you very much.

Problem

There is no accessible, standards-compliant way to code radio buttons in XHTML, because the label association mechanism conflicts with name and id attributes in radio buttons.

Solution

Replace the radio buttons with a select element.

Explanation

Form elements create key-value pairs through the use of name and value attributes. The form is serialized as an ampersand-delimited string of fields, where each field takes the form of name=value. This is fine for text input fields and checkboxes, which have a single-source structure in the HTML. However, radio buttons present a special problem. Each radio button in a group has the same name and a different value, indicating that they are the possible values a field can take.

Recall that label depends on the id of the form element with which it is associated, as well as the requirement that the name and id not differ on an element.

<label for="address">Address</label>
<input type="text" id="address" name="address" value="" />

How, then, does one code radio buttons with labels? Since all the radio buttons in a set will need the same name, each element with a label will need an id, and the id must match the name, the radio buttons will have identical ids. This is not in compliance with the W3 specifications, however, leading some web designers to choose accessiblity over compliance by appending an index digit to the id of each radio button.

There are further accessiblity issues that I will not explore here, such as visibility of the radio button itself, association of a label with the entire radio set, and visual interference between multiple radio sets.

A better solution is to scrap the radio buttons altogether in favor of the select element. The dropdown list is far more accessible, supports internal grouping of options, and consumes less real estate, yet preserves the data structure of the radio buttons.

Resources

• Alternatives to radio buttons: How to decide on a solution and refactor the associated text.