jake said:
Why? Why is it 'terrible'?
The idea (most simply stated) is "annotate the incomprehensible and
make it accessible". This is a good idea, and I think most of us would
support it.
However their "d link" approach is bogus. Rather than marking up the
item that is affected, they link to a wholly separate resource. There
are a lot of things wrong with this:
Why it's a bad idea:
- It's very far from obvious. What's this "d" floating around all
over the page? Why should I want to click on that?
- It's itself an accessibility issue (and I think this is the most
serious problem) – let's suppose I can't resolve the image because my
elderly vision is suffering, but I'd like to read a description of it.
How am I expected to find or recognise a single character as a link
marker?!
- It's unusual. "d links" are _not_ common. As their only possible
usability depends on them having good branding and immediate
recognition, then that's serious.
- It's patronising. Why not go the whole hog and label it
"Cripples click here (or get your carer to do it for you)"
- And the killer: "Find out what the little "d" means"
This is effectively a user manual. We had those ten years ago, back
when computers were hard to use and scary. Nowadays anyone can use
computers for two things (and largely, that's all they do use them
for) – browsing the web and playing games. You'll note that neither of
these rely on following a manual or instruction and that's _why_
they're successful. If you need to _explain_ it, you've failed as a
usability designer. If you need to explain a "usability" feature, then
that's ludicrous.
Why it's a poor implementation:
- So what happens when you navigate a "d link" ? You lose the page
context (this _would_ be a good use for a pop-up) and the annotation
replaces the entity it's describing. Think about that objectively for
a moment ?
- There's nothing formal linking the resource to its annotation.
- As far as machine-processable metadata goes, this is requiring the
page author to do a lot of work in setting up this annotation system,
then hiding the results from anything resembling a web crawler. Dumb.
What would have been better:
- Simple thing - Take that annotation, and display it on the page,
right alongside the thing it's describing. Why should the disabled get
all the fun?
- Show the annotation on the page. Use CSS / JavaScript to hide it in
those circumstances when it's excessive and when the current browser
platform/config lets you do so (this isn't rocket science).
What do you find 'inaccessible' about the
http://www.mainecite.org/
site? Specifically.
It's not a bad site accessibility wise. Specifically it's a _simple_
site, and that's always a free-lunch for accessibility. Why worry
about the best way for a multi-column layout when you can simply avoid
it altogether?
THIS IS NOT A _BAD_ SITE FOR ACCESSIBILITY
We know this – oh, we've seen _much_ worse !
But it's a site that has a target audience where accessibility, and
general web-naivety, are major issues. They're also "in the business"
of accessibility. As such, we expect _better_. They accept this
themselves – else why bother with the Bobby eye-candy ?
The accessibility issues are largely minor things – but equally they'd
have been minor things to correct. Why bother setting an alt and even
the (rarely-used) longdesc attribute on images, yet ignoring the title
attribute ? I use Firefox as a browser – I don't see these alt texts,
when I could so easily have been given them. Kudos though for
realising that longdesc is a URI, not human-readable text.
How about a few titles elsewhere too? Links should be titled – it's
cheap to do, it's demonstrably useful to a whole lot of user
interaction models. It's usual that the text content of an <a> element
is equivalent to the title, but it's not always so. Placing something
into a title attribute is a direct indication that it's meaningful as
such, even if it's a mere duplication of the element's text content.
Maybe to you and I it's "obvious", but there are lots of assistive
technologies where it's anything but, and this strong hint is helpful
to them.
Lists could benefit from title too. Some of the lists, particularly
the footer menu bar should be marked-up as either <menu> or <ul>, yet
they're constructed from a simple <br> and list of (untitled) <a>'s .
There is no distinction being made here between "any old link" on the
page, and what is a fairly major navigation tool. Again, this is a
trivial issue, but it's still a _real_ issue, and it's an issue where
the fix is itself trivial.
Worst of all, the links on the home page _do_ have titles. Except that
instead of putting them in a sensible place, they're stuck underneath
some JavaScript roll-over code. Then they appear in the centre of the
page, well away from the mouse location and the actual link! This
isn't just a disability accessibility issue, it's piss-poor design all
around.
How about using <address> for that telephone contact number? For
vision-restricted users that's just about the most useful part of the
page, yet there's no way to find or highlight it easily or
automatically? Yes, this is me doing the SemWeb blue-sky pitch again,
but with trivial CSS in a user stylesheet _right_now_ I can make those
contact details light up for the user, for just the effort of adding
that element.
What's with the "Skip past menu items" link? This jumps over the menu
footer, which is about three lines of text. It is pointless as a
navigation feature and simply adds excess crud. Perhaps there's a page
where it does have a function (in the right context, it's a good idea)
– but using it in the pointless case like this also devalues it from
when it could have added something.
Accessibility isn't rocket science. I've seen almost no feature where
boosting accessibility was at all complicated – almost every
improvement depended on _simplifying_ something, not adding bells and
whistles.
They also have a number of eye-candy logos on the page – the
ubiquitous "Valid HTML" button appears. Except that this page is not
only invalid mark-up, but it's not even HTML. They have legacy
bit-rot. Once this sets in, standards compliance falls apart and
pretty soon so does accessibility.
