Journal

This post from earlier this year offers a similar encouraging message to Henny Swan’s recent The only accessibility specialist in the room. It contains advice that’s worth remembering when we have one of those ”what’s the point?’ moments!

Advice like:

• Get started; don't wait until everything is done and perfect
• Small steps make a big difference
• Educate, don't berate
• Think of accessibility as an ongoing journey with no finish line

Nathan on how complex components require comprehensive specifications rather than ill-advised assumptions, and how Figma can be used to guide engineers to reliably build such components.

I’m still amazed when designers schlep together a few pictures, publish a configurable Figma component, point their developer counterparts at the main component and say “Use Figma’s inspect tool.”

Things have changed. Components are more complicated. Designers are delivering to many different developers. Accessibility has risen to the fore. For design systems that scale, teams are finding it necessary to write down all the details again.

At work in our project to improve our component documentation across the component life-cycle, we’ve been following Nathan’s advice and using his plug-in to assist with the “specification” aspect.

Had a great day with Mark and Alan on Saturday climbing Ben Lomond. Although I’m not much of a hill-walker I reckon that’s the third Munro I have bagged.

We were staying overnight at our friend Jim’s family cabin at Rowardennan and it was a short walk from there to the mountain. The start is steep and the weather progressively worsened until the rain was horizontal, but nonetheless we reached the summit (3200 feet above sea level) in around two hours then skipped back down in just one more hour. We were pretty proud of ourselves to complete the walk in just over three hours!

After that we enjoyed steak pie, fish and chips and victory pints at the Rowardennan hotel. A perfect day.

Mind you, over the last couple of days I’ve been feeling pain in muscles I didn’t know existed!

I’ve been:

• reading The Islander by Chris Blackwell and Paul Morley
• watching Oppenheimer on the big screen and The Bear on TV
• listening to 1982 by A Certain Ratio and Matt Wilde’s Hello World
• out to see Moorcroft at the Tron and thinking about it ever since
• enjoying collaborating and socialising with teammates in the office but not loving the commute
• at one wedding (Lou and Tom) and one funeral (Aunt Elsie)
• losing sleep while Rudy goes through a night-whines phase
• starting to re-find some form at table tennis training
• wanting to write regular posts like this – this is the test run!

Something Adrian Roselli said recently has stuck with me. The gist was that when developers need definitive guidance they shouldn’t treat MDN as gospel, but rather refer to the proper specifications for web standards.

Note: this post is a work in progress. I’ll refine it over time.

HTML

The HTML Living Standard

The Edition for Web Developers version looks handy. It seems to be streamlined and you can also use the forward-slash key to jump straight into a search then type something like “popover” to access that specification quickly.

WCAG Accessibility

How to Meet WCAG (Quick Reference)

Adrian referenced the above in one of his blog articles.

ARIA

W3C’s ARIA in HTML document

Adrian will quote or reference this when talking about roles, landmarks and the like… for example when he tweeted about developers using section.

Note: the above resource somewhat confusingly describes itself as a W3C recommendation. But despite that naming it should be regarded as definitive guidance. That description links to an explainer of W3C recommendation confirming that these are specifications which have been endorsed by W3C, that software manufacturers should implement, and that may be cited as W3C standards. My understanding is that if a specification is at an earlier stage it will be described as a W3C proposed recommendation.

Miscellaneous notes

How useful is MDN? I’ve read before that it’s not definitive. But it has recently had some good people work to improve its references to accessibility

MDN typically references WHATWG HTML, which often gets accessibility… well, not quite right. Part of my efforts included updating the accessibility content to point to the W3C specs wherever appropriate.

Adrian tests how blockquotes, marked up in a variety of ways, are announced in different screen readers.

He concludes that his personal choice is as follows:

<main>
  <!-- other content -->
  <blockquote>
    <p>A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.</p>
    <footer>— <cite>Douglas Adams, <a href="https://en.wikipedia.org/wiki/Mostly_Harmless">Mostly Harmless</a></cite></footer>
  </blockquote>
  <!-- other content -->
</main>

He avoids the cite attribute completely because it creates noise in JAWS, and recommends against using figure with figcaption because it results in unnecessarily verbose and duplicate announcements.

In his chosen approach the footer is used mainly as a sensible styling hook, since in the context of a main (as opposed to as a direct child of body) it is not regarded a landmark and is strictly presentational. The cite element has semantic intent – it’s the element for marking up the title of a cited creative work – even if those semantics are not always exposed to users.

So there’s an action for my team at work, because our blockquote component currently uses figure and figcaption. Perhaps at the time of build we took advice from one of the MDN or W3C pages which Adrian has now shown weren’t ideal.

There’s a great section on Source order and layers in Every Layout’s Imposter layout. It’s a reminder that when needing to layer one element on top of the other you should:

1. favour a modern layout approach such as CSS Grid over absolute positioning; and
2. not apply z-index unless it’s necessary.

which elements appear over which is, by default, a question of source order. That is: if two elements share the same space, the one that appears above the other will be the one that comes last in the source.

z-index is only necessary where you want to layer positioned elements irrespective of their source order. It’s another kind of override, and should be avoided wherever possible.

An arms race of escalating z-index values is often cited as one of those irritating but necessary things you have to deal with using CSS. I rarely have z-index problems, because I rarely use positioning, and I’m mindful of source order when I do.

In web-based products from e-commerce stores to email clients to accounting software you often find index pages where each item in a list (or row in a table) has a Delete option. This is often coded as a link… but it shouldn’t be.

I liked this comment by Rails developer Dan where he advises a fellow Rails developer that to create his Delete control he should use a form rather than a link, via Rails’s button_to method.

Dan mentions that in the past Rails UJS set an unsdesirable historical precedent by including a pattern of hijacking links for non-GET reqests.

But per the HTML standard, links are for navigation:

Hyperlinks… are links to other resources that… cause the user agent to navigate to those resources, e.g. to visit them in a browser or download them.

And as Dan goes on to say that’s why links make a GET request.

A GET request is a visit, it says “show me this” and it’s idempotent. When you make the same request it’ll show the same thing.

If on the other hand you want a control that performs an action (in this case request an entity to be deleted) then the appropriate HTML element is usually a button, and in this case a submit button within a form.

Relatedly, Jeremy Keith previously wrote about how to use request methods properly in his excellent post Get safe.

Love Matt Wilde’s music and his new LP Hello World is even better than expected. Beautiful laid-back and understated vibe from start to finish. Lovely artwork too.

Cheers also to Band on the Wall recordings for the surprise tote bag!

I really like Jim’s idea of putting an avatar file somewhere that’s memorable and easy to access by me wherever I am and that also (in the future) might be automatically grabbable by any platform that needs my avatar.

So I’ve put my avatar at fuzzylogic.me/.well-known/avatar.

Great idea, Jim!