On a Sandy Beach: WCAG

Showing posts with label WCAG. Show all posts

Ajabbi slide talks

Mike's Notes

I will have to give many presentations (talks and demos) in the future, so here is a rough plan that builds on an earlier note from a month ago. Feedback on this is welcome.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

12/03/2026

Ajabbi slide talks

By: Mike Peters

On a Sandy Beach: 09/03/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Background

I previously gave hundreds of slide talks to conferences, workshops, and public meetings in NZ. I enjoyed explaining complex things so that anyone could understand. Everything from 30 seconds to 2+1/2 hours. But that was years ago.

As Pipi continues to develop and international interest grows, I will have to give many talks to different audiences in the future.

The need is now becoming urgent, with requests and opportunities arriving.

What works

I'm also highly visual and prefer to talk about something I can see, like a map, chart, video, gadget, or drawing, rather than read a speech.

What is needed

Audiences

Software developers
Scientists
Pitching to a panel
Training users
Radio or TV interviews
Contractors
Volunteers and staff
Open office hours
etc

Format

In-person
Remote
Hybrid

Delivery

Live
Pre-recorded

Modular

Short & consice
Combined for longer talks.

What will happen

This is what I thought might work.

Design a structured outline of topics to cover.
Design a simple uniform slide format.
Apart from the title, utility, and end slides, use one slide per minute, following the 5:5:5 rule.
Practice delivering some to the fortnightly research group I attend online, as well as to other groups I am a member of.
Start rapidly manufacturing slide talks based on the priority of need.
Reuse the notes and images from the 650 posts on this blog.
Create simple 1-page A4 summary notes for print, hand out, event notices and email invitations.
Record the talks with slides in advance and upload them to YouTube as a library.
Pre-record short videos of live demos of using Pipi and upload them to YouTube as a library.
Save and share the slides using links as PowerPoint, Google Slides, or Adobe PDF. On Slideshare.
Automate by using the Pipi CMS Engine (cms) to store, reuse, update, render, and manage metadata, put in the right place, etc

Work Log

09/03/2026

Wrote this post
Made A4 paper card mockups of typical slides, looking at layout, fonts, and colours

10/03/2026

Created a topic outline (Google Sheet)
Watched how TED recommend how to give talks
Built a temporary Access Database to organise content. To be imported into the Pipi Learning Object Engine (lob) and use those tools to further configure.

ID
Code No, e.g., "103-10045-100001-eng-US", "103-10045-100001-fra"
Footer, e.g., "Ajabbi Learn"
Collection, e.g., "Signing Up"
Title (5 word max), e.g., "Creating your profile"
Subtitle (5 word max)
Slide Talk Flag Y/N
Video Demo Flag Y/N
PDF Summary Flag Y/N
Note

Imported the Google Sheet topic outline into the database
Discovered Free/open-source screen capture software to pre-record live demos for YouTube.

"ShareX (Windows): Open-source, lightweight, and excellent for both screen recording (including GIFs) and screenshots, featuring powerful, automatic sharing options."
"OBS Studio (Windows/Mac/Linux): The premier choice for high-quality, unlimited, and feature-rich recording. It is ideal for streaming and complex recordings but has a steeper learning curve."

11/03/2026

Added list of slide footers (lower right-hand side)
Added list of Collections

12/03/2026

Created codes

3-digit footer
5-digit collection
6-digit presentation

Heavy editing and reorganising

Content reuse

The same material can be reused in many formats.

Developer Docs
User learning (Diataxis)
In-context workspace help
Newsletters
This blog
Whitepapers
Etc

Slide Footers (Host websites)

Visit the Presentation Catalogue (Google Sheet)

100 Ajabbi
101 Ajabbi Learn
102 Ajabbi Design
103 Ajabbi Research
104 Ajabbi Foundation
105 Ajabbi Developer
106 Ajabbi Handbook
107 pipiWiki
108 Ajabbi Community
109 Ajabbi Project
110 Ajabbi i18n
111 Ajabbi Workspace

Collections

Visit the Presentation Catalogue (Google Sheet)

101-10001 Personal Account
101-10002 Enterprise Account
101-10003 Developer Account
101-10004 Researcher Account
101-10005 SME Account
107-10006 Engines
101-10007 Content Management System
106-10008 History
106-10009 Engineering
106-10010 Ajabbi
103-10011 About
103-10012 Research Publications
103-10013 Research Platform
104-10014 Mission
101-10015 Agent Account
102-10016 Components
102-10017 Accessibility
109-10018 Accessibility
105-10019 Boxlang
107-10020 Industries
107-10021 Plugins
109-10022 i18n
103-10023 Complex Systems
104-10024 Programme
104-10025 Board

Talks & Demos

Visit the Presentation Catalogue (Google Sheet)

101 Ajabbi Learn

101-10007 Content Management System

101 Introduction
102 Content Management System
103 Publication
104 Website
105 Blog
106 Wiki
107 Docs
108 Help
109 Workspace

<Unknown>

Agents & engines
How to use the engines
DevOps
Security
Pipi
Sign up
Choosing an account type

101-10001 Personal Account

Personal Account
Username, password, and 2FA
Account settings
Create a profile
Languages
Accessibility
Support
Training

101-10002 Enterprise Account

Enterprise account
Account settings
Default Language
Billing
Support
Training
Creating a deployment
Choose a Language
SaaS configuration
Creating a workspace
Adding modules
Adding Plugins
Roles and Permissions
Adding Users

101-10003 Developer Account

Developer account
Account settings
Default Language
Billing
Support
Training
Creating a deployment
Choose a Language
Creating a workspace
Adding modules
Adding Plugins
Roles and Permissions
Adding Users

101-10004 Researcher Account

Researcher account
Account settings
Default Language
Billing
Support
Training
Creating a workspace
Adding modules
Adding Plugins
Roles and Permissions
Adding Users

101-10005 SME Account

SME account
Account settings
Default Language
Billing
Support
Training
Choosing a module
Roles and Permissions
Adding Users

101-10015 Agent Account

Agent Account
Account settings
Default Language
Billing
Support
Training
Creating a deployment
Choose a Language
Creating a workspace
Adding modules
Adding Plugins
Roles and Permissions
Adding Users

102 Design System

102-10016 Components

102-10017 Accessibility

103 Ajabbi Research

103-10011 About

Ajabbi Research
Role and purpose
Income
Open handbook
Team culture
Open Research
Library
Projects

103-10023 Complex Systems

103-10012 Research Publications

Publications
Newsletter
Friday Report
Seminars
On arXiv

103-10013 Research Platform

104 Ajabbi Foundation

104-10014 Mission

Ajabbi Foundation
Role and purpose
Income
The Open Handbook
Team culture

104-10025 Board

104-10024 Programme

Future support
Ortus Open-source
SIL KeyMan
User groups
Books

105 Pipi Developer

105-10019 Boxlang

BoxLang in a VM
BoxLang in Docker

106 Ajabbi Handbook

106-10010 Ajabbi

Ajabbi intro
Who am I
Resources
Thanks & Questions
Origin
Mission & values (why)
Organisational form
Ajabbi
Role and purpose
SaaS
Profit distribution
From customers to community-driven
Bootstrap Startup
Scaling
Open-source
GitLab
GitHub
Future Collaborations
Unicode
OMG
W3C WCAG
CNCF
Pipi
Intro
Origin

106-10008 History

Pipi 1-5 (1997-2008)
Pipi 6 (2017-2019)
Pipi 7 (2020)
Pipi 8 (2021-2022)
Pipi 9 (2023-2026)

106-10009 Engineering

Closed core & open-source
Closed-core
Roadmap
Pipi 9 (2023-2026)
Pipi 10 (2027-2029)
Pipi 11 (2030-)
Open-source
Roadmap
Pipi 9 (2023-2026)
Pipi 10 (2027-2029)
Pipi 11 (2030-)

107 pipiWiki

107-10006 Engines

Algorithm Engine (alg)
CMS Engine (cms)
Configuration Engine (cnf)
Factory Engine (fac)
Workflow Engine (wfl)
Workspace Engine (wsp)

107-10020 Industries

Agriculture
Arts & Culture
Built Infrastructure
Civil Defense
Data Centre
DevOps
Learning
Nature Conservation
Research
Transport

107-10021 Plugins

AddThis
Amazon Book
Apple Map
Apple Music
ArcGIS Map
Atlassian Analytics
Azure Map
Cacophony
CloudConvert
CodePen
CodeSandbox
Confluence
Elfsight Weather
Flightradar24
FormBlock
GitHub-Embed
GitLab Snippet
Google Analytics
Google Calendar
Google Docs
Google Form
Google Map
Google Meet
Google Sheets
Google Slides
Instagram
IUCN Threat Status
Jira Advanced Roadmap
JSBin
Jupyter Notebook
KeyMan
MailChimp
Metservice Weather
Microsft Forms
Monaco Editor
NASA Spot the Station
NASA Worldview
NetSuite Case Form
NIWA CO2 Widget
NIWA Tide Widget
NIWA UV Widget
NIWA Weather Widget
Odoo Form
PDF
PostHog Analytics
Survey Monkey
Trello Board
Trello Card
TypeForm
VesselFinder
Vimeo Video
Weather Widget
Wolfram Notebook
Yandex Map
Yandex Video
YouTube Video
Zoho Calendar
Zoho Form
Zoom Meeting

108 Ajabbi Community

109 Pipi Project

109-10018 Accessibility

Accessibility Profile
UK.Govt Design Guide

109-10022 i18n

Web KeyMan
Mobile KeyMan

110 Ajabbi i18n

111 Ajabbi Workspace

The Accessibility Issue

Mike's Notes

This is a copy of the February issue of Ajabbi Research.

It is about the history of the effort to create a fully accessible User Interface (UI) for Pipi.

Ajabbi Research is published on SubStack on the first Friday of each month, and subscriptions are free.

Each issue is a broad historical overview of a research topic, serving as an index to dozens of previously posted related articles. There are now 647 articles/posts.

This copy of the issue will be updated with additional information as it becomes available. Check the Last Updated date given below.

Eventually, each issue will be reused on the separate Ajabbi Research website as an introduction to a research area comprising multiple research projects.

Resources

https://ajabbi.substack.com/archive

References

Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) 1.2, W3C, 6 June 2023.
Web Content Accessibility Guidelines (WCAG) 2.2, W3C, 12 December 2024.
GOV.UK Design System.

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

6/03/2026

The Accessibility Issue

By: Mike Peters

Ajabbi Research: 6/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

This is the story of the effort to make Pipi fully accessible to all who need it. The steps taken have been part of Pipi's development since 2005, spanning 5 versions.

The NZERN Pipi 2003-2005 Development Plan started it all.

https://www.blog.ajabbi.com/2016/10/nzern-pipi-2003-2005-development-plan.html

Pipi 4 (2005-2008)

The story starts with Pipi 4. It was a big, successful system that supported community-driven Ecological Restoration in NZ. Here is a history of that Pipi version.

https://www.blog.ajabbi.com/2017/09/pipi-4-2005-2008.html

During that time, New Zealand (NZ) had dial-up modems. Many NZERN members were working farmers in rural areas, with very slow internet. Many were older with low computer literacy. This was a major factor determining what was possible. Web page sizes had to be kept under 16kb.

Recently, an archive of Pipi 4 help documentation was discovered and is now available for viewing. It is incomplete, but it gives an idea of how it worked.

https://example.ajabbi.com/eng/4/help.bush.org.nz/index.html

Here is the description taken from the Pipi 4 Help archive. The Screen Reader Edition was designed for the blind members of NZERN by their family members.

PIPI4 is available in four editions to meet the needs of different groups of NZERN members.

Basic Edition

Designed for the novice computer user who wants a simple cut-down system, with instructions built into every step.
Skill level required: Capable of using a simple program like Outlook Express
Availability: All members of NZERN

Standard Edition

Designed for the confident computer user who wants a system with help available with one click. The user can ask questions and report bugs to the help desk.
Skill level required: Capable of using a program like Microsoft Word
Availability: All members of NZERN

Screen Reader Edition

Designed for the confident computer user who uses a screen reader and wants help available with one click. The user can ask questions and report bugs to the help desk.
Skill level required: Capable of using a program like Microsoft Word
Availability: All members of NZERN

Professional Edition

Designed for the expert computer user capable of self-learning, who wants a fast system with detailed technical documentation available with one click. The user will provide support to other members as a member of the help desk.
Skill level required: Capable of using an advanced program like Adobe Photoshop
Availability: All members of the help desk

Pipi 6 (2017-2019)

When Pipi was rebuilt from memory, some work was done to prepare for a more modular, standardised model-driven User Interface (UI) approach. Metadata was added to every database table to enable future personalisation and meet accessibility requirements.

https://www.blog.ajabbi.com/2020/01/pipi-6-2017-2019.html

Pipi 7 (2020)

Small, simple, static HTML mockups of workspaces were created as experiments.

https://www.blog.ajabbi.com/2021/03/pipi-7-2020.html

Pipi 8 (2021-2022)

System-wide namespaces were implemented to enable future complex automated interactions.

https://www.blog.ajabbi.com/2022/12/pipi-8-2021-2022.html

Pipi 9 (2023-2026)

In 2023, a year-long investigation into model-driven interfaces led to the reuse and hacking of several abandoned EU research efforts in Human-Computer Interaction (HCI).

https://www.blog.ajabbi.com/2023/12/pipi-9.html

Putting a User Interface (UI) on the front end of Pipi 9 was challenging. It had to be

Model-driven
Adaptive to the users' devices
Automated
Meet the individual needs of each logged-on user

Resources used

OMG Interaction Flow Modelling Language (IFML)
The CAMELEON References Framework (CRF)
User Interface Description Language (UIDL)
W3C Model-based UI Incubator

https://www.blog.ajabbi.com/2023/12/model-driven-user-interfaces.html

Model-driven UI

The User Interface Description Language (UIDL) was an EU-funded project that was abandoned in 2010 after 10 years of excellent work. It was to enable accessibility on different screens and devices. The research results were reverse-engineered to build a User Interface Engine (usi) that would run in reverse to generate accessibility solutions for Pipi. The CSS Engine (css) replaced some redundant components of the UIDL project. Additional engines for localisation and personalisation were created.

https://www.blog.ajabbi.com/2023/12/model-driven-user-interfaces.html

UK Design System

The UK Government has created a design system for building accessible websites. It includes many templates, components, tools, code, and guidance on achieving this. An excellent resource.

These templates are being used for the Pipi-generated workspace User Interface (UI)

Example

https://www.blog.ajabbi.com/2023/12/uk-government-design-system.html

A teaching customer

Mr G, my coach from Startup Aotearoa, suggested finding a first customer who could be a teaching customer. What a good idea.

As it happens, a new disability rights organisation emerged in response to funding cuts by the NZ government. The group led a national campaign that resulted in the Minister responsible for the cuts losing her job and the scale of the cuts being reduced. The group had no money and needed a large campaign website that was highly accessible for deaf and blind people. Helping lead this campaign and building the website were deep learning experiences for me.

https://www.blog.ajabbi.com/2025/06/some-initial-notes-on-what-my-first.html

Pipi CMS Engine (cms)

A decision was made early on to autogenerate a separate website for each language (English, Māori, NZ Sign Language, and AAC picture language). This was the simplest solution for the CMS and the users.

Creating UI for each natural language, including sign languages (i18n), requires user requests and volunteer testers.

The CMS uses a template engine that builds web pages from reusable components. This means that getting CCS correct only needs to be done once for each component, and so on.

Sign Language

The scheme was dreamed up to embed NZ Relay Video Interpreting onto any webpage. This is an ongoing experiment, driven by deaf people.

Blind and Low Vision

This didn't get far because blind people in NZ were needed to volunteer to help with testing. However, there are volunteers in other countries. This job depends on ongoing work on the CSS Engine (css). A particular challenge is catering for braille machines.

Picture Language

Professor Stephen Hawking used AAC via a computer-generated voice. There are many forms of AAC, including picture language. Providing this as a UI is being explored, with other AAC to follow. Important for the millions of people with Cerebral Palsy and Motor Neurone Disease.

https://www.blog.ajabbi.com/2026/02/how-intel-gave-stephen-hawking-voice.html

Workspace personalisation

The workspace settings will offer complete personalisation of the UI. Similar in purpose to the wonderful AccessWidget from Accessibe.com. Instead of a pop-up, it will use a personalisation form in account settings.

Keeping it simple

On paper, WAI-ARIA looks great. However, the reality is that the growing interactive complexity of websites and differences in how browsers work mean that web pages break for people using assistive technology.

https://www.blog.ajabbi.com/2025/06/what-i-wish-someone-told-me-when-i-was.html

Modern websites present a large attack surface, making them vulnerable. Pipi's solution is to focus on functionality, usability, and maximum simplicity. Small page sizes (Kb), semantic structure, and minimising JavaScript use.

Standards

The W3C Web Content Accessibility Guidelines (WCAG) sets the international standard for providing full accessibility. Pipi will endeavour to meet WAIG 2.2 as a new conformance target for all languages.

Whats next

Designing the workspaces has made accessibility through personalisation a top requirement. The ongoing 2026 workspace rollout will include further accessibility testing.

https://www.blog.ajabbi.com/2026/02/the-workspace-issue.html

Thanks

The most useful and inspiring resource has been Smashing Magazine's weekly newsletter, which often covers accessible UI design in great depth.

https://www.smashingmagazine.com/the-smashing-newsletter/

Dedication

Those who have fought all their lives for a world where people with disabilities have equal rights and can fully participate without barriers to the extent they are capable.

WCAG 2.2 is here

Mike's Notes

WCAG 2.2 is the new accessibility standard that Ajabbi must work very hard to meet.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

11/01/2026

WCAG 2.2 is here

By: Chris Pycroft

Intopia: 05/10/2023

"The World Wide Web Consortium (W3C) has finalised the next version of the Web Content Accessibility Guidelines, known as WCAG 2.2.

After much anticipation, the latest version of the Web Content Accessibility Guidelines (WCAG) has finally arrived. Version 2.2 has officially been made a ‘Recommendation’ by the World Wide Web Consortium (also known as the W3C), which means it is stable with no further changes. For any organisation wanting to conformance to the latest version of WCAG, WCAG 2.2 will be your go-to version.

It’s the first major update to the Web Content Accessibility Guidelines in nearly five and a half years, with the last update, WCAG 2.1, launched in June 2018.

So what’s new in WCAG 2.2?

As a part of the updated Guidelines, there are 9 new success criteria.

There are 2 new Level A criteria:

3.2.6 Consistent Help
3.3.7 Redundant Entry

There are 4 new Level AA criteria:

2.4.11 Focus Not Obscured (Minimum)
2.5.7 Dragging Movements
2.5.8 Target Size (Minimum)
3.3.8 Accessible Authentication (Minimum)

There are 3 new Level AAA criteria.

2.4.12 Focus Not Obscured (Enhanced)
2.4.13 Focus Appearance
3.3.9 Accessible Authentication (Enhanced)

Most of the new criteria are design-driven requirements. They also take into consideration the increased use of certain technologies, such as multi-factor authentication.

There is also one change to an existing success criterion – 4.1.1 Parsing (Level A) has been marked as obsolete and removed. This criteria, released as part of WCAG 2.0, was necessary when assistive technologies needed to directly parse HTML, and parsing errors weren’t handled as well as they are today. As a result, issues that were previously covered by this criterion either no longer exist, or are covered by other success criteria. Notes have also been added to previous versions of WCAG (2.0 and 2.1) to reflect this update.

Does this mean I need to start thinking about WCAG 2.2?

The short answer is yes.

Now that the new version is finalised, the W3C recommends that websites meet WCAG 2.2. Embracing the new requirements also means a more accessible experience for people using your product or service.

We anticipate that policies and standards that reference WCAG 2.1 or below, such as the European Commission’s Web Accessibility Directive, or EN 301 549, will be updated to reflect WCAG 2.2 in the future. We’ll keep you updated of changes over the coming months. In the meantime, to future-proof your products and services, consider moving to WCAG 2.2 as soon as you can, especially for new content or features.

The good news is that if you’re already meeting all the requirements of WCAG 2.1 (or are in the process doing so), you’re already most of the way there. The most common conformance level that organisations typically aim for is Level AA. This means that there are 6 new Level A and AA success criteria that you need to take into consideration. By conforming to WCAG 2.2, you’ll also conform to previous versions of the Guidelines (2.1 and 2.0).

Where can I find more information about WCAG 2.2?

There is already some useful information and resources that are available to you, and there’s also plenty more on the way.

The main source of truth, the World Wide Web Consortium, has published the standard in full, along with supporting documentation to help you understand the guidelines:

We also have an updated version of our much-loved WCAG Map! The WCAG 2.2 Map is now available and can be used to map out what success criteria you need to consider (see what we did there).

We’ll also be hosting an Ask Us Anything free webinar on Wednesday 18 October at 1pm AEDT (GMT +11). You’ll have the opportunity to hear from our team about what they think of the updates to WCAG, and ask them any questions about WCAG 2.2.

We’ll also have more information and helpful resources available over the coming weeks. These will help you understand exactly what the new success criteria are, and how to meet them. Follow us on LinkedIn, X (formerly Twitter), Facebook and YouTube, or subscribe to our newsletter (which you can do at the bottom of this page) to stay up to date. We’ll also be updating our Not-Checklist soon, stay tuned.

If you’re keen to hop down the rabbit hole and begin the journey to meeting WCAG 2.2, we’re here to help. In fact, we’ve already helped some of our client organisations who have been implementing WCAG 2.2 before it was finalised. Contact us through our website, and someone from our team will get back to you.

Happy WCAG 2.2 release day!"

WCAG 2.2 Map

ARIA and Design Systems

Mike's Notes

Pipi is primarily a workplace tool. One of Ajabbi's top objectives is to use technology to eliminate barriers so that disabled people can work as a fundamental human right.

The Pipi 9 Design System database has a draft set of UI component primitives to which any other design system components could be mapped.

The Pipi 9 Content Management System (CMS) always starts with these primitives (then calls the derived design system) when rendering UI on web pages.

I previously created a rough list of primitives. Then, I discovered that ARIA has a well-defined list of "patterns" that could be used as primitives.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

17/05/2025

ARIA and Design Systems

By: Mike Peters

On a Sandy Beach: 09/06/2024

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

ARIA list of "Patterns"

Solving several problems

Accessibility is not an afterthought.

Any Design System UI components would automatically be referenced to ARIA, and so work for disabled people.

ARIA is an accepted, robust international standard. Occasionally, the standards will be updated.

It answers the problem of what component primitives to use and how to name and describe them. It would also save a lot of work.

The page layout still works. And ARIA Roles would be the default names to use.

Nested components still work. ARIA will ignore the nesting.

The Design Tokens will not be affected.

The reference to ARIA in the Design System docs will be automated.

Unanswered questions

What happens with other languages? Are WAI-ARIA roles translated into Chinese, French, etc?

Are there Design System components that won't map to these primitives?

Is this the latest version of patterns? MDN and W3C ARIA have slightly different lists.

Next steps

Importing the ARIA "pattern" definitions.

Update the derived Pipi Design System.

Look at a series of existing websites that compare how different design systems implement the same component and what names they use. Try importing popular design systems, e.g. Bootstrap, Foundation, and Material, to ensure no mapping problems.

UK Government Design System

Mike's Notes

The UK Government has created a design system for building accessible websites. It includes many templates, components, tools, code, and guidance on achieving this.

I am using this design system as a starting point for making the Pipi User Interface (UI) fully accessible.

Please note: This blog is for a technical audience and is intended to help Mike (me), who has synesthesia (that's why everything is colour-coded), keep notes and share them with collaborators. It is not intended to be accessible.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

18/05/2025

UK Government Design System

By: Mike Peters

On a Sandy Beach: 31/12/2023

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

User Testing

Assume every person is unique and allow for personalisation. W3C WCAG 2.1 is the standard to aim for. Accessibility testing is underway in English for,

Braille Devices for the Deaf-Blind
Screen Readers
Screen Magnifiers
Low Vision
Irlen's
Colour Blindness
Dyslexia
Dyscalculia
Autism
Epilepsy
Synesthesia
Strokes
Older adults require a more straightforward UI
Muscular Dystrophy (large buttons)

The current testing process steps are,

Speak to groups of people and their organisations with everyday accessibility needs. Ask for volunteers.
Watch and learn from people who volunteer with accessible needs. How do they find using a computer to visit and use a website? What are the problems? What works?
Use personalised handmade web pages for volunteers to test.
Configure the Content Management System (CMS) to generate the web UI automatically to meet the individual accessibility needs of logged-in users.

UK Gov Design System

The UK government's design principles and examples of their use.

Start with user needs
Do less
Design with data
Do the hard work to make it simple
Iterate. Then iterate again
This is for everyone
Understand context
Build digital services, not websites
Be consistent, not uniform
Make things open: it makes things better

The Design System components are reusable parts of the user interface that have been made to support various applications.

Accordion
Backlink
Breadcrumbs
Button
Character count
Checkboxes
Cookie banner
Date input
Details
Error message
Error summary
Exit this page
Fieldset
File upload
Footer
Header
Inset text
Notification banner
Pagination
Panel
Phase banner
Radios
Select
Skip link
Summary list
Table
Tabs
Tag
Task list
Text input
Textarea
Warning text

Patterns are best-practice design solutions for specific user-focused tasks and page types.

Ask users for…

Addresses
Bank details
Dates
Email addresses
Equality information
Gender or sex
Names
National Insurance numbers
Passwords
Payment card details
Telephone numbers

Help users to…

Check if a service is suitable
Check answers
Complete multiple tasks
Confirm a phone number
Confirm an email address
Contact a department or service team
Create a username
Create accounts
Exit a page quickly
Start using a service
Recover from validation errors

Pages

Confirmation pages
Cookies page
Page not found
There is a problem with the service pages
Question pages
Service unavailable pages
Step-by-step navigation

Free Posters

The UK Home Office has free Accessibility design posters (PDF).

DWP Accessibility Manual

Smashing Magazine

Smashing Magazine has even more articles and ebooks on accessibility

Chrome's web.dev

Accessibility for web developers