Tags: guidelines

Monzo tone of voice

Some good—if overlong—writing advice.

• Focus on what matters to readers
• Be welcoming to everyone
• Swap formal words for normal ones
• When we have to say sorry, say it sincerely
• Watch out for jargon
• Avoid ambiguity: write in the active voice
• Use vivid words & delightful wordplay
• Make references most people would understand
• Avoid empty adjectives & marketing cliches
• Make people feel they’re in on the joke – don’t punch down
• Add a pinch of humour, not a dollop
• Smart asides, not cheap puns and cliches
• Be self-assured, but never arrogant

Web Content Accessibility Guidelines—or WCAG—looks very daunting. It’s a lot to take in. It’s kind of overwhelming. It’s hard to know where to start.

I recommend taking a deep breath and focusing on the four principles of accessibility. Together they spell out the cutesy acronym POUR:

1. Perceivable
2. Operable
3. Understandable
4. Robust

A lot of work has gone into distilling WCAG down to these four guidelines. Here’s how I apply them in my work…

Perceivable

I interpret this as:

Content will be legible, regardless of how it is accessed.

For example:

• The contrast between background and foreground colours will meet the ratios defined in WCAG 2.
• Content will be grouped into semantically-sensible HTML regions such as navigation, main, footer, etc.

Operable

I interpret this as:

Core functionality will be available, regardless of how it is accessed.

For example:

• I will ensure that interactive controls such as links and form inputs will be navigable with a keyboard.
• Every form control will be labelled, ideally with a visible label.

Understandable

I interpret this as:

Content will make sense, regardless of how it is accessed.

For example:

• Images will have meaningful alternative text.
• I will make sensible use of heading levels.

This is where it starts to get quite collaboritive. Working at an agency, there will some parts of website creation and maintenance that will require ongoing accessibility knowledge even when our work is finished.

For example:

• Images uploaded through a content management system will need sensible alternative text.
• Articles uploaded through a content management system will need sensible heading levels.

Robust

I interpret this as:

Content and core functionality will still work, regardless of how it is accessed.

For example:

• Drop-down controls will use the HTML select element rather than a more fragile imitation.
• I will only use JavaScript to provide functionality that isn’t possible with HTML and CSS alone.

If you’re applying a mindset of progressive enhancement, this part comes for you. If you take a different approach, you’re going to have a bad time.

Taken together, these four guidelines will get you very far without having to dive too deeply into the rest of WCAG.

Link colors and the rule of tincture

When you think of heraldry what comes to mind is probably knights in shining armor, damsels in distress, jousting, that sort of thing. Medieval stuff. But I prefer to think of it as one of the earliest design systems.

This totally checks out.

Community Guidelines for Kottke.org

I like Jason’s guidelines—very in keeping with The Session’s house rules.

And I really like his motivation for trying out comments:

The timing feels right. Twitter has imploded and social sites/services like Threads, Bluesky, and Mastodon are jockeying to replace it (for various definitions of “replace”). People are re-thinking what they want out of social media on the internet and I believe there’s an opportunity for sites like kottke.org to provide a different and perhaps even better experience for sharing and discussing information. Shit, maybe I’m wrong but it’s definitely worth a try.

As I said in my comment:

Yes! More experiments like this please! Experiments that aren’t just “let’s clone Twitter”.

Readability Guidelines

Imagine a collaboratively developed, universal content style guide, based on usability evidence.

Privacy in the product design lifecycle | ICO

A very handy guide to considering privacy at all stages of digital product design:

This guidance is written for technology professionals such as product and UX designers, software engineers, QA testers, and product managers.

1. The case for privacy
2. Privacy in the kick-off stage
3. Privacy in the research stage
4. Privacy in the design stage
5. Privacy in the development stage
6. Privacy in the launch phase
7. Privacy in the post-launch phase

Introducing the GOV.UK Design System - Government Digital Service

The Gov.uk design system is looking very, very good indeed—nicely organised with plenty of usage guidelines for every component.

Guidance on using components and patterns now follow a simple, consistent format based on task-based research into what users need in order to follow and trust an approach.

Monzo – Tone of Voice

Monzo’s guidelines for tone of voice, including a reference to “the curse of knowledge.”

Vox Product Accessibility Guidelines

Accessibility isn’t a checklist …but this checklist is a pretty damn good starting point. I really like that it’s organised by audience: designers, engineers, project managers, QA, and editorial. You can use this list as a starting point for creating your own—tick whichever items you want to include, and a handy copy/paste-able version will be generated for you.

Useful accessibility resources

A whoooole bunch of links about inclusive design, gathered together from a presentation.

clean-code-javascript

Opinionated ideas on writing JavaScript. I like it when people share their approaches like this.

Design Guidelines — The way products are built.

A collection of publicly available design systems, pattern libraries, and interface guidelines.

Voice Guidelines | Clearleft

I love what Ben is doing with this single-serving site (similar to my design principles collection)—it’s a collection of handy links and resources around voice UI:

Designing a voice interface? Here’s a useful list of lists: as many guiding principles as we could find, all in one place. List compiled and edited by Ben Sauer @bensauer.

BONUS ITEM: Have him run a voice workshop for you!

10 guidelines to improve your web accessibility | Aerolab

1. Do not depend on color
2. Do not block zoom
3. Rediscover the alt attribute
4. Add subtitles and captions to your videos
5. Semantics = accessibility
6. Use the right mark-up
7. Use roles when necessary
8. On hiding elements
9. Follow web accessibility standards
10. Audit and review

Another Lens - News Deeply x Airbnb.Design

A series of questions to ask on any design project:

• What are my lenses?
• Am I just confirming my assumptions, or am I challenging them?
• What details here are unfair? Unverified? Unused?
• Am I holding onto something that I need to let go of?
• What’s here that I designed for me? What’s here that I designed for other people?
• What would the world look like if my assumptions were wrong?
• Who might disagree with what I’m designing?
• Who might be impacted by what I’m designing?
• What do I believe?
• Who’s someone I’m nervous to talk to about this?
• Is my audience open to change?
• What am I challenging as I create this?
• How can I reframe a mistake in a way that helps me learn?
• How does my approach to this problem today compare to how I might have approached this one year ago?
• If I could learn one thing to help me on this project, what would that one thing be?
• Do I need to slow down?

Amazon Alexa Voice Design Guide

A style guide for voice interfaces.

Vox Product Accessibility Guidelines

I’m not a fan of the checklist approach to accessibility, but this checklist of checklists makes for a handy starting point and it’s segmented by job role. Tick all the ones that apply to you, and this page will generate a list for you to copy and paste.

BBC - Future Media Standards & Guidelines - Accessibility Guidelines v2.0

The minimum dependency for a web site should be an internet connection and the ability to parse HTML.

Sass Guidelines

Advice for writing Sass. I don’t necessarily agree with everything, but on the whole, this is a solid approach.

It’s worth bearing Chris’s advice in mind.

CSS Guidelines – High-level advice and guidelines for writing sane, manageable, scalable CSS

Harry has written down his ideas and recommendations for writing CSS.