January 9th, 2019
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.)
Read full entry »
Comments Off on Image descriptions on Mastodon | Posted in -no category-
October 28th, 2006
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.
Read full entry »
6 comments | Posted in Solutions
May 31st, 2006
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.
Comments Off on Accessibility vs. WCAG2 | Posted in Uncategorized
May 20th, 2006
- 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 id
s. 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
-
Comments Off on Radio buttons not accessible | Posted in Uncategorized