Nick Freear’s blog

Vocal Accessibility Part 3: A critique of PAS 901:2025, and testing

Tue, 12 May 2026 08:00:00 +0000

In this post, I’m presenting a critique of PAS 901:2025 Vocal accessibility in system design. This follows on from the Part 2 post, where I quoted some of the content from the Code of Practice, particularly Part 5, System Design.

I need to preface the critique with two points. First, PAS 901:2025 is a really important document, the result of a lot of hard work, and the first time anyone has tried to describe and specify what Vocal Accessibility should entail. This critique is written in the spirit of wanting to take this valuable work and build on it. And second, I believe that PAS 901:2025 was developed with a design mindset, whereas I with my Accessibility Consultant hat on, view it more through a testing and auditing lens.

Video: Vocal Accessibility Part 3, on Vimeo.

Critique 1: not open

The first critique concerns openness in all its forms. PAS 901:2025 is published as a DRM-protected PDF through the BSI shop, where you need to register an account, add it to your shopping basket and checkout. It costs £0.00 (GBP). It is copyright “© The british Standards Institution 2025”, and carries the statement or warning “No copying without BSI permission except as permitted by copyright law”.

As the Code of Practice is published as a PDF and is behind a paywall, it is not possible to deep link to different sections. By contrast, this is something that is straightforward with, for example, the Web Content Accessibility Guidelines, where you can link to the whole standard, one principle, a [guideline][wmcag:g-1.1] or an individual Success Criterion (W3C license).

It is worth noting that the PDF is untagged, and therefore not accessible to those using assistive technologies such as screen readers.

Finally, the process and governance around developing PAS 901:2025 was not open. There was no opportunity to feedback on early drafts of the work, and as far as I know, the first that the wider community was aware was when it was published in March 2025.

All of the above lead, I believe, to siloed thinking, the inability to freely share, blog, create bug reports, improve and re-use PAS 901:2025 (including, self-censorship). Overall, this is likely to restrict usage and uptake. <!–

Restricted access & copyright (BSI “shop” £ 0)
PDF, not HTML (without deep-linking) (+ untagged PDF!)
Closed governance. Consequences:
Siloed thinking
Not free* to share, blog, create bug reports **, improve, re-use… b) “self-censorship”
Likely to restrict usage and uptake. –>

Critique 2: sub-clauses not prioritized (too big!)

The second criticism concerns prioritization and the scale of PAS 901:2025. There are 60 sub-clauses in section 5 of the Code of Practice, with no indication if any of them should be considered more or less important than the others. This is similar in scale to the 57 Success Criteria in WCAG 2.2 Level AA. However, WCAG tries to cover all disabilities and digital accessibility considerations (except voice/speech), while PAS 901:2025 only covers vocal accessibility.

This leads to a few questions and consequences. Do individual organizations have to research and assign priorities, given that it is hard to share information (openness)? Would an audit of a speech-enabled system need to test all 60 sub-clauses, plus WCAG? (A big undertaking.) Again, this is likely to restrict usage and uptake. <!–

Section 5 has 60 sub-clauses (similar scale to WCAG 2.2 A+AA, 57)
No concept of level A, AA, AAA. Consequences:
Different orgs have to research/assign priorities.
Would an audit need to test all 60 sub-clauses (+WCAG)?
Likely to restrict usage and uptake. –>

Critique 3: objectivity / testable?

The third critique concerns objectivity and testability. Taking the Web Content Accessibility Guidelines as an example again, while there are grey areas such as informative versus decorative images, there are also many Success Criteria that are objectively testable, and have thresholds and other quantitative criteria. Examples, include Contrast (minimum), Reflow and Three Flashes or Below Threshold.

By contrast, sub-clause “5.4.16 Support for conversational interactions – Interrupting a user” in PAS 901:2025 talks about “sufficient time”, without specifying or suggesting what the time should be, and “5.5.3 Fairness” states that “Systems should behave fairly with regard to protected characteristics”, without defining what “fairness” means (fairness is hopefully the ultimate aim of all accessibility work, including vocal accessibility — I suggest that it is too high level).

I should note that there are sub-clauses that appear to be objectively testable, for example, “5.1.1 Individualization”, which talks about multi-modal presentation and operation. Whether a system is multi-modal is hopefully a binary decision. <!–

Can sub-clauses be objectively tested?
Was testability/ measurability considered during writing/dev.?
Thresholds/ timeouts/ numbers?
Example, “5.5.3 Fairness - Systems should behave fairly with regard to protected characteristics” Consequences:
1. Testing/ audits would be difficult,
2. Likely to restrict usage and uptake. –>

How to test?

When I presented at TechShare Pro 2025 colleagues were keen that I included a practical discussion of how to conduct testing for vocal accessibility. This very much remains a work-in-progress, but here are some thoughts.

As noted above, there are sub-clauses that can be tested in a binary (pass/fail) manner. Analysis is required to determine which sub-clauses can be objectively tested without further work.

There are sub-clauses, as highlighted above, which require further research. Sub-clause 5.4.16, which was referenced above, talks about “sufficient time”. We can envisage this being achieved by giving the user the option to customise the recognition timeout(s) for a speech-enabled system. User research can help us determine a practical range of timeouts to offer the user.

A number of sub-clauses deal with accuracy of speech recognition, and this throws up an interesting challenge, namely that testing recognition requires a “user input”. This is fundamentally different to things like testing colour contrast for WCAG. Contrast can be tested using software and algorithms, without a user being present to perceive the colours.

So, how are we to test speech recognition? Does it require accessibility consultant professionals to “mimic” a range of non-typical speech, including stammers/stutters? No, this is clearly unacceptable, as well as being unfeasible.

One can envisage a bank of “standardized” audio samples that could be used for repeatable testing. Questions arise around how to collect samples, managing access, and data protection. We would need to guard against things like un-authorized voice cloning. We could collaborate with groups like the Speech Accessibility Project at the University of Illinois Urbana-Champaign. We would need to ensure that data used for testing is not the same as that used for training by software vendors (Train, Test, Validation split).

There are unresolved questions relating to the range of speech-types and dis-fluencies that we can test with, how to produce the “minor” and “significant” failures of speech recognition that are mentioned in sub-clauses in PAS 901:2025 (5.5.5, 5.5.6, and so on).

And, there is always an alternative to an audit-type approach in the form of diverse user-testing.

That concludes my critique of PAS 901:2025, and our discussion of testing challenges and methods.

Vocal Accessibility Part 2: What is in PAS 901:2025?

Mon, 27 Apr 2026 18:00:00 +0000

In part 1 of this series of blog posts, we looked at where the PAS 901:2025 Vocal Accessibility Code of Practice came from, what technologies are covered by it, and who it is for.

In this post, we’re going to delve deeper into the actual contents of the PAS. The Code of Practice comprises a foreword, 6 parts and 3 annexes, as can be seen in the table of contents below. We are going to concentrate on parts 4 “Goals and user accessibility needs approach”, and 5 “General design”.

"Foreword `. . . . . . . . . . . . . . . . . . . . . . . . . . . .`	ii
0 Introduction `. . . . . . . . . . . . . . . . . . . . . . . . . .` 	iv
1 Scope `. . . . . . . . . . . . . . . . . . . . . . . . . . . . . `	1
2 Normative references `. . . . . . . . . . . . . . . . . . . . . . `	3
3 Terms, definitions and abbreviated terms `. . . . . . . . . . . . . `	4
4 Goals and user accessibility needs approach `. . . . . . . . . . . . ` 	8
5 General design `. . . . . . . . . . . . . . . . . . . . . . .  . .`	11
Annex A (informative) An exemplar using accessibility goals and needs `. . . `	25
Annex B (normative) Procurement scenarios `. . . . . . . . . . . . . . . `	41
Annex C (normative) List of additional user accessibility needs `. . . . . ` 	42
Bibliography `. . . . . . . . . . . . . . . . . . . . . . . . . . .  `	44"

Part 4 (page 8) builds on ISO/IEC 29138-1:2018, Information technology – User interface accessibility – Part 1: User accessibility needs and outlines how to document the accessibility requirements, including vocal accessibility needs, during the design and procurement of a product or service. It is key to the whole approach espoused by PAS 901:2025.

Video: Vocal Accessibility Part 2, on Vimeo.

Part 5 “General design” contains a series of clauses and sub-clauses under the following 8 headings:

"5.1 Multimodality `. . . . . . . . . . . . . . . . . . . . . . . . . `	11
5.2 Language `. . . . . . . . . . . . . . . . . . . . . . . . . . . `	12
5.3 Speech processing `. . . . . . . . . . . . . . . . . . . . . . . `	13
5.4 Interaction `. . . . . . . . . . . . . . . . . . . . . . . . . . .`	15
5.5 Feedback, error prevention and error correction `. . . . . . . . . . `	19
5.6 Privacy and trust `. . . . . . . . . . . . . . . . . . . . . . . . `	21
5.7 Speech technology services `. . . . . . . . . . . . . . . . . . . `	23
5.8 Training `. . . . . . . . . . . . . . . . . . . . . . . . . . . . `	24"

We’ll go through some examples of the sub-clauses in order, starting at the beginning with “5.1.1 Individualization” (page 11):

“When delivering electronic information, a system should provide the modalities that best serve the user’s needs or preferences in that context, selectable singly and together.”

This sub-clause is saying that a system should allow the user to interact using speech/voice, text or other modalities, or a combination of them. Its hopefully a fairly obvious requirement, and brings to mind guidelines in the Web Content Accessibility Guidelines 2.2 such as 2.1 Keyboard Accessible and 2.5 Input Modalities.

Jumping ahead to “5.3 Speech processing”, we have sub-clauses such as “5.3.6 Speech impairment” (page 14):

“Speech recognition and automatic language translation should be performed in a manner that achieves an equal level of recognition and correctness for all speakers including speakers with impaired speech or specific speech disabilities.””

This speaks to the need for fairness and equal access to voice-based software and systems.

These first two examples are generic, while the next one, “5.4.9 Telephone and internet menu systems – recognition failure” (page 18) is specific:

“Voice recognition systems running over a telephone or internet menu system should provide an simple means to access and communicate with a human after failed attempts to recognize voice input.”

As a person with a stammer (stutter) who has had many difficult and demoralizing interactions with automated phone systems, the requirement to have a human as a backup strikes me as really valuable.

We will continue with “5.4 Interaction”, and look at “5.4.16 Support for conversational interactions – Interrupting a user” (page 19). This says:

“Products, systems or services accepting vocal input or supporting vocal interaction should provide sufficient time for a user to speak and not respond before presuming an utterance is complete.”

Again, one of the biggest frustrations as someone who stammers is being interrupted by humans or machines, so this makes sense.

The final sub-clause we are going to cover is “5.5.4 Tolerance of minor speech errors” (page 20):

“A system that accepts vocal input should be tolerant to minor speech errors made by the user.”

This requirement also seems reasonable, as anyone can make mistakes when they speak. Like many of the sub-clauses in part 5, this requirement also seems reasonable, as anyone can make mistakes when they speak.

I should mention that many of these sub-clauses have notes and references to goals and user needs, which are excluded here for brevity.

Hopefully, the above quotes and discussion have given you a flavour of what is contained in PAS 901:2025. This concludes part 2.

In part 3 I’ll present a critique of PAS 901:2025, and considerations for testing.

Vocal Accessibility Part 1: What is PAS 901:2025?

Mon, 13 Apr 2026 18:00:00 +0000

The Web Content Accessibility Guidelines (WCAG) are the leading international standard for digital accessibility, developed by the World Wide Web Consortium. Version 2.2 is the latest version, published as a recommendation in 2023, and it covers almost all disabilities to varying degrees, including vision, hearing, mobility/motor and cognitive/specific learning disabilities. The one disability it makes no mention of is speech. It just doesn’t cover things like stammers/stutters and other impairments in this category. Which is a big omission.

It is in this context that PAS 901:2025 Vocal accessibility in system design. Code of practice was published by the British Standards Institute, in 2025. This post covers the background to the Code of Practice.

Video: Vocal Accessibility Part 1, on Vimeo.

Where did it come from?

Between 2018 and 2025, the Helen Hamlyn Centre for Design, at the Royal College of Art and Tata Consultancy Services undertook research to, in their words, “better understand vocal interactions with technology and develop a set of accessibility guidelines for designers and technologists.”

Tata and the Helen Hamlyn Centre became the lead sponsors of PAS 90:2025, working with the other partners — Axelrod Access for All, Google, the Indian Institute of Technology, Microsoft, Polyloop (now, Whitelabel.ai), Special Projects, University College London and University of York.

Who benefits?

PAS 901:2025 is designed to benefit many groups, including:

Disabled and neurodivergent people
Older users
People with developmental speech disfluency, developmental verbal dyspraxia, cluttering, stammers/ stutters
Tourette’s, Tourettism, vocal tics
People with acquired speech disfluency, aphasia, verbal apraxia, dysarthria, people who have had strokes, Parkinson’s, cerebral palsy, motor neurone disease(s), brain injuries,
Non-verbal
Non-native speakers

Technologies covered

That is the who. And, here is an incomplete list of the types of software and hardware that are covered:

Automated telephony systems,
Smart speakers,
Internet (Web) of Things – for example, smart connected appliances,
Speech-enabled chat-bots,
Speech recognition software on desktop, tablet and mobile,
- Includes operating system, assistive technologies ….
- Speech-enabled (mobile) apps.
Voice navigation systems, for example in cars,
… Anything else?

These technologies are covered both in the context of design and production by vendors, and procurement and deployment by third-parties.

This concludes our introduction to PAS 901:2025. In part 2, we will take a look in some depth at what the Code of Practice contains.

The Enchanted Pig

Wed, 20 Aug 2025 20:00:00 +0000

Bedfordshire Youth Opera

proudly presents

The Enchanted Pig

Wednesday 27 — Saturday 30 August at 7:30pm
Thursday 28th — relaxed performance
Thursday 28th at 4pm — little piggies’ party
University of Bedfordshire Theatre, Polhill Avenue, Bedford, MK41 9EA (map).

Tickets

Tickets: £25 / £13 (via TicketTailor.com)

Dialog-position

Sun, 13 Apr 2025 19:00:00 +0000

In this video, I discuss the challenges we face with keyboard accessibility in modal dialogs and introduce a new dialog-position package on NPM, that exposes a stylesheet to easily position native HTML <dialog> elements.

Loom: Enhancing Modal Dialog Accessibility

dialog-position demo

Out with it: How stuttering helped me find my voice

Sun, 28 Jan 2024 19:00:00 +0000

I’ve just finished reading Out with it: How stuttering helped me find my voice, by Katherine Preston. I found it moving and a great read!

It’s not a new book, but it has aged well, and feels relevant to me today.

Out with it is a memoir, that starts in the author’s childhood, growing up in suburban England, and ends after she completes a road trip across the United States, interviewing people who stammer/stutter, speech therapists and researchers.

Katherine explores her childhood and teenage years, searching for an elusive “cure”. During the second part of the book she gradually comes to accept her stutter and finds a way to live with it.

She meets lots of famous and everyday people along the way, and quotes liberally from her interviews.

In the author’s journey I see echoes of my own. My formative experience was group speech therapy at the age of 20, at the old Queen Elizabeth Hospital, Birmingham. The speech therapy was based on the work of Van Riper, Sheehan and others. It used a 4-step process:

Identification,
Open and voluntary stuttering,
Desensitization,
Acceptance.

Therapy was tough and lasted an intense 5 months, but with the support of the other young people in the group, ultimately successful in allowing me to accept and reduce my avoidance of stammering.

I heartily recommend Katherine’s book!

My Custom Elements

Sun, 19 Feb 2023 12:30:00 +0000

For a while I’ve been working on a suite of custom elements. Custom elements are a standards-based way to extend HTML. A <custom-element> could encapsulate a user-interface component or custom form-field like <my-star-rating>, it could purely encapsulate a behaviour like <my-keyboard-control>. The possibilities are endless!

So I’m getting my ass in gear, and explaining the what and the why …

Why?

A colleague asked me “why?” recently, which got me thinking … I’m motivated by a few different factors. In no particular order:

Curiosity … wanting to play and experiment,
Develop things useful for other projects, for example this blog!
To push boundaries,
Explore the possibilities and limitations, for example in relation to accessibility,
Tied in with other experiments, for example, relating to readable fonts.

Where?

If you’re impatient to get started:

What?

You’ve got the experimental — <my-star-rating>, <my-font>, <my-page>,
Things that are useful on my blog — <my-analytics>, <my-busy-spinner>, <my-feed>, <my-font>, <my-gaad-widget>, <my-skip-link>,
Some are overtly accessibility-focussed elements — <my-skip-link> and <my-keyboard-control>,

And, some are just … because — <my-map> anyone?

See the Pen my-map demo #2.

How?

To load all elements, purely in the HTML page, simply:

<my-skip-link></my-skip-link>

<my-options template-host="github.io"></my-options>

<script src="https://nfreear.github.io/elements/index.js" type="module"></script>

Or to import just a handful of elements:

import customImport from 'https://nfreear.github.io/elements/custom.js';

await customImport('my-skip-link, my-map');

Then:

<my-skip-link></my-skip-link>

<my-map
  lat="51.505"
  long="-0.09"
  zoom="13"
  geojson="path/to/landmarks.json"
>A map showing some landmarks in London, UK</my-map>

The code uses ES modules throughout, with semistandard linting. It should play well with build tools and other custom element libraries.

What’s next?

It’s high time I published another version on Npmjs.com. Tidying and tweaking. I don’t have big plans at present — I’d love to hear what you think.

I’m @ndf@mastodon.social.

Review: Lainey Feingold: Accessibility Convincing - WebAIM

Tue, 03 Jan 2023 19:30:00 +0000

I had some spare time today, so watched Lainey Feingold: Accessibility Convincing. Web Accessibility In Mind Conference – V. good talk, which I think counts towards CAECs for IAAP.

Lot’s of useful points she made. “#2 Do understand who you’re convincing and speak their language” – Lainey made the point, for example, pharmacists care about safety, so access(ibility) is safety - Braille labels on medicine, or side-effects published in an accessible format on a website are about patients/customers not being made sick or worse. Access(ibility) is security for Web developers – not having to share your password with someone just to log into a site, etc. Accessibility is privacy/security for bankers.

Lainey also said, “DO talk about the law as a civil right” and DO use ethics … and DO use kindness – which I thought was particularly interesting :wink:

Also some good questions at the end, one of which led her to mention the Procure Access initiative led by Disability:IN. Some big names have signed up to the statement – Microsoft, Google, JP Morgan, Salesforce … Twitter (interesting!)

I hope this is useful! :+1::skin-tone-2:

(Oh, and Techshare Pro / Barclays got a mention!)

Speech-devices and stammering

Sat, 08 May 2021 08:30:00 +0000

Do you stammer/stutter? I do.

While working on the ADMINS Chat-bot project last year, we came to a significant realisation.

The speech recognizer used by default in Webchat (and many other speech user-interfaces) assume the first pause in your speech (even a small one) is the end of your utterance and they move on with the conversation. Now this may be acceptable if your responses consist of “yes“, “no“ and “continue“, or you have typical speech patterns.

However, as soon as you’re answering open-ended questions, or have a stammer/stutter or other dis-fluency, then it soon breaks down, and the Chat-bot cuts you off mid-response. I characterize that as impatient!

Our answer was to develop an alternative, adaptive speech recognizer, built on Microsoft’s cognitive speech SDK. This was configured with a longer timeout for the open-ended questions in our Chat-bot’s dialog, while recognizing and responding more quickly to the shorter closed responses like “yes“, “no“ and “move on“.

After some experimentation, we settled on a timeout of 1.75 seconds (a compromise between everyone’s needs), and the adaptive speech recognizer was used successfully during the main trial for ADMINS. Always at the back of my mind was the question — could the speech recognizer adapt to the speaker, not just to the conversation?

Since then, I’ve realised that most speech-devices, including smart speakers like Alexa, voice assistants like Siri and automated phone-systems are not well suited to those with a stammer/stutter or other non-typical speech.

What I sense is needed, is data on the attitudes of people who have dis-fluencies to speech-devices, and research into the effectiveness of potential adaptations. This could be used to drive change, potentially including through standards like the Web Content Accessibility Guidelines.

I’m working to put together a research project. I effectively mocked up a short survey on twitter, with interesting results!

Luckily I’m not the only one working in this space! Project Euphonia and Project Understood are important and ambitious projects to effect change. Researchers including Leigh Clark are doing valuable research.

If you’re interested in collaborating, please reach out to me on twitter or via The Open University.

See research papers on ORO, Microsoft and OU research news.

ADMINS project — update

Tue, 23 Feb 2021 16:30:00 +0000

After a busy, rewarding and challenging year, Paco launched the main trial for ADMINS on the 18th November 2020. It was closed on the 10th January 2021, with 134 student respondents completing all parts of the trial.

A key takeaway from the research was that respondents preferred the ADMINS Chat-bot they trialled over the existing online form, when disclosing their disabilities and needs to us. (Links to research papers to follow.)

Chetz Colwell undertook accessibility testing before our main trial, and I’ve followed up by contributing accessibility bug reports and fixes to the Microsoft WebChat Javascript library.

Below I’ve summarised some of our technical achievements and some challenges we faced.

Technical achievements

Richard developed a structured data-format to load the conversation into the Chat-bot. This gives us flexibility to customize the conversation-flow, without changing the code;

We developed …:

A custom “patient”, adaptive speech recognizer for the Chat-bot, built on MS Speech Cognitive Services (live-demoed!);
And, a [LUIS model][] to classify multiple disabilities and health conditions from a potentially long, multi-sentence disclosure by a student.

Challenges

Incomplete documentation; documentation only dealing with simpler use-cases; out-of-date documentation;
Issues encountered with speech-to-text accuracy when using low bandwidth phone calls (Paul)

…

Read more in various blog posts from early February 2021.

I’m very proud of what we achieved throughout 2019-2020, and the COVID crisis!

Thanks to :~ Tim, Kate, Paco, Wayne, Jo, Kevin, Peter, Rich, Paul and our consultant students.