Human-centred

How to get the most out of AI

2026-07-27T00:00:00+00:00

AI (in this case, meaning mostly LLMs like ChatGPT and Claude) is powerful and can be very useful! It’s great at transforming text, converting formats, generating code, and more.

But/and there are ways to use it to get the most out of it. Knowing what it can do well and what it can’t do well lets us choose where, when, and how to use it. In particular, using AI can be worthwhile when verifying the output is quicker and easier than producing it ourselves.

Ask for critical review, rather than asking for approval

Be a student. Ask AI to find holes, mistakes, and improvements in the work, rather than ask it if we’re right.

AI is fast at generating options, but less useful for confirmation. To varying degrees, it’s trained to tell us what we want to hear. Even if we suggest a bad idea, the AI can say it’s a good idea, and tell us we’re right.
This can be especially tricky for high-stakes and/or interpersonal topics!

Treat responses as a possible answer, rather than the only answer

Be a scientist. Use AI when we don’t need the same output for the same input.

AI output is probabilistic, non-deterministic: the same input won’t always give the same output. That’s useful for making variations, but it can mean trouble when we need precision or accuracy!
Sometimes plain old automation is all we need, so keep an eye out for that.

Check the details, rather than trusting them

Be a detective. Don’t treat AI output as factual information: check everything it produces, in fine detail, for accuracy and consistency.

AI produces plausible text rather than facts. True things are often the most plausible, but not always!
This leads to “hallucinations”: confidently stating false information as true. In particular, AI tends to get specific facts wrong. There has been some progress on this, though.

Try “AI in the loop”, rather than “human in the loop”

Be a surgeon! Use AI precisely and accurately, use it where it’s strongest: reviewing, providing options, general rather than specific things. But/and start with the problem rather than AI as the solution. Do some of the work/thinking without AI first.

When we start with AI as a solution, we look for problems that AI can solve. Doing the thinking ourselves first helps guard against cognitive atrophy and cognitive offloading.
AI makes it easier to jump to an answer rather than deeply considering the question and the process to get to the answer. The process is where we learn and make decisions. It’s where we’re challenged and apply active effort, critical thinking, and analysis.

How to get the most out of AI was originally published by at Human-centred on July 27, 2026.

Helping AI-written code be more accessible

2026-07-15T00:00:00+00:00

Some quick notes of what engineers seem to be saying about accessibility and writing code with AI.

Things people are doing already

Most teams are already doing a mix of these things: static analysis, unit tests, integration tests, end-to-end (e2e) tests, CI. Accessibility can be included in each of these.

Using an AI to write the code
Static analysis with the eslint-plugin-jsx-a11y plugin
Unit tests with jest-axe
- I’ve seen most teams lean heavily here rather than further down the list. I have mostly been working with Design Systems teams, though.
Integration tests
e2e tests with @axe-core/playwright
- using getByRole with accessible name
- using toHaveAttribute for ARIA states
- I’ve seen teams using getByTestId, and Quality Engineers recommend this as the preferred way. The argument is something like: we want to avoid using DOM-related selection in tests so that they’re more resilient, and we don’t care about the implementation. That’s true for classes (that are used for presentation), but for accessibility tests we do care about the DOM, the implementation, the HTML and the ARIA attributes.
Using CI to block a merge until all tests pass, including all the a11y tests above. That means failing tests return an error instead of a warning.

Some previous notes that cover some of these in a bit more detail: Dessert: The Accessibility Testing Trifle; Automated Accessibility Testing.

Things that look new to me

Accessibility-flavoured prompt constraints

Using a persistent context to guide the AI
- .cursorrules or .github/copilot-instructions.md or CLAUDE.md
  - These point out to SKILL.md files for specific tasks and framework usage
- For accessibility these will be about semantic HTML, accessible names and attributes, keyboard interactions, testing patterns (as noted in the previous section)
Use libraries that are known to be accessible (see the next section for more on this)

For many years, it’s been fairly common for some teams to argue that accessibility-related tests shouldn’t fail the build. Other tests do, but these should somehow be exempt.
As a short-term measure, for a team that’s working on a large backlog of issues, this could be workable. Although it would be better to add tests slowly and fix things as we go.
Now it seem like more teams are willing to admit that AI-generated code is likely to be inaccessible, and we want to be sure we catch any issues.

How to get the most (accessibility) out of a library (or a design system)

I think the best way to get the most accessibility out of a library is similar to how to get the most (accessibility) out of a design system:

Use the right components in the right place, following good documentation
Run tests to check for any error or omissions we’ve made, or the library (or design system) has made
Give feedback on the components, using the components, and the documentation

Here, the decision of which component to use might be by the human, or it might be from the AI reading the docs. It might start even earlier, with the designer labelled something a specific way in the design.

Screen reader testing workshop for WWAM

2026-07-12T00:00:00+00:00

Hi, folks at the Wellington Web Accessibility Meetup! 👋

Short URL for this page: bit.ly/wwam20260723
Google doc handout with keyboard shortcuts

Before we begin (5m)

We'll focus on free, laptop, screen readers

Laptop/Desktop screen readers
- On Windows, we recommend NVDA (it’s a bit more mature than Narrator)
- Narrator comes bundled with Windows
- VoiceOver (VO) comes bundled with macOS
- JAWS (Windows only) is also good but expensive
For quite a lot of testing, especially simpler components, we usually find the same issues whichever SR we’re testing with
- The jump from testing with zero screen readers to one is much bigger than the jump from one to two (or three).
No mobile testing today (VO on iOS, TalkBack on Android)
- Laptops a bit better to huddle around in a group
- Tricky to do both since they’re so different

We're just covering getting started

This session is short, so it can only be a taste test
Many of the problems occur with the building blocks of the web (headings, images, links, and buttons) so there’s value in testing there
There’s loads more to explore and learn if you’re interested! Including: changing the voice, the speech rate, the verbosity, and more.

Test a fairly familiar page

Something you use often
Something from work!
Google your favourite fruit or animal (hint: it should be capybara), then follow one of the search results
Use some of the WebAIM practice pages: look for “examples and practice” links on Using NVDA to Evaluate Web Accessibility

Use popular browser-and-SR combinations

Although you can use any browser, these generally give best results:

NVDA with Firefox
Narrator with Edge (the OS defaults)
VoiceOver with Safari (the OS defaults).

Do some gentle group discussion

After each section, we’ll go around the room and ask each group to share a few sentences about how they went
Nothing formal, no need to stand up or prepare anything
So that we share the love around the room a bit

Agenda

Intro: What does good sound like? (5m)
Demo: on/off, next/previous, shh! (5m)
- Once-off set up (5m)
- Practice: on/off, next/previous, shh! (5m)
Discussion: on/off, next/previous, shh! (10m)
Theory: we’re testers, not users (5m)
Practice: headings, images, links! (15m)
Discussion: headings, images, links! (10m)
Theory: the two modes of SRs (5m)
Practice: form and function (15m)
- Aside: listing things (5m)
Discussion: form and function (10m)
Get help! (5m)

Intro: What does good sound like? (5m)

Broadly speaking: it should sound the same as it looks.

Names and roles are announced

For example: "button, save"; "contact us, link".

States, properties, and values are announced

For example: an expanded state on an accordion, the text in a text field

Groupings and landmarks are announced

For example: a group of radio buttons; the main navigation.

Demo: on/off, next/previous, shh! (5m)

Mute your sound, or press Ctrl to pause the speech.
Or, turn it off entirely!

Action	NVDA	Narrator	VoiceOver
Start screen reader	`Ctrl` + `Alt` + `N`	`Windows` + `Ctrl` + `Enter`	`Cmd` + `F5`
Stop speech	`Ctrl` (or `Mute`!)	`Ctrl` (or `Mute`!)	`Ctrl` (or `Mute`!)
Next item	`↓`	`↓`	`→` (Quick Nav)
Previous item	`↑`	`↑`	`←` (Quick Nav)
Turn off screen reader	`Caps Lock` + `Q`	`Windows` + `Ctrl` + `Enter`	`Cmd` + `F5`

Once-off set up (5m)

There are a few things we can do to make testing easier. You will thank yourself later!

With NVDA on

Update the NVDA key. Preferences > Settings, Keyboard, Select NVDA Modifier Key(s). Set Caps Lock as the NVDA key.
Turn on Highlighting. Preferences > Vision, check Enable Highlighting.
Turn on Speech Viewer. Tools > Speech Viewer: Open the Speech Viewer.

With Narrator on

Show the speech viewer (patchy!). Caps Lock + Alt + x (Live Transcription)

VoiceOver

Make sure the keyboard works as expected.
- System Settings > Keyboard item, toggle Keyboard navigation on
- Safari > Settings, Advanced tab > Accessibility item, check “Press Tab to highlight each item on a web page”
Turn on VO Quick Nav. VoiceOver Utility > Commands, Quick Nav (QN), check Arrow-key Quick Nav and check Single-key Quick Nav. (This makes VO behave more like other screen readers by letting us omit VO keys (Ctrl + Opt) or VO keys + Cmd in almost all cases)
Turn on the caption panel. VoiceOver Utility > Visuals: Show caption panel.

Practice: on/off, next/previous, shh! (5m)

Now you try!

Discussion: on/off, next/previous, shh! (10m)

We’ll do a quick go around the room. Pick one or two of these and give us a few sentences. If you’re watching this online, throw your answers in the chat!

How was that?
Where did you get stuck? (and how did you get unstuck?!)
What was unexpected?

Theory: we’re testers, not users (5m)

Don't worry about trying to have an "authentic" experience. That's not really possible!

If you don’t use a screen reader (SR) every day, your experience won’t be the same as someone who does.
How people use their screen reader can vary wildly from one person to the next. Like many human things!
You can choose not to use it, some everyday users can’t.
To find out about an “authentic” experience, we can do usability testing with everyday users!

What we’re trying to do is to find barriers that someone who uses a SR every day might encounter

That we can do, and we can compare what it looks like and what it sounds like.
It’s not “cheating” to use your mouse, to have the voice rate slow, or to avoid the screen curtain!

Practice: headings, images, links! (15m)

Action	NVDA	Narrator	VoiceOver (QN)
Next heading	`h`	`h`	`h`
Next heading at level 1-6	`1`-`6`	`1`-`6`	`1`-`6`
Next image (graphic)	`g`	`g`	`g`
Next link	`k`	`k`	`l`
Next landmark	`d`	`d`	Not available
Previous [thing]	`Shift` + `[thing key]`	`Shift` + `[thing key]`	`Shift` + `[thing key]`

Discussion: headings, images, links! (10m)

We’ll do a quick go around the room. Pick one or two of these and give us a few sentences. If you’re watching this online, throw your answers in the chat!

How was navigating around with the shortcuts?
How are the headings on the page? Good structure? Should be a heading / shouldn’t be a heading bits of text?
How were the text alternatives?
Any “Click here” or “Read more” or other links with confusing link text?

Theory: the two modes of SRs (5m)

Screen readers have two modes: Browse mode (which Narrator calls Scan Mode) and Forms mode. One way to think about the difference is the keyboard interactions for desktop screen readers.

In Browse mode, keystrokes perform reading and navigation actions by the screen reader.
In Forms mode, keystrokes perform data entry actions by the browser.

Screen readers generally change modes automatically. For example: when tabbing into a form field. You can also change modes manually.

Action	NVDA	Narrator	VoiceOver
Change mode	`Caps Lock` + `Space Bar`	`Caps Lock` + `Space Bar`	Not available

Practice: form and function (15m)

Test some interactive elements, especially help text and errors. Tab through the page, or jump to the next form element.

Remember our “What does good sound like?” from earlier:

Names and roles are announced
States, properties, and values are announced
Groupings and landmarks are announced

A new one for here: help text and error text is announced when a field gets focus.

Action	NVDA	Narrator	VoiceOver (QN)
Next interactive element	`Tab`	`Tab`	`Tab`
Next form element	`f`	`f`	`j`
Next text field	`e`	`e`	Not available
Next button	`b`	`b`	`b`
Previous [thing]	`Shift` + `[thing key]`	`Shift` + `[thing key]`	`Shift` + `[thing key]`

Aside: listing things (5m)

NVDA and VO both let you list stuff: all the links, buttons, headings, and so on. In usability testing we don’t tend to see people using these often. These lists can be helpful to us testers though!

Action	NVDA	Narrator	VoiceOver (Rotor)
List element	`Caps Lock` + `F7`	Not available	`VO keys` ( `Ctrl` + `Opt` ) + `u`
List all landmarks	Available in Elements list	`Caps Lock` + `F5`	Available in Rotor
List all headings	Available in Elements list	`Caps Lock` + `F6`	Available in Rotor
List all links	Available in Elements list	`Caps Lock` + `F7`	Available in Rotor

Discussion: form and function (10m)

We’ll do a quick go around the room. Pick one or two of these and give us a few sentences. If you’re watching this online, throw your answers in the chat!

What went well?
What went weird?
What did you learn?

And the big question: what will you do next?

Get help! (5m)

Desktop Screen Readers Survival Guide - Basic Keyboard Shortcuts at Deque (Shortcut Keys for JAWS, NVDA, Narrator, VoiceOver)
NVDA
Narrator
- Narrator Keyboard Shortcuts at Deque
VoiceOver
- VoiceOver Keyboard Shortcuts at Deque
- Using VoiceOver to Evaluate Web Accessibility

Screen reader testing workshop for WWAM was originally published by at Human-centred on July 12, 2026.

Severity and WCAG vs best practice

2026-07-08T00:00:00+00:00

Notes for a session at the Digital Accessibility Discussion Group.

Designed to help answer: “I’ve found an accessibility issue. How serious is it?”.

We can use severity levels and WCAG or best practice (BP) to decide this. One reason we want to be able to consistently assign the appropriate level of seriousness to an issue is to build trust with the teams doing the work. We want them to be able to believe us when we say something is High severity.
Every issue is important. But when everything is urgent, nothing is urgent. Getting the seriousness of an issue right helps the team fix the things that have the most impact first.

Severity

WCAG only has pass or fail; it does not have a severity rating. A fail of any WCAG success criteria means a page is not conformant. If we’re aiming for conformance, we have to fix every issue.

However, almost every tool or company that assesses using WCAG will also include a severity or priority rating. The severity of an issue is about the user impact, not just the technical compliance or failure. The problem that the user, the human being, encounters. Here’s one version.

Critical: the issue stops users from accessing content or completing a task. It does not have a workaround.
High: the issue causes serious problems or major inconvenience to users. It has a workaround but it is difficult and not obvious.
Medium: the issue causes problems or frustrations for users. It has a workaround.
Low: the issue causes inconvenience or irritation to users. It may not need a workaround.

Deciding on the severity level

Severity is inherently subjective and contextual. Some things to consider:

who is impacted (for example: everyone, keyboard users, screen reader user)
how they are impacted (the barriers, problems, inconveniences, frustrations, irritations)
where they can’t get to or what they can’t do
how far from the ideal or the standard that the implementation strays
what workarounds they can do.

Process for deciding Severity

Is the issue Critical? Does it stop a user from completing a task? Is this the only way a user could do a task? If there are multiple ways to complete the task, and only this one is inaccessible, the issue is High instead of Critical.
Is the issue High, Medium, or Low? How serious is the problem? How difficult is it to complete the task compared to how easy it is if we fix the problem?

Severity examples

These are just a guide: the actual severity depends on context and implementation. For example: it’s quite common to have a contrast-related issue at Low severity when the ratio is quite close to the WCAG required ratio.

Critical

The issue stops users from accessing content or completing a task. It does not have a workaround.

Functionality is not available from the keyboard. 2.1.1 Keyboard (A)
- People who use only a keyboard (or similar input like a switch or voice control) cannot use this functionality at all
Functionality breaks or content not available when zoom is increased. 1.4.10 Reflow (AA)
- People with low vision who have to zoom the page to use it will not be able to use the page or access the content
Conformance Requirement 5: Non-Interference. Failing any these SC means a page does not conform since it could mean a person can’t use the page:
- 1.4.2 Audio Control (A)
  - People using a screen reader won’t be able to use the page as the audio interferes with the speech output
  - People will find the auto-playing content distracting, making it hard to focus on the rest of the page
- 2.1.2 No Keyboard Trap (A)
  - People who use only a keyboard can only exit the trap by reloading the page and starting their task from scratch
- 2.2.2 Pause, Stop, Hide (A)
  - People using a screen reader won’t be able to use the page as the accompanying audio interferes with the speech output
  - People with a vestibular disorder may feel dizzy or nauseous
  - People will find the auto-playing video content distracting, making it hard to focus on the rest of the page
- 2.3.1 Three Flashes or Below Threshold (A)
  - People may feel dizzy or nauseous, or have a seizure triggered

High

The issue causes serious problems or major inconvenience to users. It has a workaround but it is difficult and not obvious.

1.1.1 Non-text Content (A)
- Screen reader users will miss out on the information that the image conveys to other users
1.3.1 Info and Relationships (A)
- Screen reader users will miss out on the information or relationships that are available to other users, such as grouping or listing
1.4.10 Reflow (AA)
- People with low vision who zoom in, and people on small screens, are forced to scroll in two directions, making the content hard or impossible to read
2.4.3 Focus Order (A)
- Screen reader users may miss information or find the ordering of interface confusing
- People who only use a keyboard may be frustrated by the extra effort required to complete the task
2.4.7 Focus Visible (AA)
- People who use the keyboard cannot tell what has focus. They may activate the wrong element or lose their place, and have to spend extra effort to complete the task.
2.5.3 Label in Name (A)
- Speech recognition software users might not be able to directly access the element
- Sighted screen reader users may be confused by mismatched speech and visuals
4.1.2 Name, Role, Value (A)
- Screen reader users won’t know the link’s destination, the button’s action, or what to enter in the form field
- Speech recognition software users won’t be able to directly activate the element

Medium

The issue causes problems or frustrations for users. It has a workaround.

1.3.1 Info and Relationships (A)
- The information or relationship that isn’t conveyed is minor or can be worked out from context, so people can still complete the task with some extra effort.
1.4.1 Use of Colour (A)
- When only colour is used, people with colour perception differences may not see the change in state or meaning
1.4.3 Contrast (Minimum) (AA) and 1.4.11 Non-text Contrast (AA)
- People with low vision, colour blindness, or older adults may find it difficult to read or distinguish text or UI elements from surrounding colours
2.4.2 Page Titled (A)
- If the title is missing, it’s harder to find the tab again
- If the title is not clear, it’s harder to understand the topic or purpose of the page
2.5.8 Target Size (Minimum) (AA)
- People, including those with limited dexterity or hand tremors, can miss the target or hit the wrong one
Best practice: no <h1> element
- Screen reader users can’t use the main heading to confirm the purpose of the page, or as a way to jump to the main content

WCAG or best practice?

When doing an accessibility audit/assessment/review we log WCAG failures and accessibility problems that WCAG does not cover. These are generally called best practice (BP).
- BP can mean different things in different contexts. Here we mean anything outside of our local baseline. For most places, the baseline is WCAG 2.2 AA. That means the following are BP:
  - Anything at Level AAA
  - Anything not covered by a WCAG SC
A WCAG issue needs to make clear the connection to the Success Criteria (SC).
Some things that are currently considered BP are being worked into WCAG 3.

WCAG and BP example: new tab

The following is a BP issue: links that opens in a new tab without warning. There’s no WCAG SC that addresses this, but it’s not good practice. We recommend adding text “opens in a new tab” or an icon with a text alternative.

But! The following is a WCAG issue: links that have an “opens in a new tab” icon without a text alternative. That fails 1.1.1 Non-text Content (A).

WCAG and BP examples: headings

The following are WCAG issues:

Text that looks like a heading but isn’t marked up as one. 1.3.1 Info and Relationships (A)
Text that is marked up as a heading but isn’t one. 1.3.1 Info and Relationships (A)
Heading order that does not match the structure (usually seen as headings going up instead of down). 1.3.1 Info and Relationships (A)
Heading text that isn’t descriptive. 2.4.6 Headings and Labels (AA).

But! The following are BP:

No headings are present (falls under 2.4.10 Section Headings (AAA))
There’s no <h1> element
There’s more than one <h1> element
Heading levels are skipped (E.g. <h1> to <h3>, then <h4>, missing the expected <h2>)

Prioritisation

The severity level and the WCAG/BP classification are two aspects of prioritisation. Other aspects might be:

how many users the issue affects (for example by role: user, admin, super-admin)
the user journey (for example: the main user flow, or an occasional or side flow)
importance to business goals
effort to fix
lots of other things!

Severity and WCAG vs best practice was originally published by at Human-centred on July 08, 2026.

Notes for a more social 'Screen reader testing workshop'

2026-06-20T00:00:00+00:00

These are some scribbles I’m pulling together to make an updated version of the Screen reader testing workshop I ran recently. That one was mostly solo work: some pointers on how and what to test, then heads down and headphones on to do the testing. The next version is going to be more social, more group work.

Aside: I like taking notes. Two pages I’ve gone back to a lot are my Teaching and learning notes and my Writing, Workshops, and Talks notes.

Gathered notes

These are options and ideas, and have some overlap.

Need instructions slides this time, since people will be off in corners of the room.
All together group shout-outs: what are you hoping to get out of this session?
- While they’re testing, see if some of the stuff not covered can be added near the end, or at leat talked about briefly
Opening act, show of hands
- who’s heard a screen reader before?
  - nice! would anyone like to say how / where?
- who’s used a screen reader before?
- who hasn’t used a screen reader before?
- who doesn’t want to put their hand up? (trick question! maybe…)
Pair share: Have you ever tested with a screen reader before? Tell me more! (Which one? How was it?)
After first activity, a 1 minute review in your group
- How was that? Anything unexpected or interesting?
Make preso bit interactive: ask the crowd before giving the answer
Make name, role, value preso bit interactive
- A few examples of button, link, form field, maybe some ARIA stuff too
- Show just the UI, ask audience for name, role, value, (state?)
- And a tricky one: fieldset and legend, breadcrumbs (need HTML for that)
Update headings activity
- How are the headings on the page? Do they represent the content well?
- What’s not a heading, but should be? (Often big, bold, text)
- What’s a heading, but shouldn’t be? (Often in the hero section)
After headings and images activity
- Each group share back to everyone: one or two sentence review
  - What you did or what you learned or where you got stuck (and how you got unstuck)
Closing, part one: back as one group
- What went well?
- What went weird?
- What did you learn?
Closing, part two: now what?
- Write a sentence starting with “I will…”. Get as many of these in as you can. The more you get, the more likely you are to Do The Thing!
- What will you do?
- When will you do it?
- Where will you do it?
- Who will be involved?
- How will you do it?
- Why do this?

Raw notes

Better > Worse
- Movement > Sitting
- Talking > Listening
- Images > Words
- Writing > Reading
- Shorter > Longer
- Different > Same
Connections
- to each other
- to the topic
- to learning goals and outcomes
Concepts
- Include 1 minute reviews
Celebrations
Learning is strong when it matters, is concrete, is personal.
Knowledge
- Retrieving
- Predicting
- Interleaving
Understanding
- Connecting
- Practising
- Self-explaining
Social
- Use pair share / teach back activities, have accountability buddies.
Physical
- Use activities like show of hands.
Practical
- Show how to get started with small wins that stack up and lead to big ones.
- Do the work. Tell learners to bring their stuff.
- Provide a toolkit with clear, actionable, steps.
Short
- Keep it simple and prioritise. What’s the key message or concept?
- Make small but meaningful milestones. Find the short-term reward linked to the long-term benefit.
- Do warm-ups, easier or softer, stuff before the difficult stuff.
High energy
- Have a strong opening.
- Have a strong peak.
- Have a strong closing.
Flexible
- Vary type and length of activities, senses used.

Notes for a more social 'Screen reader testing workshop' was originally published by at Human-centred on June 20, 2026.

The (more) complete view

2026-06-16T00:00:00+00:00

Something I aim for is a complete view. Seeing things from multiple sides and angles.

Sometimes that means steel-manning someone else’s argument. Sometimes that means presenting a side that’s been neglected: I find this one to frequently be the case with AI, in particular hype-based reporting. One of the reasons that I went to an AI conference and took a bunch of notes was to get a more complete view of how jobbing engineers are using AI. What’s working and what’s not. To get a more complete view of AI in engineering.

Realistically, it’s impossible to have a (completely) complete view: to consider every single angle. But we can work towards a more complete view. One that takes in more perspectives. The main thing is to ask a lot of questions! I find it helpful to have a few “grips” to get a handle on the process: width, height, depth. Kind of like left-right, up-down, in-out.

Width

Look more widely. Look left and right.
What’s happening in parallel situations? Different teams, different organisations.
What’s being left out? What else is happening?

Height

Look higher and lower. Look up and down.
What’s happening in the layers above? The layers below?

Depth

Look more deeply. Zoom in, and zoom out.
Zoom in on the details, the specifics, the measurables and metrics, the numbers. Zoom out and look at the context, the bigger picture.

The (more) complete view was originally published by at Human-centred on June 16, 2026.

Sketchnotes from Web Directions – AI Engineer Melbourne

2026-06-07T00:00:00+00:00

Last week I was in Melbourne for Web Directions - AI Engineer. I was interested in hearing from people using AI day-to-day, and the ups and down of it. As I usually do, I took a bunch of notes.

My takeaways

I went to about half the talks, splitting my time between the Software Engineering and AI Engineering tracks. A few themes came up across the talks I was at.

Practical

Choose the right model for the task
- Use a frontier model when things are subjective, ambiguous, and we have sparse feedback. This can be slow and expensive.
- Use a lower-end model when things are objective, clear, and we can loop with good feedback. This can be fast and cheap: error improvement compounds.
- Most of the time, start with a model in the middle
- Right context beats more model
Use a versioned learning loop
- Documents that AI uses have to be keep very up-to-date to stay and relevant and helpful
  - The spec, the AGENTS.md, skills, Confluence pages
  - The spec becomes the source of truth
- Version control these changes like we version control our code

Theoretical

Treat LLMs with caution
- There will always be some confabulation, even with excellent prompt engineering
- The LLMS should not act as a boundary (for privacy, security, etc). Our application (architecture) should be.
  - Stories, prompt injection, can change the success condition: failure is always nearby
- AI use must earn the right to scale. Start small and have a progressive rollout.
There are many pieces, and they’re all connected
- The model, the prompt, the harness, etc.
- AI helps with coding, but that’s only a small part of an engineer’s job
No magic wands
- Bottlenecks/constraints don’t disappear, they just move
- Removing waste is (still) the biggest accelerator: more than AI

Sketchnotes

Day one - sketchnotes page 1

State of the AI Landscape - George Cameron

Cheaper intelligence but/and Higher spend than ever

Token Town: why token strategy is product strategy - Sarah Sachs

Build the best product that uses any model instead of training the best model
Optionality is leverage
Open weight models are now strong enough for moderate tasks
- What moderate means is contextual

Everything is a Factory - Geoff Huntley

Everyone is now a software developer → The job has been commoditised
It needs Deliberate intentional practice, like an instrument
Curiosity-test people
Removing waste is the biggest accelerator (more than AI)

Three lanes below one millisecond - Vamsi Ramakrishnan

Full-duplex voice punishes the mistakes that text-only forgives.

Day one - sketchnotes page 2

Fail fast, fix faster: why faster models can beat smarter ones

Good enough, but fast
- Especially for Ralph loops, with good feedback
  - Cheap error detection
Implement → Validate → Inform, loop
A bit like Test-Driven Development
Error improvement compounds
Use a frontier model when: subjective, ambiguous, sparse feedback

Why AI coding tools might not make the slightest difference - Jason Cornwall

They say about 10% increase in productivity 2024-2026
Every system has exactly one constraint
- but/and it moves!
- when you remove one
Coding is about 15% of an engineer’s time
- The others are failure-avoidance activities
AI as an ingredient, not the recipe

Constitutional prompting - Prem Pillai

Your agents is already making decisions - just not ones guided by you
You can debug a spec. You can’t debug vibes.

From zero to production - Rachael Zhang

Do progressive rollout: earn the right to scale

Day one - sketchnotes page 3

Agent observability - Daniel Nadasi

Look at every level, once per framework
Tighter controls means easier observability

Our AI hallucinated in Production: how we fixed it with evals - Yicheng Guo

Hallucination (of property features) rate: 5%
- even after much prompt engineering
Learning system
- Software metrics
- Human judge - lots of labels
- LLM judge - trained from human’s labels

The application layer is the new research lab

The prompt is just one piece of many
- Behaviour is joint
We only own a function of the pieces, not the pieces themselves

Orbital lasers vs For loops: economically matching models to tasks - Stephen Sennett

We don’t choose, we default
The range
- $ Words matter (about 10% of the time)
- $$$ Structured, but logical (about 70% of the time)
  - Failure? Retry with $ model
- $ Make simple things fast (about 20% of the time)
Best fit, best tool
- Not overuse or hallucinate
Right context beats more model
- Documentation, MCPs

Your AI can’t engineer (yet) - Theo Galanos

One number can’t tell the whole story
Model: the reasoning; harness: everything else!

Day two - sketchnotes page 1

Growing on purpose: the work that makes you - Jeremy Howard

Self-determination theory
Two paths: support or Decay
Autonomy, Mastery, Purpose, Relatedness
Effortful craft

Craft in the time of agents - Annie Vella

Apprentice → Journeyman → Master
A spectrum between results-oriented and journey-oriented
Creation to verification (“supervisory engineering”) shift
Effects
- Flow state ↓↓↓
- Cognitive load ↑↑
- Feedback loop ↑
Self-efficacy as a dominant predictor
Three models
- Artisan. Rare.
- Orchestrator
  - Domain (problem) and harness (platform)
- Clerk. Avoid!

Buidling a mesh LLM from spare compute - Mic Neale

Inference is now the bottleneck.

Towards long-horizon tasks - Zixuan Li

Handles interruption and replannings of context
Human help
- Checklist for addressing drift
- Tell it to verify for addressing error accumulation
- Tell it to evaluate for when it can’t pivot

Day two - sketchnotes page 2

Spec-driven AI development - Nick Beaugeard

We’ve been backing up the wrong files
The spec is the source of truth. The code is a build artefact.
- Anything you can regenerate is an artefact.
The process
- Spec: intent and guarantees
  - Edited by a human
- Plan: architecture and approach
  - Approved by a human
- Tasks: atomic, ordered, checkable
- Build: code, tests, docs

Building SDKs in the agentic era - Mark McDonald

AGENTS.md is the most effective way to instruct an agents, but/and uses many tokens
LLMS.txt has high latency, uses lots of tokens
Agent skills - keep them lean

AGENTS.md is the wrong conversation - Jakub Riedl

AGENTS.md as an index/router - good, but …
- it gets outdated quickly
- it’s one person’s opinion
Use a versioned learning loop
- in AGENTS.md say what to do with ADRs, etc.
Have an inner/local loop and an outer/organisation-wide loop
- Share to the outer loop on merge

How do we engineer in a world where we no longer read code - Ben Taylor

Bottlenecks don’t disappear, they move
Engineering ≠ Coding
- The doing is the understanding
Vigilance decrement: monitoring misses what active catches

The death of documentation

The pattern
- Day 0 it’s documented
- Sprint 2 it drifts
- Month 6 it’s become folklore
  - A rumour about how the system used to work
LLMs can’t know the why, the intent
Deterministic specs
- the code
- openAPI yml

Day two - sketchnotes page 3

Designing inference-native systems - Sajjad Kamal

Update belief → Decide → Act
Intent (decisions, stories), Context, Action, Reconciliation, Verification

Why LLMs fall for stories - Mal Curtis

Can get outside the guardrails
Chat is still a prompt
Reasoning is more text
Stories can flip the success condition
- The opposite is nearby
  - Failure is nearby
Stages of guardrails
1. Input rails
2. Dailog rails
  - No changing jobs
3. Retrieval rails
  - Evidence, not instructions
4. Execution rails
  - Tools behind policy, not prose
5. Outout rails
  - Verify the answer

Hacking the model: AI Red Teaming in practice - Pas Apicella

Goal + Strategy
Fractured, ever-evolving, attack surface
Continuous Offensive Security

Why most AI De-identification fails in production - Moin Zaman

The LLM should not be your privacy boundary
- Your application architecture should be
Manual review wasn’t a fallback. It was part of the architecture.
Don’t hide uncertainty from users

Sketchnotes from Web Directions – AI Engineer Melbourne was originally published by at Human-centred on June 07, 2026.

Screen reader testing workshop

2026-05-25T00:00:00+00:00

We’ll focus on the free screen readers.
- Testing with JAWS is fairly similar to testing with NVDA.
- Narrator comes with Windows and VoiceOver comes with macOS
- NVDA is a free download, Windows only
We’re just covering getting started
- Most of the problems occur with foundational stuff, the building blocks of the web.
- There’s loads more to explore and learn if you’re interested!
We’ll be testing on Research insight: accessibility of images

If you just want the keyboard shortcuts, go to “Get help!” at the bottom of the page.

Agenda

1. Dive right in (practical 🫱)
2. Think about it (theory 🧠)
3. Set it up (practical 🫱)
- NVDA only: NVDA key and Turn on highlighting
- Speech viewer
4. Set if off (practical 🫱)
5. Share it out (theory 🧠)
6. Something went wrong (practical 🫱)
7. Get help!

Depending on how we go with time, we may jump to “Get help!”, which is a list of resources.

1. Dive right in (practical 🫱)

Be prepared to make it hush!

Mute your sound, or press Ctrl to pause the speech.
Or, turn it off entirely!

Action	NVDA	Narrator	VoiceOver
Turn off screen reader	`NVDA key` (`Insert` or `Caps Lock`) + `Q`	`Windows` + `Ctrl` + `Enter`	`Cmd` + `F5`

We’ll come back to NVDA key later!

Search for it, click the logo, or use a keyboard shortcut.

Action	NVDA	Narrator	VoiceOver
Start screen reader	`Ctrl` + `Alt` + `N`	`Windows` + `Ctrl` + `Enter`	`Cmd` + `F5`

Although you can use any browser, we generally suggest using these combinations for best results:

NVDA with Firefox
Narrator with Edge
VoiceOver with Safari.

Move around the page

Action	NVDA	Narrator	VoiceOver
Next item	`↓`	`↓`	`↓`
Previous item	`↑`	`↑`	`↑`
Next interactive item	`Tab`	`Tab`	`Tab`
Previous interactive item	`Shift` + `Tab`	`Shift` + `Tab`	`Shift` + `Tab`

If you get stuck, try:

going backwards
pressing Tab a few times
refreshing the page!

Briefly discuss

How was that? 🙃

2. Think about it (theory 🧠)

Testers, not users

Don’t worry about trying to have an “authentic” experience. That’s not really possible!
- If you don’t use a SR (screen reader) every day, your experience won’t be the same as someone who does.
- Your familiarity with the SR and the way of browsing is very different.
- You can choose not to use it, some everyday users can’t.
- To find out about an authentic experience, we can do usability testing with everyday users!
What we’re trying to do is to find barriers that someone who uses a SR every day might encounter.
- That we can do, and we can compare what it looks like and what it sounds like.

The two modes of screen readers

Screen readers have two modes: Browse mode (which Narrator calls Scan Mode) and Forms mode. One way to think about the difference is the keyboard interactions for desktop screen readers.

In Browse mode, keystrokes perform reading and navigation actions by the screen reader.
In Forms mode, keystrokes perform data entry actions by the browser.

Screen readers generally change modes automatically. For example: when tabbing into a form field. You can also change modes manually.

Action	NVDA	Narrator	VoiceOver
Change mode	`NVDA key` + `Space Bar`	`Caps Lock` + `Space Bar` + `Enter`	Not available

What does good sound like?

Broadly speaking: it should sound the same as it looks.

Names and roles are announced
- For example: “button, save”; “contact us, link”.
States, properties, and values are announced
- For example: an expanded state on an accordions, the text in a text field
Groupings and landmarks are announced
- For example: a group of radio buttons; the main navigation.

Variations between SRs

Some screen readers announce ‘button, save’ and some announce ‘save, button’.

Different screen reader and browser combinations may announce the same thing slightly differently. That’s fine, and expected!

Briefly check that no information is missing across these variations. The order doesn’t matter, only the content of the announcement.

3. Set it up (practical 🫱)

Okay, let’s make our testing slightly easier by updating a shortcut key and turning on highlighting.

NVDA only: `NVDA key` and Turn on highlighting

Set a new NVDA key. Some people prefer Caps Lock as the NVDA key. In the menus, go to Tools > Speech Viewer (by using your mouse or NVDA key` + N).
Turn on Highlighting. In the menus, go to Preferences > Vision, and check Enable Highlighting. This lets you see where NVDA’s cursor is.

Speech viewer

NVDA and VoiceOver both let you view a text version of the speech. It doesn’t always match what’s announced, though, so be wary of relying on it.

Action	NVDA	Narrator	VoiceOver
Turn on the speech viewer	`Tools` > `Speech Viewer`: `Open the Speech Viewer`	Not available	`VoiceOver Utility` > `Visuals`: `Show caption panel`

4. Set if off (practical 🫱)

Quick aside for VoiceOver:

Interact with (go into/out of) objects (like iframes, menus, application regions, etc.) : VO + Shift + ↓ / ↑

Test the headings

Action	NVDA	Narrator	VoiceOver
Next heading	`h`	`h`	`VO` + `Cmd` + `h`
Previous heading	`Shift` + `h`	`Shift` + `h`	`VO` + `Cmd` + `Shift` + `h`
Next heading at level 1-6	`1`-`6`	`1`-`6`	Not available

Trying moving down the page after jumping to a heading!

Action	NVDA	Narrator	VoiceOver
Start reading from here	`NVDA key` + `↓`	`Caps Lock` + `↓`	`VO` + `a`

Test the images

Action	NVDA	Narrator	VoiceOver
Next image (graphic)	`g`	Not available	`VO` + `Cmd` + `g`
Previous image (graphic)	`Shift` + `g`	Not available	`VO` + `Cmd` + `Shift` + `g`

Test the title

Action	NVDA	Narrator	VoiceOver
Announce title	`NVDA key` + `t`	`Caps Lock` + `w`	Not available

What went well?
What went weird?
What did you learn?

6. Something went wrong (practical 🫱)

Test some interactive elements, especially help text and errors. Tab through the page, or jump to the next form element.

Action	NVDA	Narrator	VoiceOver
Next form element	`f`	`f`	`VO` + `Cmd` + `j`

If you get stuck, try:

going backwards
pressing Tab a few times
switching modes
refreshing the page!

7. Get help!

Desktop Screen Readers Survival Guide - Basic Keyboard Shortcuts at Deque (Shortcut Keys for JAWS, NVDA, Narrator, VoiceOver)
NVDA
Narrator
- Narrator Keyboard Shortcuts at Deque
VoiceOver
- VoiceOver Keyboard Shortcuts at Deque
- Using VoiceOver to Evaluate Web Accessibility

Screen reader testing workshop was originally published by at Human-centred on May 25, 2026.

Sketchnotes from the 2026 NZ Tech Rally conference

2026-05-20T00:00:00+00:00

Last week was the NZ Tech Rally conference. It was so good!

Everything about the event was high quality. Also, I gave a talk about design systems and accessibility.

A few top takeaways for me:

Don’t mistake speed for alignment
Design for disagreement in meetings and workshops
Don’t mistake intelligent discussion for moving forward (or making a decision)
Clarity is important (but that doesn’t always mean certainty)
Culture is the accepted, repeated, behaviour

Below are my sketchnotes from some of the talks I attended.

Morning keynotes

Cognitive diversity in the age of AI: building teams that out-innovate with a Pasifika lens - Norie Ape

How do we make the data that AI uses truly diverse?
Innovation is about making space for different ways
Cultural intellligence
- Thinking together
  - styles
  - culture
  - perspective
AI risk: accelerating bias
Don’t mistake speed for alignment
Talanoa
- respect, care, integrity
- understanding, not winning
Design for disagreement in workshops and meetings

Building with AI without losing our values - Lauren Peate

Systems around us make us complicit in bad things
(Only) use AI when it’s a good solution
- e.g. measuring feedback quality - tone, specificity
Diversity improves AI accuracy
- LLMs need evals → evals need humans → quality needs diverse humans
Use holistic metrics
LLMs are non-deterministic, use more deterministic tools to check the output
Sometimes money and values will be in conflict
Build to easily swap LLMs

Community, Culture & Wellbeing track talks

The Dungeon Master’s guide to feedback - Tamara Buckland

Even with best intentions, feedback comes out judgey
- So we tend to avoid it!
  1. Centre the hero
  2. Narration, not judgement
- narration opens and adds context
- judgement closes
  1. Point forward

Your code is fine. Your leadership… - Rachael Fitzjohn

Leader’s responsibility
- Clear confusion
  - Reduce uncertainty
- Make hard decisions
  - Without enough information
Intelligent discussion ≠ Moving Forward (or making a decision)
Clarity is underrated
- Clarity is not necessarily certainty
We avoid discomfort, difficult decisions
Ambiguity creates anxiety
Indirectness, avoidance, destroys trust
Culture is accepted, repeated, behaviour

Locknote

The accessibility features of today are the breakthroughs of tomorrow - Maia Miller

When we ask “is is worth it?” late, it makes it easier to say no
- time, money, customers
  - it’s okay to ask
Much tech that was made to meet the needs of disabled people become the preferred version
An inaccessible solution is an incomplete solution
An accessible solution is a better solution
More flexible and adaptable, to our lives

Sketchnotes from the 2026 NZ Tech Rally conference was originally published by at Human-centred on May 20, 2026.

Sketchnotes from the May 2026 NZ Tech Rally meetup

2026-05-19T00:00:00+00:00

Last week NZ Tech Rally had a great pre-conference panel meetup.

My top takeaways:

The rise of AI has lead to a rise in old-fashioned automation
Ask “How did you arrive at that decision?”
The hype is ridiculous, but there are realistic, good, use cases

Below are my sketchnotes.

AI adoption in high trust environments

AI in a measured and safe way
Cautious with AI and decisions, outcomes
Code (GitHub Vopilot) summarisation, internal / back-office productivity
All AI ideas go through a Working Group
- The group contains people from privacy, infosec, legal, and more
The (Public Service) Framework is more of an enabler than a constraint
The rise of AI has lead to a rise in old-fashioned automation
- Don’t always need AI!
“Do you need this to be deterministic”
Train staff to be critical of AI outputs
“How did you arrive at that decision?”
“What is good enough?”
- Hard to answer!
Testing is hard!
Needs SMEs, more business engagement, when using AI
Can’t predict the future, but can stick to our principles

Q&A

Can customers opt out?
- Guidance from Privacy and Ethics
Managing the risk of the rising AI costs
- Having a Business Continuity Plan
- Looking at Small Langauge Models
The hype is ridiculous, but there are realistic, good, use cases

Sketchnotes from the May 2026 NZ Tech Rally meetup was originally published by at Human-centred on May 19, 2026.

Sketchnotes from the May 2026 Wellington Web Accessibility Meetup

2026-05-11T00:00:00+00:00

I went to the May 2026 Wellington Web Accessibility Meetup and listened to two great talks, and a lively Q & A. Below are my sketchnotes from the talks.

Text version of sketchnotes from the May 2026 Wellington Web Accessibility Meetup

Influencing Accessibility Change – Mark Lynskey

Accessibility is everyone’s responsibility
Circles of influence: you, your team, your organisation, more!
Treat accessibility issues as bugs: POs hate bugs!
Make Guidelines and Tools that scale

Accessibility Success Stories – Michele de Bes

Move Design Review to before Acceptance
Expand Acceptance Criteria to include Accessibility items
Ensure Strategic Alignment
Continuous Improvement
Design for everyone
Ask: can everyone use this?

Sketchnotes from the May 2026 Wellington Web Accessibility Meetup was originally published by at Human-centred on May 11, 2026.

Draft notes for an AI usage policy

2026-04-16T00:00:00+00:00

Having a policy for AI usage in the workplace is important. Below are some gathered notes, a sketch of a first draft of a policy.

Decide when to use it
Use it thoughtfully
Review the output
Be a considerate coworker
An incomplete reading list

Decide when to use it

Start with the problem rather than AI as the solution.
Decide where on the spectrum of “never use AI for this task” to “always use AI for this task” this task falls.
- Consider whether the task requires thinking, evaluation, experience.
Be able to articulate why we’re using it for this task.
Use it to learn and explore rather than to provide answers.

Use it thoughtfully

Do a quick pros/cons analysis of using it for this task.
- Is the trade-off acceptable, and why?
Be clear on what’s being automated, the inputs, and the outputs.
Have a hypothesis, an expected outcome, success criteria.

Review the output

Recognise the potential for bias and errors.
- Errors and confabulation are particularly likely around details and specifics, and for niche topics.
- Check for relevance, accuracy and consistency, errors and omissions.
- Be particularly wary of plausible nonsense.
Use a verification checklist.
Measure the outcome to see whether using AI made a material improvement to the task.

Be a considerate coworker

Share respectfully and thoughtfully.
- Only share things we’ve reviewed thoroughly.
- Share a distilled summary or a link, not raw LLM output.
- Watch for effort asymmetry, and share it only when requested.
Realise that the responsibility, accountability, and reputation risk remains with us, not the AI.
Share how we used it for task.
- The facts, not opinions and predictions.
- Include our context and our intended outcome.
Treat questions and concerns with respect, kindness, and dignity.
- A friendly, non-judgemental, approach.

An incomplete reading list

Draft notes for an AI usage policy was originally published by at Human-centred on April 16, 2026.

My (Sketch)notes from Code Camp Wellington 2026

2026-03-21T00:00:00+00:00

On Saturday 21st March 2026 I was at Code Camp Wellington. The speakers were great and the crowd was friendly!

A few plucked highlights from talks for me:

The importance of thinking well
- self-awareness, reflection, deliberate action, precision, quality
Being wary of the impact on ourselves when using AI
Agents work better when you get your accessibility right

Sketchnotes

Below are my sketchnotes from the talks I went to. Each image: links to a larger image; is followed by a text version.

Text version of page 1 of sketchnotes from Code Camp Wellington 2026

Think small: How to maintain a startup mindset even after 20+ years – Chris Smith

Lesson 1: small is good
Lesson 2: Embrace your inner Anarchist
Lesson 3: Surround yourself with geniuses
Lesson 4: Keep your culture alive
Lesson 5: It’s about people

Data wrangling with AI – Daniel Shannon

Have secure custom deployed models, an air gap
Use continuous QA agents
Map together disparate data sets
The most important thing: high quality data set

Running Runn on a run: Hands free vibe coding – Ingo Schommer

“From writing code to having conversations about code”
Agents work better when you get your accessibility right
Two stage loop, two LLMs
- Sandbox around Claude Code
- Many hilarious edge cases

New Normal: AI Speed, Human Overload – Lexi Weng

Ship more, close more tickets, but increased mental load, more context-switching, less satisfaction
Waiting for a prompt response, or an agent, is not a rest
It moves effort, we do more in parallel
The productivity baseline has gone up
Becoming orchestrator more than creator

Text version of page 2 of sketchnotes from Code Camp Wellington 2026

How I took a career break – Prae Songprasit

If you have an Employee Assistance Programme, use it!
Things that lower morale, path to burnout
- Mismatched skills and team needs
- Devaued specialist skis
- Values mismatch
What do you
- care about?
- get satisfaction from?
Rest is not wasting time
Become clear on your burnout conditions, your red flags
- For example: tired, teary, terse
Know thyself and monitor

Pragmatic GenAI for Software Developers: Staying Human in the Loop – Roberto Allende

Be Deliberate rather than be reactive
- Act with agency
An LLM is a probability machine that gives us plausible answer
- When we give it vague inputs it has a large probability space
Automation has to be deterministic: the same inputs give the same outputs, every time
It feels magical until it collapses
LLMs can give genuine leverage when generating options
Review AI output like an untrustworthy Pull Request

The Habits of Fast Developers – Sam Jarman

Increase the density of your experience
Good habits and bad habits both stack
Understand the big picture
Have the option to reverse things
Bookmark everything
Experience = Sensations + Reflection

I also did a talk of my own. A little lightning talk: The fiction of non-friction being favourable.

My (Sketch)notes from Code Camp Wellington 2026 was originally published by at Human-centred on March 21, 2026.

The fiction of non-friction being favourable

2026-03-16T00:00:00+00:00

The HTML version of my talk at Code Camp Wellington 2026.

Or: “Easy is not always an uncomplicated good”

The front-page

Choose friction to choose growth

Foreword

📧 steve.barnett@intopia.digital
🤓 Digital Accessibility Consultant
🛠️ Finding and removing friction

1. Friction

Quick definition(s)

Friction is resistance

The force of resistance to relative motion
That is: stop-it-slipping-ness

Friction is difficulty

It stops things being easy
That is: have-to-do-something-ness

2. Favourable non-friction

Or: “Easy can be good”

Code completion

For example: IntelliSense in VS Code
No hunting around, it’s right there
There’s no value in this being difficult

3. Unfavourable non-friction

Or: “Easy can be bad”

Taking shortcuts that lead to tech debt

For example: 0% test coverage
“That’s a problem for future-me”
Tech debt more generally

4. Favourable friction

Or: “Difficult can be good”

Adding a new framework (or library)

For example: React
Switching from Vue or Angular or …
Get the finer flavours of it

5. Choosing friction

Making mistakes Getting feedback

Friction is fervour

😋 Difficult is interesting
😪 Easy is boring
🧩 Solving problems with code

Feasibly factious example

(Or: “Probably provocative example”)

Choose friction when using AI
Don’t let AI do the work
Do let AI help do the work

The finale

Choose friction to choose growth

Thank you! 🙇

steve.barnett@intopia.digital

P.s. check out this book! 👇

The fiction of non-friction being favourable was originally published by at Human-centred on March 16, 2026.

Notes on some Canadian Accessible and Equitable AI stuff

2026-01-23T00:00:00+00:00

I had a quick read through of the Canadian Government’s CAN-ASC-6.2:2025 – Accessible and Equitable Artificial Intelligence Systems. Here are some quick notes on it.

Much of the document is about the how, the implementation: using AI in an equitable way for people with disability. I was pleasantly surprised, though, at the bits that did not treat AI and its use as a foregone conclusion, as an uncomplicated good.

One theme that ran through for me was: allow opt-out of AI, without penalty. With two sub-themes:

Have a clear plan for human options that are equally available and usable;
Stop using AI if it causes harm or is no longer fit for purpose.

Another theme for me was: monitor for harm and unfair treatment, on an ongoing basis. With a few sub-themes:

Understand risks and impacts, including things that build up over time;
Allow anonymous feedback;
Respond to feedback with a specific plan for fixing it;
Allow challenging of decisions.

As someone who tends to be critical of any new tech, and likes to be clear on the pros and (especially) the cons, I thought this was great.

Notes on some Canadian Accessible and Equitable AI stuff was originally published by at Human-centred on January 23, 2026.

A business case for regular retrospectives

2026-01-21T00:00:00+00:00

A good way to increase long-term efficiency is by running a 30 minute retro at the end of every project.

Why do retros

Retros are the best, structured, way to continuously improve by building on successes and learning from mistakes. They should be treated as an essential part of a project, similar to the investment in project management time.

The way we improve is to:

keep doing what’s working well;
stop or change what’s not working well (by doing something about it).

Retros work by driving change in people and processes, and by building better shared understanding within the team. They help improve trust and psychological safety, and demonstrate the value of feedback. Every retro ends with deciding on a small, cheap, experiment: we agree to try something to see if there’s an improvement or not.

This results in higher quality, more efficient, work and better team communication and collaboration. Running retros regularly is best because it means more opportunities to improve.

Often there are items in company values or business objectives that match up well with doing retros, such as improvement and efficiency.

Ways to support running regular retros

Adding a retro as a item in templates
Scheduling the retro when scheduling the work
Templating the process and the outcomes, with some room to improvise
Being flexible on the timing

2025 Year in Review

2025-12-17T00:00:00+00:00

For the past few years I’ve been doing a quick worky year-in-review. Here’s the one for this year.

This year more than others I feel very run dry and out of energy at the end. A big part of this is not taking a proper holiday. I’m working on it!

Speaking

I gave two talks this year, both on Getting “Accessibility Ready” for a Design System. The first was in September at Inclusive Design 24 (here’s the video on YouTube). The second was (an updated and revised version of the talk, including a “6 months later” epilogue) at the Digital Accessibility Community of Practice (here’s an HTML version of talk).

Next year I’ll be doing a shorter, sharper, shinier version of the talk at NZ Tech Rally. I also put in a few talks to other conferences that didn’t get picked up. I like thinking of and writing up talks and I’ll continue to do so next year.

Conferences and meetup

I officially become co-facilitator for the Digital Accessibility Discussion Group here in Wellington, Aotearoa New Zealand, with my friend and ex-colleague Tamsin. We started a Wiki on GitHub to keep track of links and things. I gave a few little talks there too, including Accessibility Ready, burnout, Validating validation, and behaviour change. This group has been a really valuable source of peer support: we often discuss the difficulties of doing the work, and ways to deal with it.

I went to the Disability Inclusive Pathways Conference in July and wrote up my notes from some of the great talks. A few things that stuck out for me: noticing the cumulative load of many individual stressors; the Ripple Effect of disclosing disability.

I also went to the talk track at Wellycon, a board games expo, to hear about design in other realms. I wrote up my notes from those board game design talks too. In particular, it was good to be reminded of the importance of: a good first-time and early user experience; handling failure states well.

Writing

I wrote just over 20 things this year.

My biggest focus was design systems: Design systems, Accessibility, and Testing (Accessibility), Early Adopters and Design Systems, Accessibility Ready, Resolving variations between screen readers, Supported Assistive Technology, (Accessibility) Testing on real devices, Automated Accessibility Testing, Screen reader testing for a Design System.
I also wrote about some of the things that came up while working with a design system team: What key does what?, Comboboxes and keeping it simple, The two modes of Screen Readers, and Usability testing for a design system.
I had lots of interesting questions as part of my consulting during the year. One of my favourites was about marking photos as decorative images. I wrote up some thought about it as Does this image need alt text?. I also wrote up some stuff about Carousels.

I wrote a post for HTMHell: Giving pages a clear shape by using headings. I’m a big fan of the site and series, and it’s a real pleasure to be published there.

I started a work-in-progress AI Resistance page. I have a tendency to want to see the more complete picture, and often end up putting myself on “the other side”. In this case, the prevailing thinking about AI seems to be that it’s an uncomplicated, inevitable, good. That doesn’t seem quite right to me, so I’m digging into the opposite to see what’s there.

Values and Types

On the home page of this site are two little lines and my values and the types of work I enjoy.

When working with people, especially on accessibility things, I try my best to: be empathetic; make it simple; be positive.

I’ve been doing okay with these qualities over the year. I think the one that’s been most difficult to keep up is the simple. Perhaps that’s been a bit of a consequence of spending so much time deep in design-system-land.

The things I most enjoy doing at work are: supporting, teaching / training, writing, presenting, and coding. There’s some overlap between these.

This is easiest to think about in the context of the day job.

18 months job check-in

I started at Intopia in April 2024. Overall, I’m still enjoying consulting life. In particular, the variety of work and clients keeps me interested. I like mixing up things, trying different angles.

The majority of my work has been auditing, which tracks. But/and I have spent a large chunk of months doing more support-like, more consulting-like work, which I enjoy a lot more. Being able to talk through problems, help people find new angles, reconsider choices, that’s the stuff that I enjoy the most.
I haven’t done any training, and that seems likely to remain the case.
I have been doing some writing and especially presenting. There’s some support for that, which is great. I feel like I’ve actually done a fair bit of this over the year, but not much of it public.

That’s a wrap

I’m not sure yet what my focus for next year will be. I hope I’ll continue to do more presenting and talking. But I’m mostly zooming out and looking at the wider context of life and seeing where things are going there, with work being a part of that.

2025 Year in Review was originally published by at Human-centred on December 17, 2025.

Does this image need alt text?

2025-11-11T00:00:00+00:00

Short version: probably yes.

Recently I was working with a team on a page that’s a listing of people who are professional service providers. Each provider has a head shot photo. So, naturally, we were discussing if those photos needed to have text alternatives.

In general

WCAG Success Criteria 1.1.1 Non-text Content (Level A) says that all non-text content must have a text alternative that serves the equivalent purpose.
It also says that decorative images must be hidden from assistive technology.
Photos are very rarely decoration. Their purpose is to convey visual information, so they must have a text alternative.
Writing good text alternatives can be tricky! That doesn’t mean we shouldn’t try and do it. If an image conveys information we must supply a text alternative.
Usability testing suggests that screen reader users prefer photos to have a text alternative. They want an equivalent experience.

In this specific case

Marking these images as decorative would imply that they don’t have a purpose. If that were true, we would remove the images.
Writing a generic text alternative (for example: “Headshot of [service provider’s name]”) does not convey the same information as the photo.
We want to consider including things like ethnicity and gender because these may be important to the customer, in particular customers who belong to marginalised groups.
We don’t want to make assumptions, so we should ask the person in the photo about the text alternative. This is most efficiently done at the same time as taking the photo.

Does this image need alt text? was originally published by at Human-centred on November 11, 2025.

Carousels

2025-11-07T00:00:00+00:00

Also known as slide shows and sliders, carousels come and go out of fashion. They tend to fall into the bucket of “designers like them, customers don’t”.

There are a few approaches we can take.

Try not to use a carousel

Don’t bring up carousels at all. Mike Monteiro’s excellent The Market Is Always Out of Carousels talks about this from a design perspective.
Discuss the reasons why they’re usually not a good choice. “Should I use an carousel” brings a humorous take on it, and some quotes and links out to sources.
- They’re often not very accessible, in particular auto-playing ones failing under WCAG SC 2.2.2 Pause, Stop, Hide (A) and a lack of keyboard accessibility
- Users tend to ignore them, sometimes mentally classifying them as advertising
- The content tends to be chosen from motives that are not user-centred
Offer some alternatives.
- Anton Sten’s Why carousels don’t work suggests considering prioritised messaging and content hierarchy.
- Choose more carefullly and show fewer things, removing the need for a carousel
- Use a different pattern like an accordion or a “Show more” button for hiding less important content

Make a good carousel

Follow some good advice on making the most usable and accessible carousel we can.

Brad Frost’s Carousels article has some advice and a call-to-action to gather data to measure their actual effectiveness
Smashing Magazine has an in-depth article: A Step-By-Step Guide To Building Accessible Carousels
Heydon Pickering’s Inclusive components includes A Content Slider
The Carousels Tutorial at WAI
The ARIA Authoring Practices Guide includes a Carousel (Slide Show or Image Rotator) Pattern.
- As with all APG patterns, follow their Keyboard Interaction and WAI-ARIA Roles, States, and Properties guidance, but don’t rely too much on their example code. As they say at the start of each example page: “The code in this example is not intended for production environments.”

Four common carousel issues found in accessibility audits

Like any component, it’s possible to make carousel technically accessible (noting that it may still not be very usable). Here are some common accessibility problems with carousels.

Carousel isn’t identified programmatically

Screen reader users won’t be told that it’s a carousel
To fix it: wrap the carousel in a role="region" and give it an accessible name

Carousel auto-plays and can’t be stopped

This is distracting for many users, and the content may move too quickly to be read
This fails under WCAG SC 2.2.2 Pause, Stop, Hide (A)
To fix it: ideally don’t auto-play, but otherwise have a Pause/Play button

Screen reader users won’t know if anything happened after they pressed the button
This fails under WCAG SC 4.1.3 Status Messages
To fix it: use a (polite) live region to announce the current item after pressing the next or previous button

Current slide (in list of slides) is not programmatically indicated

Screen reader users will have to puzzle out where they are in the carousel
This fails under WCAG SC 4.1.2 Name, Role, Value (A)
To fix it: add aria-current="true" to the current slide in the list

Carousels was originally published by at Human-centred on November 07, 2025.

Notes from "You Deserve A Tech Union"

2025-11-02T00:00:00+00:00

My notes from “You Deserve A Tech Union” by Ethan Marcotte.

I picked it up when it came out, but didn’t read it. The current tech landscape, in particular the rise of AI, nudged me to pick it up and read it now.

Power

Power is a hierarchy of the people who make the decisions and the people who have to conform to them
Our power comes from taking collective action, fighting for dignity, protections, and safety
Solidarity is powerful because it’s open, explicit, acknowledgement of our connections, dependencies, and common humanity

Technology

Ursula Franklin on what happens with every new technology

It appears with grand promises, often on liberation from toil
This drives adoption, and the tech becomes expected and assumed and institutionalised
The promise of liberation is never fulfilled, the tech is used to exploit workers

Unions

A union is a group of workers who, through organisation and collective action, fight for a better life
Unions are a good way to address
- How to keep the things you like about your job
- How to change the things you wish were different about your job
Understanding labour law and how it protects you (and how it doesn’t) will make you a better, more effective, organiser
Step 1: Building Support, Step 2: Outreach and Organising, Step 3: Winning Your Union, Step 4: Negotiating Your Contract

The tech industry

A disconnect between motto and reality is fairly common, especially in mission-driven organisations
The scale of our industry’s problems have changed, but the shape’s the same
- Our industry leans toward eliminating people from the process
- We work in a system that is actively trying to devalue our labour
Deskilling: technology is introduced, overseen by fewer workers, wages lowered and jobs cut. Demand for skilled labour reduced or eliminated. Workers moved into roles they’re overqualified for.

Notes from "You Deserve A Tech Union" was originally published by at Human-centred on November 02, 2025.

Human-centred

How to get the most out of AI

🧑‍🎓 Ask for critical review, rather than asking for approval

🧑‍🔬 Treat responses as a possible answer, rather than the only answer

🕵️ Check the details, rather than trusting them

🧑‍⚕️ Try “AI in the loop”, rather than “human in the loop”

Helping AI-written code be more accessible

Things people are doing already

Things that look new to me

Accessibility-flavoured prompt constraints

Allowing a11y tests failing the build “because AI-produced code”

How to get the most (accessibility) out of a library (or a design system)

See also

Screen reader testing workshop for WWAM

☝️ Before we begin (⏱️5m)

Agenda

✔️ Intro: What does good sound like? (⏱️5m)

💁 Demo: on/off, next/previous, shh! (⏱️5m)

Once-off set up (⏱️5m)

With NVDA on

With Narrator on

VoiceOver

🗣️ Practice: on/off, next/previous, shh! (⏱️5m)

🤓 Discussion: on/off, next/previous, shh! (⏱️10m)

🧠 Theory: we’re testers, not users (⏱️5m)

🗣️ Practice: headings, images, links! (⏱️15m)

🤓 Discussion: headings, images, links! (⏱️10m)

🧠 Theory: the two modes of SRs (⏱️5m)

🗣️ Practice: form and function (⏱️15m)

📋 Aside: listing things (⏱️5m)

🤓 Discussion: form and function (⏱️10m)

🛟 Get help! (⏱️5m)

Severity and WCAG vs best practice

Severity

Deciding on the severity level

Process for deciding Severity

Severity examples

Critical

High

Medium

WCAG or best practice?

WCAG and BP example: new tab

WCAG and BP examples: headings

Prioritisation

Notes for a more social 'Screen reader testing workshop'

Gathered notes

Raw notes

The (more) complete view

Width

Height

Depth

Sketchnotes from Web Directions – AI Engineer Melbourne

My takeaways

Practical

Theoretical

Sketchnotes

Day one - sketchnotes page 1

State of the AI Landscape - George Cameron

Token Town: why token strategy is product strategy - Sarah Sachs

Everything is a Factory - Geoff Huntley

Three lanes below one millisecond - Vamsi Ramakrishnan

Day one - sketchnotes page 2

Fail fast, fix faster: why faster models can beat smarter ones

Why AI coding tools might not make the slightest difference - Jason Cornwall

Constitutional prompting - Prem Pillai

From zero to production - Rachael Zhang

Day one - sketchnotes page 3

Agent observability - Daniel Nadasi

Our AI hallucinated in Production: how we fixed it with evals - Yicheng Guo

The application layer is the new research lab

Orbital lasers vs For loops: economically matching models to tasks - Stephen Sennett

Your AI can’t engineer (yet) - Theo Galanos

Day two - sketchnotes page 1

Growing on purpose: the work that makes you - Jeremy Howard

Craft in the time of agents - Annie Vella

Buidling a mesh LLM from spare compute - Mic Neale

Towards long-horizon tasks - Zixuan Li

Day two - sketchnotes page 2

Spec-driven AI development - Nick Beaugeard

Building SDKs in the agentic era - Mark McDonald

Ask for critical review, rather than asking for approval

Treat responses as a possible answer, rather than the only answer

Check the details, rather than trusting them

Try “AI in the loop”, rather than “human in the loop”

Before we begin (5m)

Intro: What does good sound like? (5m)

Demo: on/off, next/previous, shh! (5m)

Once-off set up (5m)

Practice: on/off, next/previous, shh! (5m)

Discussion: on/off, next/previous, shh! (10m)

Theory: we’re testers, not users (5m)

Practice: headings, images, links! (15m)

Discussion: headings, images, links! (10m)

Theory: the two modes of SRs (5m)

Practice: form and function (15m)

Aside: listing things (5m)

Discussion: form and function (10m)

Get help! (5m)

NVDA only: `NVDA key` and Turn on highlighting