CANAXESS web accessibility articles

Accessible pagination

2016-10-11T00:00:00Z

Pagination controls are the clickable numbered links found at the bottom of blocks of content which allows the user to load a next set of records. These are quite often one of the easier to identify accessibility failings for web content.

The links list within NVDA

The links list window within NVDA showing each link on the pagination control, as the links are viewed outside of the page they’re not understandable.

When the links are viewed out of context in the links list within JAWS and elements list in NVDA, if the links are numbered with no other identifying characteristics the user will not understand what each link does. Which will fail WCAG 2.0 Guideline 2.4.4 Link Purpose (In Context).

A common solution is to add hidden text to each link, this will not display the text to the screen but when the link is viewed in the links list the hidden text will be shown and give greater meaning to the original link text.

If the links are numbered sequentially, you could add the word ‘page’ in front of the link text styled with a hidden CSS technique, and because we’ve given each link more context, the links would now be accessible?

The first pagination link - page 1 - is highlighted

After adding the word ‘page’ to each numbered link, the text is becoming more understandable

Not quite, the links list dialog in JAWS sorts links on a page alphabetically. If all the links begin with the word ‘page’ a user cannot easily navigate to Page 11 without first navigating and hearing the previous 10 links which all start with the word ‘page’, has it really been made accessible?

WebAIM suggest placing the distinguishing information at the beginning of the link, instead of placing the word page at the front of the link followed by the number, place it after the number.

Implication 2: Place the distinguishing information of links at the beginning of a link. Don't put extra information first, For example, don't say "Link opens in a new window: Products." Instead, say "Products (opens in a new window)" (or something along those lines)

This will ensure when the links are viewed out of context they are sorted correctly and the user can navigate the links easier.

1 Page, 2 Page … sounds kind of grammatically incorrect doesn’t it? This can be fixed by adding an ordinal indicator (st, nd, rd, th) after the numbers and using a CSS hidden display technique and a little JQuery.

The first pagination link with the unique link text placed at the beginning

Ensuring the unique link information is first (the number) adding an ordinal indicator and placing the repeating text ‘page’ last

Visually nothing has changed on the screen, however when viewed out of context the links are grammatically correct and accessible.

How to protect your website from spam and be inclusive

2017-01-22T00:00:00Z

Captcha is the most effective way to stop spammers. However, captcha isn’t accessible and presents real challenges for people with disabilities. There are better approaches which offer similar levels of security and are more accessible and should be considered.

Captcha is a security feature found on websites to stop automated signups from spambots. A user is asked to type a collection of characters or numbers which are distorted to prove they are a real user wanting to sign up.

The problem with using captcha is that it isn’t accessible. The distorted text is very hard to see and the audio option is itself distorted. This makes it difficult to understand and this is usually combined with a user interface which has very poor keyboard support.

From a user experience perspective, why should users have to prove they’re human?

The challenge with Google reCaptcha and why you should avoid it

Google's familiar type the letters captcha

Google have made huge improvements with their recaptcha mechanism. A simple checkbox asks the user if they are human and when ticked allows the form to be submitted. This checkbox is announced by screen readers and shows up in the keyboard tab sequence.

Unfortunately, if Google’s recaptcha mechanism determines the user’s behaviour is unusual the accessible captcha reverts to the old style of requesting the user to identify images, or sketch an outline.

Google's invisible recaptcha challenge

It is not accessible. The vision impaired user cannot see the image they’re asked to interact with and the keyboard user cannot sketch around the image (if one is displayed).

Worse still, the audio alternative offered is not keyboard accessible and does not appear in the keyboard tab sequence.

How the strategy of layered security can help you

Fortunately, there are other techniques which can offer similar levels of security to stop bots abusing your systems and creating fraudulent accounts.

A technique which can be used is that of layered security – “defence in depth”. Layered security is a strategy of not relying upon one method to stop spammers but using a combination. If one of the layers is breached there are still others stopping the fraudulent activity.

Consider using all the following techniques.

1. Use a honeypot

One of the most popular methods is a honeypot. Spambots trawl forms and fill all the available fields with data and submit it automatically. We can use a form field hidden with CSS to render it invisible to the screen.

When the form is submitted, if this hidden form field is not blank consider that the form has been compromised by a bot and discard the forms input.

Think carefully how you implement it

The way the honeypot technique is implemented can alter its effectiveness. Use CSS to hide the form field, don’t use input controls of type hidden. Use a name for the hidden form field that is commonly found on contact or signup forms.

Consider the name “fax” for the hidden form field, it’s unlikely a fax number is used. Avoid the use of field names such as “honeypot” or similar as this can be easily ignored by the bots. You don’t want to inadvertently make it easy for the bots to ignore the honeypot.

Make sure to use the autocomplete attribute and set this to “off” to stop the browser prepopulating the field.

User Nick J on stackoverflow explains the technical details of a better honeypot implementation.

2. Form submission time

Calculate the time taken to submit the form. If the time was very short, for example, less than 5 seconds assume the form has been compromised and discard it.

User zaba on the interactivetools forum explains the technical detail with a PHP implementation.

3. Email verification

Send the user an email asking them to confirm their email address by clicking a time limited link. By requesting the user click a link in their email we assume the user is human, this approach works very well with an account creation process.

The techniques you should avoid

Other techniques of providing mathematical questions or relying on the user to type in words or phrases should be approached cautiously.

Both examples could be difficult to solve if the user has a cognitive impairment affecting their ability to solve equations, or if English is a second language.

More inclusive but a compromise has been made

These techniques aren’t foolproof. Given enough time and effort the techniques will be overcome (as will most captchas). The aim is to slow down the spambots enough that repeated attempts to signup become unsustainable for the spammers and they move to easier targets.

Test the effectiveness over a couple of months and if the approach is being overcome begin to tweak the layers.

In Summary

Current captchas aren’t accessible and present significant challenges for people with disabilities. Images can’t be adequately described, mouse only for some modes of operation and distorted audio all mean captcha shouldn’t even be considered.

The honeypot technique is a worthy replacement but it needs to be combined with other security techniques to be effective.

It needs continual monitoring and adjustment to remain effective. If you care about your users experience, replacing captcha with the layered security technique offers significant advantages.

5 simple accessibility fixes for your website

2017-03-11T00:00:00Z

I tend not to like giving out advice for easy accessibility fixes as I find it gives people a slightly unrealistic view of making their website accessible. However, there are 5 straight forward fixes you can start applying today which will begin to make a big difference and improve your websites accessibility.

1. Images missing a text alternative

All images need to have ALT attributes. The ALT attribute stands for “alternative text” and it’s a way to describe the image via text. But, and this is important, not all images require ALT text.

If an image needs to be described, and without a description a user won’t understand a part of your site, use concise ALT text. If the image is decorative and there is no meaning attached, the ALT text can be set to nothing.

2. Poorly labelled links

Every link should be understandable when read on its own. Screen readers can display all the links on a webpage in a single list, the problem however, is if those links are labelled in an unclear way, it is very difficult and in some cases impossible to understand where each link leads.

A good way to make sure your links are labelled correctly is to read the link back to yourself, always make sure each link is understandable on its own. Don’t use links which have the text “click here” or “read more” as they’re difficult to understand.

3. Form controls with no labels

All the controls on your forms must have labels attached to them. Screen readers do a great job of announcing form controls, but unless there is a label with has been associated to the control, the screen reader will only ever announce the type of control, not what the label is asking.

There are quite a few ways to associate labels to form controls, but one of the best is using the FOR attribute on the label.

4. Incorrectly structured headings

Creating a good web page structure is really important for accessibility. Many users may not be able to see the webpage and how everything is laid out on screen, they instead rely on the document structure to understand it.

Screen readers can navigate a webpage via the headings, these headings serve as convenient hints to how the page is laid out. Always make sure your webpages have one H1 heading element, followed by H2, H3 and H4 headings all in a correct sequence.

5. Test everything with a keyboard

People who are vision impaired use the keyboard for navigation and interacting with their screen reader. Some users may have problems with fine motor skills and may experience tremors which make using a mouse impossible, which is why making your website keyboard accessible is vital.

When you use native HTML elements on your site you get keyboard support as a standard behaviour, but when you begin adding custom controls, dropdown menus, widgets and graphs, that keyboard support now needs to be built in. Having custom controls and complex functionality isn’t bad, but you need to go that step further to ensure its keyboard accessible.

It’s easy to get overwhelmed with web accessibility and deciding how to start making your website accessible.

These 5 issues are straightforward to fix, require a minimal amount of effort and will significantly improve your website. Web accessibility isn’t always straightforward, but you can make progress on your website with these easy fixes and quick wins.

How to check your website is inclusive and accessible

2017-04-02T00:00:00Z

A web accessibility audit report is a really good first step in seeing if your web content is accessible. However, as many companies offer audit reports, it isn’t always easy to know what you should be looking for and what you should expect to see in a finished report.

What does an audit report offer?

An accessibility report will explain how accessible your website is. The report will assess your web content against the Web Content Accessibility Guidelines version 2.0 (WCAG 2.0). These are international best practice standards in web accessibility.

There are three levels of rating conformance in the standard, single A, double A and triple A. As you progress up the rating scale, triple A conformance is more accessible than a double A, which is more accessible than a single A.

Generally, double A conformance is the rating which web content is assessed against. Double A offers a good compromise between accessible design whilst not reducing functionality. Double A conformance also means all single A conformance must be checked as well.

How to decide on the pages to test

Depending on the size and complexity of your website it’s not always practical to test every page. A representative sample of pages is decided upon and this will become the pages which are tested. It’s a good idea to identify a wide cross section of pages with different levels of functionality throughout. You may have your regular pages, pages with interactivity and even pages with form elements.

What does the testing process involve?

The pages are then tested using a mixture of automated and manual testing strategies. Automated tests identify those easy to find problems, the “low hanging fruit”. These may be colour contrast problems or images missing ALT text. You can begin to achieve several quick accessibility wins by fixing these problems.

Manual testing though is where an audit report really comes into its own. An experienced reviewer will step through the website with a range of tools and assistive technologies, identifying sections which are inaccessible and will cause problems.

These are then recorded, and solutions and recommendations are provided which fix the issue. It may be as simple as adding a missing tag, or it could be something more complex. A good audit report will identify the problem, describe why it is a problem and present a solution which is practical to put in place.

Steps to help you choose a web accessibility company

Not all companies provide web accessibility services to the same standard and there can be a large variance in quality. These are some questions to ask:

Does the company do more than web accessibility? – If so they may have a broad range of skills but these skills may not be in-depth.
Is their own website accessible? – If a company provides web accessibility services or promote creating accessible websites, run their own website address through the W3C markup validator. This checks the code of the site. The more errors identified the stronger the likelihood of them not really understanding accessibility.
Do they offer a certification or statement of conformance when they have reviewed your site? – Such statements are meaningless. The conformance claim is not recognised by anyone else and is only as good as the reviewer.
Do they offer quick fix plugins? – Quick fix accessibility via plugins work for easy to find problems but won’t work for problems which are more challenging. If the site changes the plugin may need to be altered as well, using a plugin gives a false sense of compliance.

There are many reputable web accessibility companies. If you follow the above points they will help you make a more informed decision on who to consider, what to ask and who to avoid.

Accessibility shims as a stop-gap

2017-06-23T00:00:00Z

It’s not always easy to fix accessibility on the client side. The platform may already be chosen, or there’s an extra layer between you and the HTML code, and in these circumstances a shim can be used.

What is a shim?

An accessibility shim is jQuery code which is run after the page has loaded. It alters the document object model and the changes are picked up by the screen reader. By using jQuery selectors, we can target page elements that we want to change or alter, it sounds like a great technique but there are significant downsides.

The problem is the shim is run every time a page is loaded. If the shim is many lines in length it can begin to degrade page performance. It’s also very specific to the page content, if the page has altered significantly, then the shim no longer works.

There may be situations where you only want accessibility features introduced on a specific page. For example, using it on a contact us page and nowhere else, and localising shims to particular pages can be tricky. We would identify any unique content per page – this could be a heading or control, and then test to see if the element exists, if it returns true the shim is run.

$(function() {
if($('#selector').length)
{
//it exists add extra content or attributes
}
});

An interim fix

Accessibility shims are a hack, plain and simple. They attempt to retrofit accessibility features onto existing content. Retrofitting accessibility using shims isn’t great, but it does serve a purpose and should be considered a part of an accessibility solution, if a site is moving towards accessibility this is an ‘ok’ approach as a temporary fix. The underlying platform may have been procured without considering accessibility requirements or former developers may have added features that aren’t accessible and you’re now stuck with challenging web content.

We occasionally use shims to retrofit accessibility onto an existing system, but we always make the organisations we work with aware it’s not great, it’s a temporary fix and is liable to break if a significant portion of the web content is rewritten. For us, using shims is the exception, not the rule, we consider them a valuable addition to the accessibility toolkit when it’s not always possible to work with the HTML code direct.

Do you really care about accessibility? Stop box ticking!

2017-09-12T00:00:00Z

We need to think about accessibility as not only ensuring web content is accessible but making sure that a culture of accessibility permeates through an entire organisation.

A culture of accessibility will mean the online services and experiences we create are truly accessible and usable.

Accessibility is not just a technology problem; it’s a service delivery problem which touches many parts of an organisation. You create online services according to the accessibility guidelines, you check the content for its accessibility, and then you sit back and think job done?

If we just think about accessibility as a technology problem, then we’re just looking for ways to make sure that we’re compliant, we’ve achieved some subjective rating against a standard. Which in theory is great, but web accessibility is not always so straightforward.

When we’re creating online experiences, we need to make sure that everything produced is accessible, but by solely focusing on the end experience for the public, we are potentially hindering our efforts in other areas. Take for example procurement.

Considering accessibility in procurement

Procuring software is where accessibility requirements must be added in from the start. If we’re purchasing a content management system or a development tool we don’t want any content produced by that tool to be inaccessible.

Buying accessible software will mean our future accessibility efforts will be easier as the product already has that support provided.

Push your technology vendors to be as specific and honest as Drupal over its accessibility compliance

However, asking if the product is accessible leaves us at the mercy of the vendors. It’s in their best interest to put a positive spin on their product. When we ask if their product is accessible, the provider will typically answer yes, even if the accessibility is so narrowly defined to be practically unusable.

Make sure vendors prove their software is accessible. Don’t accept what they say as truthful and accurate.

Rephrasing the question can get a more definitive response, ask, “has your product been tested for compliance against WCAG 2.0“.

We can go further still and ask whether their product is independently audited for web accessibility and can we view the report. Put the responsibility on the vendor to prove they understand what is required, don’t accept what they say as truthful and accurate.

Before purchasing anything, organisations will need to do their due diligence that the software to be procured is fit for purpose.

Potential procurements undergo security checking, and stability checking so why not include accessibility checking? Run a few online checking tools over it, ask for test accounts to be set up and if possible get assistive technology users to see if the claims they make are truthful.

This will allow you to focus your energies on other areas, like getting your developers up to speed.

Training developers in accessibility

Training developers is where significant improvements can be made, after all, they’re the ones creating the online services. It’s important to know that accessibility guidelines are difficult to understand and have a lot of confusing statements – for instance, the WCAG 2.0 guideline on colour contrast doesn’t read particularly well.

The WCAG 2 guideline for colour contrast can be difficult to interpret

Developers have too much work to do already, and unfortunately, web accessibility is a non-core skill for many. A skill that needs to be understood.

You can’t expect your developers to fully understand any accessibility specification and be confidently able to apply it. It takes time and effort to understand a specification and its nuances entirely. Look at ways in which you can make it easier for them to build in accessibility.

I believe that people do not want to make average online experiences or ones that are deliberately difficult to use, but they often have competing priorities and time frames.

That’s why making it easier to build in accessibility support is so crucial. Can you introduce easy checklists and procedures that developers can follow while developing? Procedures that can become part of their skill set.

Look at breaking down the accessibility compliance into easy tasks which developers can perform in the context of their everyday work. For example, when they create a component they check that it’s keyboard accessible and has sufficient colour contrast.

Some accessibility techniques are as easy as including extra attributes or using the HTML elements in a way which the specification intended. That quickly fixes some of the more obvious accessibility problems.

Build empathy and understanding with the developers by humanising their work. Emphasise the fact that their work has an enormous positive benefit for people who rely on the support that comes with well-built tools.

YouTube has great videos of assistive technology users navigating websites that developers have failed to build correctly. These can serve as excellent examples of what not to do. By making it relatable, people can begin putting a face to why accessibility is important.

Make it easy for your developers to source accessible components internally between teams, and make it straight forward to apply.

Style guides and reusable pattern libraries can help as well, don’t go reinventing the wheel unless necessary.

Australian Government's Design System

The Australian Government's design system has many repeatable patterns which has accessibility built in

If you have a component or design pattern that you have proved works, use that. Make it easy for your developers to source accessible elements internally between teams, and make it straightforward to apply

The impact of security on accessibility

Security is an often-overlooked area of web accessibility, but it can undo all your hard work. Many large organisations will have IT security policies for securing web based systems, one of the most popular methods is with CAPTCHA.

Googles ReCaptcha defaulting to displaying the inaccessible choose a number variant

These terrible obscured text and image challenges ask the person to confirm their “humanness” by completing a puzzle or deciphering the text.

Captchas are a pain for any user and a real barrier if they have an impairment. Understanding the text, deciphering an image, interacting with a keyboard are all challenges if the user has a cognitive, vision or mobility impairment.

Asking a user to confirm if they’re human before they can interact with your service, that’s a really lousy user experience full-stop.

The technique may be good for security, but it’s terrible for accessibility, and asking a user to confirm if they’re human before they can interact with your service, that’s a lousy user experience full-stop.

You can’t confidently say you have an accessible website if you use captcha. Current captcha implementations are not accessible

Google now promote an invisible captcha, which isn’t shown at all, great stuff, but what’s the catch? It will revert to the image challenge if it detects erratic user behaviour. As you can’t be 100% certain of your users never seeing that problem, you can’t confidently say you have an accessible website if you use captcha. Current captcha implementations are just not accessible.

Instead of captcha consider alternative methods. Combine multiple security measures, including checking how long it takes for a form to be posted, a hidden form field that attracts bots and email verification. If one method is compromised, you have fallback options of two more.

However, a pragmatic approach to security must be taken as well. There may be instances where captcha is used, and you can’t change the outcome.

In those instances, build up a support system around it, so if a user cannot use the captcha, they can contact someone within the organisation who can verify them another way, it’s not a great outcome, but it will help.

Motivating management and leadership

To have a long-lasting culture of accessibility, it needs significant understanding and downward push from management. In big, public facing organisations, it’s pretty straight forward to get buy in from management.

The benefits of accessibility

Emphasising the benefits of a good user experience and it’s increase in conversion are significant motivators which result in affirmative action. Also, don’t forget the law is an added motivator, government bodies in particular, must provide accessible web content.

But what do you do when there is significant indifference and a lack of understanding about the benefits?

Make the accessibility of an online service tangible, describe it in terms which will make different groups of people understand and relate to it.

Look for ways which will make people take notice. For example, can you reframe accessibility into one of building a better user experience, which will equal more customers? Can you demonstrate that completion rates of product purchasing workflows increase due to the ease of use?

Make the accessibility of an online service tangible, describe it in terms which will make different groups of people understand and relate to it. It’s a sad fact that sometimes making something accessible because it will help people isn’t as strong a motivator as it should be.

Can you find the business case for emphasising accessibility, can you sneak accessibility into the design?

The dangers of ignoring accessibility

The threat of legal action is another significant lever to pull. If your attempt to highlight the positive aspects have failed, the risk of legal action can be what makes people take notice. If the organisation is in danger of being sued, this can often be the final straw to prompt change internally.

A good example is a recent case in Australia concerning a vision impaired woman, who had difficulties over many months of using a supermarkets online ordering.

Gisele Mesnage outside Coles supermarket

She attempted to contact them many times, and the updates the supermarket put in place didn’t work. Reluctantly she took the case to the Australian Human Rights commission where they attempted to mediate with both parties and find an acceptable outcome.

When that too failed, she reluctantly took them to court for breaching the Australian disability discrimination act.

That resulted in the supermarket settling out of court and fixing their website and online ordering. If they had implemented accessible features initially and listened to customer feedback, a costly court case and bad PR could have been avoided.

Appoint an accessibility champion

Designate an accessibility champion in your organisation, a person who’s unafraid to mention when accessibility isn’t the best it can be, and who can educate and advocate for building inclusive experiences, and who reports directly to the senior management.

Accessibility is more than a compliance exercise

You see, accessibility is more than just completing a web accessibility audit once an online service is ready for a production release. If we just think of it as a technology problem, then we’ll always limit our efforts to performing an accessibility audit once an online service is ready for a release, which is a compliance exercise.

Any issues found will go onto a defect list ready to fix on the next update. But retrofitting accessibility never works, at best it’s a sticking plaster which makes something a little more accessible. Instead, build it in at the start, think of accessibility at every stage.

Web accessibility is as much about managing people’s attitudes, perceptions and motivations than it is about correctly coding a website.

I like the message from Mike Paciello of the Paciello Group when discussing web accessibility; emphasise the carrot and not the stick. Treat accessibility as a creative challenge, a challenge of building a better digital product which your users will enjoy.

Use diplomacy to get the accessibility message across, use posters, stickers, presentations. Use multiple approaches and multiple methods to have people understand that it is important.

The UK Government have provided a great set of posters to encourage people to think about accessibility

Both the UK Government and Barclays have produced a range of accessibility posters, even us at CANAXESS provide free information cards and stickers; the support is out there you just need to use it.

Web accessibility is as much about managing people’s attitudes, perceptions and motivations than it is about correctly coding a website.

References

Blog post originally published in Boagworld 12th September 2017 Do you really care about accessibility? Stop box ticking!

How to make chatbots accessible

2017-12-17T00:00:00Z

Chatbots can be a really great way to solve a variety of business needs. Users can have any of their questions answered or can be guided to finding information they need. However, coding chatbots correctly to ensure they’re easy to use with assistive technology, or via the keyboard, can be a real challenge.

The hard work creating an accessible website can be quickly impacted by using a chatbot with poor accessibility and in the worst case no accessibility. By learning the concepts in this post, you’ll become equipped to design a bot that aligns with best practice accessibility support and ensures you’re reaching all users regardless of their individual challenges.

Choose the best platform

Many vendors now offer chatbots, and each have varying levels of customisation. When choosing, look for a product which allows a custom user interface to be created with HTML and CSS. Having full control over any frontend code will mean you’re able to deliver the greatest level of accessibility support.

Provide skip links

The accepted location of chatbots tends to favour the lower right of the screen, and this presents difficulties for keyboard users. If there are many links on the page, the bot may only be reachable after tabbing through many in-between links first. These in between links can be avoided by allowing a user to navigate straight to the chatbot when a skip link is provided at the top of the page,

The skip link is an in-page anchor which uses the ID of the HTML element containing the bot. When the link is clicked, screen focus is moved to the bot’s container.

<a href="#chatbot">Skip to Chatbot</a>

Ability to read the transcript

Being able to read all the previous messages in the conversation is crucial for a user to understand what has been said and by whom. However, ordinary DIV elements (what we use to display each conversation) are not available in the keyboard tab sequence. We can overcome this by adding the tabindex attribute onto each text conversation block allowing a user to tab through the conversation history.

<div tabindex="0">

Identifying who said what

The aria-label attribute on each conversation block provides a convenient way to identify who has said which part of the conversation, was it the bot or the user. The aria-label attribute allows the text to be announced through the assistive technology. It’s helpful to understand that the aria-label text will only be announced when the user is tabbing through the conversation history.

<div tabindex="0" aria-label="The bot said">
How likely are you to recommend this service?
</div>

Handling dynamic content

Updating and changing content must have an aria attribute added to allow dynamic changes to be announced audibly by assistive technology. Each conversation block should be a contained within one parent container, and that container has the aria-live attribute with the value polite.

<div id="text_body" aria-live="polite">
Reply from the bot/user
</div> $('#text_body').append(~user/bot reply~);

Whenever the conversation display updates, the assistive technology will only announce the new content. By using it in this way, only the most recent response is announced, not the whole conversation. And importantly, the polite value will only announce content when the user is idle, to not to become a distraction, or override other more important screen reader notifications.

Rich media replies

Many bot platforms can send a variety of message formats, not just text. Although text content is the most straight-forward to make accessible, there may be business needs which require richer visual replies and this non-text content is an added challenge to make accessible.

As the complexity of the bot’s communications increases to include more than just text, so too does the effort required to make the replies accessible.

An example of a richmedia card from the Microsoft Azure chatbot

We’ve been testing the Microsoft bot framework which allows a bot to reply in ‘cards’ which can have rich media including images and buttons to allow the user to interact in ways other than typing. Our testing on this platform has identified approaches which will make these activity cards accessible, but it requires significant front-end parsing of the bot’s communication with Javascript.

Be aware of quick accessibility fixes. As the complexity of the bot’s communications increases to include more than just text, so too does the effort required to make the replies accessible.

Other factors which influence bot accessibility

Is a relative font size used to allow onscreen text to resize?
Is a sufficient colour contrast in use to make it easier to identify replies?
Is the bot being displayed the best way when viewed on other devices?
Is the bot’s language tailored to the audience?

None of these questions directly relate to factors which make the bot inaccessible, but they are extra techniques which when considered will make the user experience better. A great bot experience has extra support in place which provides a seamless experience regardless of any users’ challenges.

The process of designing an accessible bot is the same as designing an accessible web app or website. Use correct semantic HTML to provide a solid skeleton of accessibility support and choose platforms and products which allow greater customisation.

Whenever you are unsure that your providing accessibility support try using the bot just with the keyboard, if you’re able to still control the bot with no mouse input then you’re designing it right.

Just what is the problem with CAPTCHA?

2018-09-03T00:00:00Z

I've spoken previously how using CAPTCHA is a really bad way of securing your website because it's inaccessible, but for people who don’t work in web accessibility it's difficult to appreciate the problems that makes it inaccessible when you begin using it on a website.

Recap: What is CAPTCHA?

CAPTCHA are the challenges you often see on websites and online services. Users are asked to prove they're human by solving visual puzzles, identifying a collection of images or letters and numbers which are obscured by lines are other distortions.

Googles' ReCaptcha asking the user to select all images with an oranges

Why use it?

It’s a way to prevent bad people using automated tools to break into your website to create fake accounts, spam users and generally become an annoyance.

The theory is humans excel at the task of correctly identifying distorted text unlike computers.

By having a mechanism is place which is only solvable by people, it reduces the likelihood of your online service being compromised.

Many of the popular captchas are free to use, fully automated and are straight forward to get up and running.

How CAPTCHA works

Before a user can perform an action or complete a task a CAPTCHA challenge is presented. When the challenge is completed successfully (for example choosing every image that is a street sign) the user is confirmed as being human and they’re allowed to continue performing their task.

CAPTCHA aren’t accessible

The problem is that CAPTCHA aren’t accessible. It can be difficult to use via the keyboard and impossible to use if you're vision impaired.

The audio is hard to listen to – and understand it, as its often combined with a lot of static or extra noise and in the case of comparing images, users with cognitive impairments can have extreme difficulties.

Even users without impairments can have difficulty trying to decipher the cryptic text. Google acknowledge their reCaptcha text is so complicated that even humans only solve it 87% of the time.

There are alternatives to inaccessible and difficult CAPTCHA. One is Google's invisible reCaptcha, promising users just need to tick a box to indicate they're not a robot.

The new CAPTCHA where the user only needs to confirm they're not a robot

It uses a range of criteria to determine whether an action is being submitted by a human. This can include watching's the user's behaviour on the page – do they linger, do they scroll the page. Does the user have a Google account, and advanced risk analysis such as where in the world the user is originating.

So, problem solved?

Unfortunately, no the problem isn’t solved. Whilst all the promise sounds great ensuring a user would never see a CAPTCHA challenge because of some sophisticated backend technology. On the Google website is this statement:

Sometimes we need some extra info from you to make sure you’re human and not a robot, so we ask you to solve a challenge

How confident are you using it?

If you're unable to say for certain that users will never see a CAPTCHA displayed, which has significant accessibility challenges, is it wise to continue using it?

We all put a lot of time and effort into making the online services we create accessible, if you're in Government both the UK and Australian governments have statements describing government websites must be accessible up to Web Content Accessibility Guidelines (WCAG) 2.0 AA.

All online services must be accessible, but all begins to be undermined when we secure the service with a CAPTCHA.

CAPTCHA has also been compromised

CAPTCHA solving is being outsourced by spammers in low cost countries where they use real people to churn through large numbers of distorted text for a fraction of a cent.

Bot farm advertising detailing the cost

Prices are very low from 50c per 1000 CAPTCHA and API’s exist which allow the service to be used easily in many modern development environments. It doesn’t take much effort to get up and running, and it's incredibly cheap.

Background reading

Australian security researcher Troy Hunt has a great bit of background reading about breaking CAPTCHA.

Only humans can break the code and complete these signup processes, right? But what if we could automate the humans; I mean what if we could take CAPTCHAs and solve them at such a rate that these registration processes could be easily automated? Well it turns out you can and it will only cost you a couple of bucks.

And recently a Californian artificial intelligence company funded by Amazon and Facebook cofounders have developed AI that can outsmart Captcha. In 2013 it announced it had cracked text based captchas used by Google, Yahoo and PayPal with a 90% accuracy.

We're not seeing attacks on Captcha at the moment, but within three or four months, whatever the researchers have developed will become mainstream, so Captcha's days are numbered,

Since then it's able to pass Googles reCaptchas 66.6% of the time. The creators say the very nature of big data analysis and machine learning is that if you give it enough data to play with it will eventually work out most things.

Other alternatives

There are a several alternatives that should be considered:

We can check the time taken to submit a form, if the form is submitted in a very short length of time we can consider the form to have been submitted by a bot and ignore the input.
We can use the honeypot principle to tempt bots to identify themselves by filling in a hidden form field. A form field is hidden with CSS, as people can't see it, this always remains empty. If this is filled when the form is submitted, we assume it's been submitted by a bot and ignore its input.
And we can ask a user to click a link from an email they've received to confirm they're a real user and not a bot.

Defence in depth

All of these are reasonable steps, but we can go further and adopt the principle of layered security or defence in depth. A strategy combining several approaches, if one approach is compromised there are several other techniques to rely on.

The more security measures which are in place can mean the more difficult it will be for bots to get though.

Number CAPTCHA problem

Other techniques for CAPTCHA alternatives often recommend the adding together of two numbers.

Simple mathematical question asking the user to add two simple numbers together

However, bots are cleverly written already, if they're able to interact with a page and submit a form then I don’t believe working out simple mathematics poses much of a problem.

Word CAPTCHA problem

Another method is a question and answer where a user is asked a question and they have to provide the correct answer.

Unfortunately, you'd have to have 100's of question and answer combinations to ensure the questions don’t repeat, it's limited to an English-speaking audience and if users have English as a second language the question may not be easily understood.

Not a good look

Besides the perception of providing a question and answer on a government website or large organisation isn’t great and it can undermine the confidence of the person using the site.

The problem

CAPTCHA is a frontend solution to a backend problem, it’s a programmer's way to ensure an online system is protected and it generally works. It's been attacked and compromised in limited ways, but it currently is an effective way to secure your system.

Although as I discussed earlier with CAPTCHA farms and AI it can only be a matter of time before CAPTCHA is being broken 100% of the time.

Although CAPTCHA is pretty effective currently, that effectiveness comes with a significant disadvantage and that's stopping users who use a screen reader or other assistive technology from using your website.

It’s a poor user experience and the user shouldn’t be burdened with having to prove they're human.

Most viable alternatives

Some of the most viable alternatives as I see it:

SMS text message
Asking the user to self-declare on any signup screen
Staff assistance if the user is having problems
Robust application monitoring

SMS text message

Whenever a user is performing a critical task such as creating an account, or posting to a forum, text a code to their phone. Two factor authentication has worked for banks, it's in use with the Australian Government with MyGov, and both Hotmail and Google use it extensively.

Two factor authentication with a code sent by SMS to the phone

However, it can incur significant costs if all users have been moved to receiving a text message, so perhaps be discerning and only offer that method to users who would benefit the most.

Self declaration

We could identify users who require greater support via asking them to self-declare, if they do don’t show CAPTCHA and instead provide the text message option.

Asking the user to self declare their disability

However not everyone is willing to self-declare and rightly so to, it feels discriminatory and why should a user have to indicate they're different and require special treatment?

Staff assistance

Provide a method for a user to contact a real support person who can guide them through any signup process and avoid having to use CAPTCHA.

Provide a link before the start of the CAPTCHA for users to contact you if they're experiencing problems solving the challenge.

"I am experiencing difficulties" link above the regular CAPTCHA

Providing an alternate way to validate a user

It's not great but it can be a stop gap approach whilst a long-term strategy is identified for transitioning from CAPTCHA to a more suitable method.

Application monitoring

Consider application monitoring as well, if you notice an unusual number of accounts being created or many requests coming from the same IP address, investigate and if necessary block.

The trade off

Security and accessibility can co-exist together, except when CAPTCHA is used. If you use CAPTCHA to secure your website, it will decrease the accessibility of it.

Summary

Current CAPTCHA implementations are not accessible and have been broken. They cannot be relied upon to secure online government and large organisation online services when those services need to be available for all users regardless of impairments.

Vendors often say their CAPTCHA is accessible, but unless it's thoroughly tested by accessibility testing staff, and users with impairments and everyone agrees that it presents no challenges, don’t trust the vendor claims.

Parts may be accessible but it’s not good enough the whole component needs to be accessible. Your users, our users, deserve a better experience than what they currently have with CAPTCHA.

Put users first

The Australian Government's Digital Service Standard advocates putting the user first, what user need is there for using CAPTCHA?

It’s a business need, and not a user need. Push back against the security requirement which says CAPTCHA must be used, there are other security techniques which are more inclusive and have similar if not identical levels of protection.

If you use CAPTCHA it will make your online service inaccessible.

Headings the right way

2018-10-07T00:00:00Z

It's easy to misuse headings when structuring a page. Incorrectly adding headings makes it's difficult for screen reader users to understand the page structure. Headings function as the document hierarchy - the hidden skeleton of a webpage.

This makes it easier for screen reader users to understand the page.

In the early days of web design, heading styles were used based on how they looked, not their structure. Instead of altering heading styles with CSS to make each level different. A smaller heading depth would instead be chosen.

Although HTML is very forgiving this isn’t correct, and it's just plain bad.

Use a good structure

Assistive technology announces the level of a heading for users to understand. This helps users to create a mental model of the content. If we don’t nest headings based on their depth it can be difficult to understand the content.

It may look correct with each heading having its own styling. But if you're unable to see the effect visually you instead rely on the heading elements themselves.

The benefits of heading level

An assistive technology user can understand the page because of the semantic elements used. Using the correct heading levels provides a solid skeleton core to the webpage. This makes the document hierarchy easier to understand.

Follow the principle to lay out headings when writing a document in a word processor. Begin with a master heading level and set this as a H1, this is only ever used once in the page.

This serves as the documents main heading, the one which all other headings sit under.

Follow this by using one or more H2 headings, which are child elements to the master H1 heading. Followed by one or more H3 headings, H4 heading and H5 headings.

The child heading element is part of the preceding parent heading element. This establishes a clear logical relationship.

<h1>Master heading</h1>
<h2>Level 2 Subheading (child of master heading)</h2>
<h3>Level 3 subheading (child of level 2 subheading)</h3>
<h4>Level 4 subheading (child of level 3 subheading)</h4>

The outlining algorithm problem

The HTML5 specification allows H1 heading elements throughout the page within different regions. The main page could have a H1, an aside region could have a H1, and a footer could have a H1.

The theory is many H1 heading elements can be used as they're defined in different regions.

However, no browser or assistive technology has successfully implemented the document outlining algorithm. Whilst the technique is technically correct it isn't implemented and cannot be relied upon.

There are currently no known native implementations of the outline algorithm in graphical browsers or assistive technology user agents, although the algorithm is implemented in other software such as conformance checkers and browser extensions. Therefore, the outline algorithm cannot be relied upon to convey document structure to users. Authors should use heading rank (h1-h6) to convey document structure. HTML 5.2 W3C Recommendation

Always ensure your heading depths follow the pattern of one H1 heading, followed by one or more H2, H3 and H4 heading levels. All heading levels should follow sequentially, and don't skip levels.

Use as many headings as you need

Even though there are several depths of headings you don’t have to use them all. Some of your pages may only need a H1 heading level, or a H1 followed by two H2 heading levels and that’s ok too.

If you think some of your content may be too long, that’s a good indicator for adding another heading level to break it down.

Headings are not subtitles

Don’t use a lower heading level as a subtitle as this is wrong. A subtitle isn’t separate to the main heading item. It's only used to provide a more detailed description for the heading.

Therefore enclose it in the heading level and style accordingly. Unless new content is introduced, don’t use headings for subtitles.

<h2>This is a level 2 heading
<span class="subtitle">This is the subtitle for the heading</span>
</h2>

Everyone keeps getting this wrong. Subtitles are not headings! They don't introduce new sections of content! #bootstrap Heydon Pickering 24th May 2018 (Twitter)

Summary

Structure your page using sequential heading elements
Use as many headings as required
Don’t rely on the HTML5 heading outline as it isn’t implemented

You're wrong

2018-10-14T00:00:00Z

The greatest tool for us as accessibility professionals is diplomacy, the quiet art of stating your case and pushing just enough to encourage change but not so much to upset people and ruin professional relationships.

When checking the accessibility of a website its very easy to be critical, our very role is to be critical. It's to spot issues, identify barriers and mark according to a severity scale of how bad the issue is.

But often this ability to expertly identify barriers and problems can mean our message becomes lost. Moving from identifying and recording issues to encouraging development teams and business areas to fix those errors.

Be flexible

The web accessibility industry is filled with good people who become advocates for making sure digital services being created are inclusive.

We know when something isn’t working right, and we can spot the familiar catchcry of "accessibility is important to us", which is then followed by accessibility not being acted upon when we identify issues.

This, in turn can make us become more stubborn and adept at raising the accessibility flag at every opportunity. But is this helpful, or can it become counterproductive?

Become a diplomat

Being a diplomat is the hardest and most challenging part of the accessibility practitioner's toolkit.

Finding technical issues is easy. We use a variety of tools and techniques combined with a deep technical understanding to find problems.

But human emotions are hard, its difficult to understand people's motivations and get buy in with accessibility. Sure, it may be mandated in your organisation that accessibility is important.

But when there are time constraints, technology constraints or staffing issues, loudly identifying accessibility issues when there are plenty of other challenges, will serve to isolate you, make your job harder and can create a perception amongst your colleagues of you being "difficult".

It’s a common challenge at times that whilst accessibility is important there are times when its not that important to be acted upon. How do we get past that, and make the problems we find actionable?

What are THEIR motivations?

Understanding people's motivations and how they perceive accessibility can go a long way towards making accessibility a real and tangible thing to be acted upon.

The motivations of developers, and the motivations for senior management may overlap but aren’t always the same. There's the end goal of being accessible but speaking to management about in-the-weeds technical issues won't achieve much other than to confuse them, same with speaking in strategic ways about accessibility to developers.

When tailoring your message, know your audience and understand their challenges and how you can help them with accessibility.

Your developers may be fantastic coders, but they may not be up to speed with the latest accessibility techniques, so show them.

Explain concepts and challenges and sketch it out on a whiteboard. Appeal to their sense of wanting to do a good job, their professional pride of making a site which is error free.

Besides, no one likes to hear an endlessly negative list of problems, and how they've not produced great code. Its insulting, and ultimately its counter productive and doesn’t help anyone.

Reframe the message

You've identified a problem but why is it a problem and what has the developer done right? Instead of blaming, emphasise what has worked and what's good and follow up with what can be improved.

Discuss why the issue is challenging for people with impairments. Until you've made accessibility relatable, it's just another standard which must be addressed. It’s a challenge that I've had to learn over time.

Build a relationship

Follow up with friendly emails and share occasional articles and blogs posts of hints and tips with accessibility. Sure, many people won't read them, but some will.

Email, whilst being convenient is also emotionless and easy to be ignored, especially with time poor developers. Speaking to people helps begin to build a relationship and identifies you as the accessibility person, not a faceless individual emailing problems.

Prioritise problems found

Draw people's attention to accessibility issues that require prioritising straight away.

Are there any issues which are show stoppers and will expose your organisation to risk? Risk is often the biggest motivator for people to act on accessibility problems. Unfortunately, until something is deemed to be a risk which may result in a financial penalty or adverse publicity nothing will happen.

Severity is an art

Identifying and classifying an accessibility issue is itself an art. But every issue is not a barrier which will affect a person's ability to use your website. A poor colour contrast may have a lesser effect on someone than, say, no keyboard support throughout the whole site.

Assigning a severity rating to issues identified will help development teams to begin addressing issues.

In an ideal world every issue would be addressed, fixed, tested comprehensively and deployed to the production website, but this seldom happens so fluidly. A severity rating encourages the most important issues to be addressed first.

The remaining issues will be addressed as part of the normal cycle of fixing defects. It may not be the ideal which we are striving for, but it’s a start and it helps.

Know when to hold and when to fold

Will letting several accessibility issues pass and enter production mean the knowledge within the organisation improves overtime?

Is it better to accept a few minor accessibility problems, whilst fixing major problems? Or even turning it on its head and fixing the easy issues whilst leaving the difficult problems into a temporary too hard basket? This is something you need to work out. Becoming a subtle negotiator means over time you're more skilled in understanding how to motivate people to fix accessibility problems.

People don’t want to do a bad job, but there are numerous external factors which affect people's ability to deliver good accessible websites.

By understanding those factors, we can begin to make our job easier and persuade people to do the right thing, the correct thing, which results in a better inclusive website for everyone.

Diplomacy IS the hard-learned skill toward being successful in web accessibility.

Accessible chatbot UI revisited

2018-11-25T00:00:00Z

Native HTML elements have keyboard support. Buttons, links and form controls all appear in the keyboard ordering sequence as standard.

Because each chat bubble is a non-semantic element (they were rendered as DIV elements) I had decided to make each bubble focusable and added the tabindex attribute. My thinking was this approach would allow a user to navigate through the entire conversation history solely from the keyboard.

I admit, it’s a technique I've used in the past and it's been a convenient way to navigate content which doesn’t traditionally fit in the regular layout of a page.

Chat conversations update frequently, and possibly don't sit well under static heading structures, so could become difficult to understand if a user wanted to re-read parts of the conversation.

Several people at the conference mentioned how only interactive elements should receive tab focus. Just because you can make non-interactive elements focusable, should you?

Adding tabindex onto each message bubble will ensure they become "interactive", but what does that achieve? The messages are now reachable in the keyboard sequence and that’s it, they don’t do anything else, they're not really interactive.

Besides the HTML 5.3 W3C Editors Draft describes interactive content as content that is specifically for user interaction. Chat bubbles don’t fit that definition.

Interactive content is specifically intended for user interaction.

The technique I used isn’t necessarily incorrect, but it did make me think is there a better way of doing this? And there is, and it is using less code instead of more.

<div class="conversation-text user">That would be great, 
can I book in for Monday?</div>

Removing the tabindex attribute on all DIV message bubbles, means the messages no longer appears in the keyboard ordering sequence. However, each message is still reachable using screen reader navigation keys.

aria-label identification

Previously I had used aria-label to identify where the message was originating from - the bot or the user. aria-label can be used on any base element but that doesn’t necessarily mean it works consistently across all browser/assistive technology combinations, as explained by the Paciello Group:

If you use aria-label, aria-labelledby, or aria-describedby with any other elements (like div, span, p, blockquote, or strong etc.), they generally won’t work across all browser/assistive technology combinations.

The aria-label technique had previously been tested and worked consistently. But when a colleague questioned its usage and their understanding of it, this caused me to retest previously working components. The outcome was it no longer worked, it may have been a specific combination of browser/assistive technology which originally allowed it to work fine.

I decided to rely on a technique which has consistent support across browsers and that is screen reader specific text. CSS is used to render text off-screen and hide in the visible screen display, but still announced through the screen reader.

<div class="conversation-text user"><span class="sr-hidden">You said</span> That would be great, 
can I book in for Monday?</div>

This throws up a further problem though, the screen reader hidden text is now unread as part of the visible sentence when tabbing through the conversation history.

Summary

There are always several ways to achieve the same outcome. Solutions which may have worked in previous browser/AT combinations may no longer work with updates and so it's crucial to constantly apply a critical lens over any accessibility solutions. Thanks to the OZeWAI community for flagging this.

Building a better chatbot UI with semantic HTML

2019-02-03T00:00:00Z

Using DIV and SPAN elements in your HTML isn't great. The generic elements are non-semantic, provide no meaning, and when they're overused mean you have to add extra meaning to the elements to provide structured information.

If you're putting time and effort into adding extra after-the-fact attributes and markup to make your DIV and SPAN elements provide more meaning, and thinking there's got to be a better way, well you're right, there is a better way and that’s with HTML5 elements.

More meaning with HTML5

The HTML5 specification provides new elements, attributes and behaviours in your browser and combined with WCAG 2.0 techniques it gives you a lot more power to introduce more meaning into your web apps.

Browser adoption is very good so there is increasingly less reason to not use the elements, and HTML5 elements can help you avoid (or at least reduce) the DIV'itis of unclear code.

The elements can help a screen reader user understand more of the screen by providing context, and several of the elements can serve as waypoints to define regions or provide onscreen text in a way which makes onscreen functionality easier to understand.

Browser support

The site HTML5 accessibility tests which features are supported by major browsers and if they're mapped to the accessibility API. An accessibility supported feature means its usable by people who rely on assistive technology.

Our chatbot UI fenton heavily used DIV and SPAN elements. They worked fine, but the code was overly reliant on these filler elements.

With the arrival of new elements in the HTML5 spec, it presented a great opportunity to update the HTML and make the chatbot UI more semantic and aid readability, besides who doesn’t like easier to read code?

Conversation identity

Previously every message was created with a DIV element, with screen reader specific text contained in a SPAN identifying the source of the message.

<div class="bot">
<span class="sr-hidden">The bot said </span>
Hi There!
</div>

There was nothing wrong with this approach and the technique worked, but the DIV provides no structural information and so lends itself to being replaced with a HTML5 SECTION element.

Placing each message within a SECTION provides greater meaning. It shows each message is related to the conversation and to each other, something which is difficult to do with ordinary DIV elements.

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading. HTML Living Standard

We also added to this an aria-label attribute to provide a unique name for the element and this is where we were creative. Every SECTION name needed to be unique, but if we used "the bot said" as a label multiple times it wouldn't be quite so unique, so we appended a timestamp to each message as well.

Every element has a unique name, and it assists the user traversing through the conversation history to understand the sequence of the messages when using a screen reader.

<section aria-label="The bot said 2:41 PM" role="region">
Hi there!
</section>

The role attribute is for backwards compatibility for legacy browsers and is only a fall-back.

When tested in Chrome with NVDA, the landmark list displays several SECTION elements with the time they were displayed.

The landmark list within NVDA displaying several regions each with a unique name

The accessibility tree is how assistive technology makes sense of the webpage in a non-visual way. If the accessibility tree is showing a logical layout with appropriate element names there is greater likelihood of screen readers and other assisitive technologies interpreting the structure correctly.

The accessibility tree within Chrome displaying nested region elements each with a unique name

Conversation container

The previous implementation used one DIV element for the conversation wrapper which contained all the conversations and this too was replaced with a SECTION element.

<section id="conversation-body" tabindex="0" aria-label="Chatbot conversation">
<section class="bot" aria-label="The bot said 2:41 PM">
    Hello, I see you're looking at loans can I book you into see one of our lenders?</section>
<section class="user" aria-label="The user said 2:42 PM">
    That would be great, can I book in for Monday?
</section>
<section class="bot" aria-label="The bot said 2:43 PM">
    What's the closest branch to you?
</section>
<section class="user" aria-label="The user said 2:43 PM">
    I'm in Canberra, so it's the city branch
</section>
<section class="bot" aria-label="The bot said 2:44 PM">
    Great, I've booked you in to speak to one of our lenders on Monday</section>
</section>

The SECTION named 'conversation-body' contains several child SECTION elements representing the conversation history.

The landmarks region within NVDA with unique sections nested within a container

A screen reader user can identify the chatbot landmark and navigate to individual message landmarks within.

Other features

Other features which we've previously written include the TABINDEX attribute to allow the conversation container to become keyboard focusable and scrollable using the arrow keys. The addition of ARIA-LIVE=POLITE which causes the audible announcement of new content through the screen reader, the value of 'polite' pauses announcement of the updates until all other screen reader announcements have finished.

<section aria-label="Chatbot conversation" tabindex="0" aria-live="polite">

<section aria-label="The bot said 2:41 PM" role="region">
Hi there!
</section>

<section aria-label="You said 2:42 PM" role="region">
Hello, I'd like advice on a bank loan
</section>

</section>

Using HTML5 SECTION elements reduces the code to be written and increases its readability, the elements provide greater clarity around parts of the chatbot and help provide additional context for the end user.

References

Section elements browser compatibility
Section elements HTML5 accessibility support
Check out Accessible chatbot design for background information.

Accessify Your Blazor Apps - Hot Accessibility Techniques For Blazor Apps

2020-05-19T00:00:00Z

Transcript

Hi everyone thanks for joining this evening under what are very challenging circumstances. This was to be a live session in Sydney and Canberra but now its online. However, I've got more flexibility to help answer some questions as we go, I'll be taking questions throughout the presentation via Twitter.

If you have any questions tag me in them @MrRossMullen with the hashtag #SSWBlazorA11y. For those in the know and those not, a11y is a shorthand way for discussing web accessibility on Twitter without using up all of the available characters. There are 11 characters between the A and Y hence Aye-Eleven-Why or a11y.

The agenda this evening is

Brief recap on accessibility
Frankenstein's monster, the DIV button
3rd party control suites
Aria live regions
Managing accessibility in large teams
And lastly using Javascript interop to manage screen focus

A little about me, I'm a digital accessibility specialist in the public service and I'm also director of CANAXESS a web and digital accessibility company. I've been working in web accessibility for in excess of 7 years in a myriad of roles including accessibility auditor and evaluator, and accessibility developer which is what I mainly do now. Before that I had numerous roles as a C# developer gradually moving from the backend and then into the frontend. I'm also a web accessibility author for Pluralsight and create accessibility courses on Udemy and YouTube.

Brief Recap On Accessibility

Accessibility is making an application usable by everyone with or without impairments. Many of you have heard about WCAG. It's best practice accessibility techniques which set out how to make web content accessible for the largest number of people. It's a set of technical criteria to build against, grouped under guidelines and principles which categorise the technical criteria into areas of concern.

WCAG stands for web content accessibility guidelines and it's an internationally accepted best practice way of making web content accessible. It's been endorsed by governments and large organisations worldwide as the accepted technical standard to apply. Its technology agnostic, but ultimately presents solutions in HTML, CSS and Javascript.

WCAG has three levels of conformance A, AA and AAA when implementing the technical detail. These are degrees of difficulty of implementing a technique and support for the end user. Single A techniques are pretty straight forward to apply technically, and give the user modest accessibility support. Whereas triple A techniques can support more users with more complex and diverse impairments but it's also more technically challenging to implement.

For example, providing ALT text for images means people with a vision impairment can understand it and its quite trivial to implement. Whereas a triple A technique is providing a sitemap. It can help users navigate a site in a nonlinear way but providing all possible permutations of a complex web app is much more challenging. Double A criteria is identified as that sweet spot, providing good accessibility support and not a massive technical obstacle to implement.

Web accessibility is a big deal. In the US Beyoncé Knowles' company was taken to court over an inaccessible website as a blind user wasn’t able to use it as was the US pizza chain Dominoes. Whilst there's been far less court cases in Australia there have been a few standouts. The supermarket chain Coles had an online ordering component which blind people couldn’t use, after repeated attempts to rectify, the case eventually ended up in Court and Coles settled with an agreement to fix their website.

Frankenstein's Monster, The `DIV` Button

A challenge when building complex interfaces is the standard array of HTML elements don’t always provide the level of interactivity needed. A decision is often made to build a new control as it'll provide more flexibility and it can do more and work how we want it to work. But there is a problem with this approach.

The standard HTML elements have built in semantics, the controls play well with browsers and assistive technologies (so things like screen readers) out of the box, there's no setup needed, no configuration, native HTML components just work. When a BUTTON element is used, the screen reader understands it’s a button, the browser allows it to be focusable in the natural page sequence and its state when it is pressed is announced through to the screen reader through the accessibility API which exists at the operating system level. The operating system exposes the webpage objects and events to assistive technology through this API. All this hidden accessibility support is provided simply by using a button element or any other native HTML component.

But someone may come along and say buttons are boring, that they can't style them adequately and work begins making a new control with DIV and SPAN elements. Using these generic elements means you can begin building richer UI's with greater flexibility, but this comes at a significant disadvantage for assistive technology users. All of those inbuilt semantics which existed when using a native controls, are now lost as we've decided to go it alone.

The DIV element probably has a click event triggered when using the mouse, but when using a keyboard its unreachable because DIV elements are generic and don’t appear in the keyboard ordering sequence. Some users navigate predominantly via the keyboard and they now can't tab and action the control.

So, first of all we have to add onto the DIV the tabindex attribute with a value of 0 to ensure its focusable in the keyboard tab sequence. tabindex="0" means the element appears in the regular keyboard sequence and that sequence is in the order the components are displayed onscreen.

Adding a tabindex attribute and a value of 0 to the DIV has now made it focusable from the keyboard, users can tab to the control. Whilst its now actionable assuming keyboard and mouse event handlers have also been added when a screen reader encounters it, it won't describe what the element is when in focus. Native elements announce the type of control audibly through the screen reader when in focus because of their built-in semantics, it may announce the type of control such as button or link.

However, DIV and SPAN elements don’t. Our hybrid control is a DIV and DIV elements are generic and don’t do anything so whilst its clickable a vision impaired user relying on a screen reader to communicate the controls audibly won't know it can be clicked.

To overcome this, we add the attribute role and the value of button. Role attributes are special attributes called aria (accessible rich internet applications) which can make elements assume the behaviour of other elements. By assigning the role of button to a DIV we can trick the screen reader and other assistive technology into announcing that this DIV is actually a button and buttons are clickable. So, we've now got two wins, we've added tabindex to make the faux button navigable from the keyboard and we've used role=button to make the screen reader announce it’s a button.

But this DIV button may have an icon instead of text denoting the button does something, which is great for everyone who can see it but if you can't well, we need to cater for that. We have to provide an accessible name, which is a label that provides a text description for the button. If this button received focus without a text description nothing would be communicated to the user other than the control type. To overcome this, we apply the aria-label attribute to provide a programmatic text description. This description isn't visible, but it means when in focus navigating via a screen reader this text description will be communicated to the user.

It's as this point the faux button is now behaving like a regular button. It has a tabindex, a role of button and an accessible name, and it's got click and keypress event handlers. All this work to make this Frankenstein's monster button be replaced with, using a BUTTON element.

A BUTTON element has a default behaviour of being focusable from the keyboard, it has an implied role announced to assistive technology and often (if created correctly) has a text label. So, we can go ahead and make custom controls but the effort to make them accessible and practically usable is significantly greater and much more effort.

By sticking with native HTML controls and components our apps are already more accessible than if building a custom control. That isn't to say custom controls should be avoided, but its understanding that to make those controls accessible is much more challenging.

The difficulty with 3rd party control suites

But the reality is there are times when we need to build complexity, that the controls provided by native HTML are too basic for what we need. We might need filter and sort functionality on data tables, autosuggest controls and other functionality which can't be provided by native HTML. After understanding all the challenges of building your own DIV button and the steps you have to go through, you might then think use a third-party custom control suite as to build it ourselves is really really challenging. Vendors have done the hard work for us by building a suite of complex custom controls and due diligence has been applied by making sure the control suite has been built to accessible standards, the vendors even provide an accessibility conformance statement.

Be very cautious!

This is one of the most problematic areas of using suites of custom controls to do a lot of the heavy lifting in web apps. Telerik, Synchfusion, Infragistics and many other vendors produce feature rich controls, which seamlessly integrate into your existing code and make it easy to produce complex interactions.

However, the accessibility statements the vendors provide are often so narrowly defined and superficial that the accessibility support provided is extremely limited and, in some instances, non-existent. The accessibility statement may state a control is keyboard accessible or that is has aria support for screen readers. Unfortunately, the accessibility statement provided applies the accessibility guidelines in isolation. So, whilst a control may have keyboard support and can be reachable from a keyboard, it may not have an accessible name. The control may trigger a partial refresh of the page but is that refresh communicated to a screen reader through an aria live region.

Looking at the Telerik UI for Blazor grid "Add Product" is the only button. All filter controls are DIV elements. Each filter control has a label of filter, but not what column is filtered. As they're all labelled the same a screen reader users will only hear multiple "filter" and thats if they could reach the control. Each cell has buttons which allow you to Edit or Delete the row, but these have a tabindex="-1" attribute which renders the buttons unfocusable from the keyboard. If the table refreshes this change isn't communicated audibly through the screen reader using a live region. And this has just been a very quick superficial check. The more you look, the more of a rabbit hole you go down in finding really challenging accessibility problems.

And it's not just Telerik, its all of the well-known custom control vendors. Accessibility is viewed as technical checklist, which is assumed that by putting in more accessibility linting the control is made accessible and supports more users with diverse disabilities. Unfortunately, it doesn’t work like that.

To build in accessibility means having to think about not only making sure the control and its subcomponents are accessible but making its effect and result is accessible as well. And backing this up with testing with users with disabilities. And ensuring all that works in a combination of browsers and assistive technologies. It's a lot of effort to get right and that’s why unfortunately many haven’t got it right.

It's promising that vendors are understanding accessibility is a growing requirement everywhere. But before you adopt a custom control suite, it needs to be comprehensively tested for accessibility, so you at least know that there is a suitable level of support there. If you don’t have time to independently test the control yourselves, ask if the vendor has tested the controls with users with a range of impairments and request to see the outcome.

Alerting the user audibly

The way we develop apps now means we seldom trigger a hard refresh of the page, only the parts of the page which have changed are refreshed. Because this change is visual a screen reader can't identify which parts of the page have updated as it relies upon the hard refresh for new content to enter its buffer. Something has changed, or something has refreshed and we need to look at other techniques to communicate the page state. One approach is to provide audible hints through an accessibility technique called a live region which can be used to indicate the status of the change audibly to the screen reader.

A live region is really just adding an aria-live attribute which screen readers can interpret to any HTML container which has content that updates. It could be a div or span element, really anything. The way the live region works is when content is added to it, the new content is communicated through to the screen reader which announces it so it’s a very convenient way to alert the user that something has changed. You can use one of several values which prioritises this announcement. If a value of assertive was used this would cause the screen reader to announce the new content straight away, if a screen reader was in the middle of reading onscreen content and new content was inserted into the live region, the screen reader will stop its announcing of other content and immediately announce the new content in the container.

We can dial down the level of urgency and instead use the value polite, which will pause until all other onscreen announcements have first finished before announcing the newly updated content.

We can also control the types of updates for the live region. Using the aria-relevant attribute we can announce only new content added, content removed, text updated or everything.

By default, without doing anything the aria-live attribute behaviour is watching for additions and text. There may be times where we want to only announce new content, the container may have existing content like a status message which holds all the old messages but we don’t want all the previous content announced when new content is added, and we can add the attribute aria-atomic. This takes a boolean value which specifies all of the contents in the container is announced, or only the new content.

An aria live region provides tremendous flexibility with how to communicate onscreen updates to a screen reader. And it may be confusing with the numerous variations of aria-atomic values, and aria-relevant values and the levels of assertiveness. A technique in the updated Web content accessibility guidelines version 2.1 provides pre-defined roles which have all the behaviour in place and we just need to specify the role according to what type of update it is. The roles all have different behaviour types for specific purposes. The roles are:

Log is for describing a log of events, or messages. It has an implied assertiveness level of polite, and an implied atomic value of false so only new updates are announced.
Status is for communicating status updates, a document has been saved or a screen has loaded. It has an implied assertiveness level of polite, and an implied atomic value of true so when new content is inserted into the container everything is announced.
Alert is for communicating errors or warnings. It has an implied assertiveness level of assertive, and an implied atomic value of true so everything is announced.

There are also the roles Progress Bar, Marquee and Time and there is still debate as to how screen readers and assist technology interprets these.

Managing Accessibility In Large Teams

But coding this each time in a Blazor app along with the numerous variations is a challenge. If the team is large, you may initially communicate the types of statuses, and describe how only to use a certain role type in design documentation. But those documents may not be read, or someone interprets them in a different way and the bold intention of building accessibility in is drifting away. In small teams its pretty straight forward to enforce design consistency, but as teams get larger it becomes much more challenging.

Creating reusable components solves this problem and makes the design consistently repeatable. Instead of leaving it up to the developer to hand code the numerous attributes and variations. A component can be created which has a range of parameters that can be set when developing. Developers aren’t having to directly code the attributes they're simply setting what type of message to display.

So, lets create an aria live component. I've created the component AudibleAlert; it'll use the new WCAG 2.1 alert roles and to maximise compatibility with legacy browsers I'll also add a redundant aria-live attribute. We'll use the three roles log, status and alert as a parameter to set what sort of live region we want to create.

When the component is used, we no longer have to manually add the attribute ourselves. We call the component with the role we want as the parameter and what's populated is the correct live region. All we then need to do is wire up how content is added into the live region container. We haven’t had to worry about specifying the correct roles or using the correct attributes, it's all done for us.

But there may be times we want to have more granular control over the type of live region being created. We may want to decide that all updates are announced or only new content and whether to announce additions or deletions of that content. The AudibleAlert component can be extended to include extra parameters which can create this variation. It can add the aria-relevant attribute to manage which type of updates to be announced, and it can have the aria-atomic attribute to specify whether to announce only new updates. And we've chosen easy to understand parameters to reduce the confusion of having to understand the aria-atomic or aria-relevant attributes.

All you need to then worry about is the trivial way of wiring up the data or values updating the container. This component has provided the accessible scaffolding.

As web applications become more complex, there is a requirement to rely on aria attributes more to provide feedback for users with a range of impairments, but aria attributes are quite brittle. They may not work well in all browsers, and they may not work well in all assistive technologies unless coded correctly. So, taking the responsibility away from the developer to have to worry and think about these sorts of things means a stronger likelihood accessibility is being maintained and is being implemented consistently, the component is called with the parameters and the rest is done automatically.

There is still the flexibility there for developers to choose which statuses are used, and there will probably be mistakes over the incorrect status region chosen for a particular message. But the mistakes now concern if the correct role has been used, not if the correct attributes are used. So, the live region will still work regardless. With components we're moving the accessibility conversation away from is this the right attribute added in the correctly way, to is this the right way the component is being used.

Managing Focus

Managing focus is crucial to making it easier for keyboard users to navigate around the screen. When modals, or new screens are loaded and the focus isn't programmatically managed and moved to the new content, a keyboard user will have to repeatedly advance the Tab position on to this new content. It's an annoyance for simple screens, but if there's a screen with many controls, or a menu with numerous links that small tab sequence can increase to be in excess of 20 or 30 times a user has to press the Tab key to advance focus. Programmatically managing the focus means when new content is loaded and we want the user to interact with it, we manually move the screen focus. The user does not have to worry about tabbing to the new content as its already there, and its reduced a potential keyboard accessibility navigation problem.

For this technique we use the Javascript interop feature. This allows us to call Javascript code to interact with the elements on the page and manage focus.

We've created a very trivial bit of Javascript in its own file. We have the sole Javascript function named IDFocus, and it accepts an ID of any component on the page. The parameter is passed to the Javascript getElementById() method and the focus property is called all pretty straightforward stuff. When the function is called with any element ID on the page, the screen focus is positioned onto the element.

The Javascript is called within the Razor component from the OnAfterRenderAsync lifecycle method after the control has finished rendering. It has the Javascript function to call along with any parameters to pass in this instance the heading ID but it could equally be any element both interactive and non-interactive.

If non-interactive elements are being focused those elements then require a tabindex="-1" attribute and value to permit programmatic focusing.

I've created a Blazor page called HeadingFocus.razor, which for the purposes of this scenario is just having its heading focused. It has a <h1> heading element, and because this is a non-interactive element it also has the attribute tabindex="-1" to allow programmatic focus. The heading element has an ID which is a set at runtime and this is also the ID passed to the Javascript function. Within the OnAfterRenderAsync method is the call to the Javascript method.

By applying this technique to all components which trigger the display of new UI content means the screen focus is always in synch with the content. An important point is a similar method must also be created to move the focus back to the calling element when this content is closed or hidden, it’s a two-way process. Move focus to new content when it appears and move focus back to the previous content when it is dismissed.

In Summary

Native HTML controls as standard have built in semantics which screen reader and other assistive technology can interpret and understand without having to do anything extra. When building your own components, you need to do extra work to bring those controls up to an acceptable level. The DIV button is a really good example, deviating from standard controls can become a technical overhead with having to add back features which exist already within HTML elements, and in that case the BUTTON element.

Control vendors provide a great range of custom componentry but approach using these with caution. The accessibility statement is often so narrowly defined that the accessibility support just isn't there. Do your due diligence and get the controls tested independently by an external web accessibility company, if in doubt speak to me.

When something changes in a Blazor app, a file is saved or validation errors have occurred and there is a visual indication, provide an audible indication through an aria live region. Aria attributes induce the screen reader to announce updates dynamically. However even though you may build an aria alert to specification, inconsistencies between browsers, and assistive technologies mean it may not work exactly as expected.

Working in large development teams can mean accessibility knowledge becomes diluted and interpreted differently. Leverage the support of components to hide a lot of the granular accessibility details and instead provide parameters which can turn the features on or off. Using components means you're more likely to produce consistent accessibility support, but it does need that initial upfront investment of a dedicated accessibility resource producing the specifications of the components and the expected way they work.

Screen focus needs to be actively managed in Blazor apps. Use Javascript interop to call Javascript methods which focus onto named elements on the page. Managing focus is a two-way process as well, managing it onto a new view when shown, and managing it back to the original calling element when the view is hidden.

Thanks to Adam, Penny and everyone at SSW for running the user group under very difficult circumstances and thanks for the invite. Blazor is no different than any other framework for accessibility, it doesn’t make any web application any more or less accessible, but you still need to actively put in accessibility support.

If you're interested in continuing the conversation reach out to me at ross.mullen@canaxess.com.au or on Twitter @MrRossMullen and I've put up a repository on GitHub which contains everything I've spoken about as well as links, and the headingfocus and audiblealert pages and component. Go to github.com/canaxess/presentations and navigate to SSW-Blazor-Accessibility.

Web accessibility isn't necessarily achieving a 100% WCAG 2.1 accessible score, but its introducing more support for users who navigate in non-traditional ways.

Write Clear Link Text

2020-06-04T00:00:00Z

Transcript

Links are the core way to navigate between webpages, but creating link text which is understandable can be a challenge. Unless the link text is well written it can be very easy or very hard for a user navigating audibly to understand where the link takes them.

In this lecture I'll walk through what constitutes good link text. I'll explain why clear link text is a necessity for web pages, describe the problem with poor link text and show several examples of good link text.

By the end of this lecture you'll be able to understand the benefits of clear link text, how to spot poor link text by using the reading aloud technique and ensure all links you add have text which is clear and understandable when read individually.

Some users navigate a website via a screen reader which audibly announces the text and labels of links and other interactive elements on the page when tabbing through with the keyboard. When a link has focus the link text is announced, but unless created clearly this text can be difficult to understand.

When a user navigates a page visually, they can easily understand the relationship between non-link text and the link. The text surrounding a link often provides additional context for where the link goes.

Link text asking the user to click here for today's fashion trends is easy to understand if the user can visually identify the proceeding non-link text "for todays fashion trends", the relationship has been established visually that the link labelled "click here", will take the user to information about today's fashion trends.

But a screen reader user doesn’t necessarily have the same ability to gather visual hints or the proximity of other text. The user may be unable to hear any of the other non-link text and they're instead relying solely on the link text to provide sufficient information where the link goes. If a link is labelled unclearly as in the case of the link text "click here" it becomes difficult to understand the destination of the link.

Overcoming unclear link text has a straightforward solution. use clear link text! Seriously it's that simple. Screen reader users navigate via page links, so it's vital to provide link text which is understandable when read on its own. But what constitutes clear link text? Its text which is understandable when read on its own away from of any other non-link text or paragraph content.

In the previous example, the fashion link would be unclear link text, when read on its own the text "click here" is unclear, what is it referring to, where does the link go? Attempting to understand the link destination solely from the text its impossible.

Instead replace the unclear link text and make the whole text a link "click here for todays fashion trends", instantly an understandable link has been provided which makes sense when read on its own. When the link is read individually the destination of the link is described, a screen reader user can understand that this link will navigate to content about today's weather. This can be taken a step further and unnecessary words be reduced to create truly succinct link text. A link by its very nature is clickable and navigates users to content, several screen readers will identify a link and add the word clickable to its audible description. Therefor an option could be to remove click here (as that’s unnecessary as that’s what a link does) and instead have "todays fashion trends" using only the words necessary to describe the destination, wherever possible get into the practice of using short and succinct link text.

Aside from reducing audible clutter of unnecessary words, links which begin click here are difficult to navigate using a feature of screen readers called the links or elements list. This is a window which lists all links on a page separately within the screen reader software. It’s a way for users to quickly navigate to a link on the page without having to navigate through all onscreen content. All of the page links are listed alphabetically, if several links begin "click here" a user has to listen to each link in full to determine if it’s a link they want to activate by hearing the last unique part of the link text.

A way to determine if link text is clear is by reading it aloud. Hearing link text spoken is a great way to determine if the text is understandable on its own, if you described a link to a colleague or friend using just the link text could they understand it? If not, then it’s probably a good indicator that the link is difficult to understand.

Using clear link text satisfies the HTML specific technique H30 Providing link text that describes the purpose of a link for anchor elements which means this has passed Success Criterion 2.4.8 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general (level AAA).

I chose to use a WCAG 2.1 AAA technique as it presents a better user experience for the end user, to pass at AA level all that is required is to provide is non link text which provides clarification for the link itself, there may be several read more links but because the preceding or proceeding text provides context this is classed as a pass. In our opinion this is a poor end user experience and always suggest you aim for the AAA success criteria in this instance.

I explained how unclear link text can make it difficult for screen reader users navigating a website in a non-visual way. The simple approach to this is to use clear link text, and the best way to determine if the link text chosen is clear is by reading aloud any text. If it makes sense when read outside of the accompanying webpage then this is a good indication the link text is clear and understandable.

This video is from our Introduction to Web Accessibility WCAG 2.1 Udemy course. The course is designed to teach you the fundamentals of web accessibility and how to apply those techniques to websites that you create. If you're interested in finding out a little more, checkout the link in the description below as well as links to a full transcript.

If you want to stay up to date with web accessibility and to learn cutting edge techniques, consider subscribing and click the bell icon to be notified when new videos are uploaded.

Grouping Controls

2020-06-22T00:00:00Z

Transcript

Grouping related controls together can help a user understand relationships more clearly between components. For example, form controls for an address may be grouped visually next to each other, but if the user is unable to identify the visual grouping any relationship between controls can be difficult to understand.

In this lecture I'll show how to group related controls together semantically. I'll explain why you may want to apply groupings to similar controls and how to use semantic HTML to ensure the grouping is identifiable via a screen reader and therefor perceivable to a larger collection of users.

At the end of this lecture you'll understand how to group related form controls together using semantic HTML to allow screen reader users to understand related controls. You'll understand that although grouping is a good way of creating relationships which are conveyed without relying on the way components are arranged, the technique should be used only when necessary.

The way form controls are laid out on screen can help and enhance the understanding of relationships and how controls relate to each other.

A collection of dropdown list controls for a date of birth may be understandable when adjacent to each other, but if a user can't perceive the visual grouping, they will only hear the individual labels and be unclear how they relate to each other.

They may guess it’s a grouping of controls requiring the date of birth, but when a relationship becomes complex, grouping controls together semantically can help a user understand how components relate to each other.

In the previous lecture "add labels to controls", a label provided a description of the individual control. But to identify groups of controls which are related the fieldset and legend elements can be used to provide a description for the whole group. This grouping mechanism triggers a screen reader to announce the legend text before the label text of each control.

Form controls can be grouped together using the fieldset and legend elements, all controls which are contained within the fieldset are then related. The legend element is the first element within the fieldset, and this describes the grouping and what is announced by the screen reader. When a screen reader focuses on any control within the fieldset the legend text is announced prior to the label of each control.

Grouping controls using the fieldset and legend element is most important for radio buttons and checkboxes. The individual label for each control may be insufficient to describe the whole groups description.

In this example there are several controls asking a user to select their shipping options, the label of each control describes the value but not the relationship to each other. In this instance grouping must be used to provide an additional description.

The numerous shipping options could therefore be enhanced by wrapping all of the radio buttons within a fieldset element and use the legend element to provide an extra level of description. When each control receives focus, the legend text will be announced first followed by the control label.

The technique is a convenient way to provide an additional level of detail for controls which may have an unclear relationship. However, don’t overuse it. Only use it where there is a need to provide additional relationship information. Because a screen reader conveys onscreen information audibly extra irrelevant content is announced which can become fatiguing.

Using the fieldset and legend elements for additional relationship information is covered by the HTML specific technique H71: Providing a description for groups of form controls using fieldset and legend elements which means this has passed success criterion 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text at level A.

Using fieldset and legend elements are a great way to group related controls together. When controls are contained within this grouping the screen reader announces the legend text followed by the control label so it’s a convenient way to describe a collection of related controls which belong together.

Although it can be applied to all controls, its best suited to use for checkboxes and radio buttons where the individual label for each control may be insufficient to describe the whole groups description.

If you want to stay up to date with web accessibility and to learn cutting edge techniques, consider subscribing and click the bell icon to be notified when new videos are uploaded.

Decorative and Descriptive Images

2020-07-06T00:00:00Z

Transcript

For vision impaired users every image needs to provide a text alternative, which is a way for the user to understand what the image is describing. But if the image is decorative, this description is not required, in both instances though the ALT attribute is required.

In this lecture I'll explain the ALT attribute, a way to describe descriptive images and a way to make a screen reader ignore decorative images. The often-repeated phrase all images require ALT text is only partially correct, some images require ALT text and some don’t.

At the end of this lecture you'll learn how a visually impaired user can understand an image when they can't see it. Understand when to apply succinct ALT text to describe a descriptive image and when to use blank ALT text to ignore a decorative image.

As I've discussed previously a visually impaired user may use a screen reader to navigate a webpage. The screen reader uses the HTML semantic structure to make sense of the page and describe its content audibly, so all the appropriate options for elements are used to give the screen reader the best chance of conveying content correctly.

The first rule for adding any images via the IMG element is making sure every image has an ALT attribute. When an image is missing an ALT attribute a text description (if required) can't be provided.

When images are encountered by a screen reader it uses the value of the ALT attribute to provide a text description for the user. If an image has no ALT attribute the screen reader will announce "image". So, the user is aware an image is there, it may be relevant it may not, but they are uncertain.

The ALT attribute is the way to provide a text description or conversely to indicate to the screen reader that the image serves no purpose other than being decorative and it can be ignored.

For an image of a boat appropriate ALT text could be "boat" as after all the image is of a boat. Whilst technically correct, the image is of a boat adding such succinct ALT text really isn't in the spirit of web accessibility.

What is the image describing, why is it relevant, what does it show? If you were describing the boat to a friend, you would say more than the literal description, apply that same richness when adding ALT text why is the image relevant, it may be a boat sailing under Sydney Harbour bridge on a sunny morning, or "A replica sailing ship leaving Sydney Harbour".

Avoid overly verbose descriptions as well, ALT text of a short sentence is probably the upper limit when describing most images. Use enough of a description to convey what the image is showing.

The second rule for adding images is descriptive images require ALT text, decorative images don’t. Unless an image is crucial for a user to understand the content of the page, set the ALT attribute to null.

When an image is decorative and doesn’t require an explanation use blank ALT text. The image still has the ALT attribute, but it has no value. So, don’t have ALT text with the value of "blank" or "null" or have a blank space, the ALT attribute value is nothing except two double quotes next to each other. Using null ALT text means the screen reader will ignore the image, this is particularly useful if you have spacer images, or images which are decorative.

Providing ALT attributes for images satisfies the HTML specific technique H37: Using alt attributes on img elements and the general technique G82: Providing a text alternative that identifies the purpose of the non-text content. Which means this passes 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose at level A.

I explained how a vision impaired user relies upon the ALT text of images to understand what the image depicts. The screen reader uses this ALT text to provide a text description of an image which is announced by the screen reader. If an image is decorative and can be ignored by the user, the ALT attribute value can be set to null. In both cases all images require an ALT attribute, but only some images require ALT text.

If you want to stay up to date with web accessibility and to learn cutting edge techniques, consider subscribing and click the bell icon to be notified when new videos are uploaded.

Create Logical Headings

2020-07-20T00:00:00Z

Transcript

Headings on a webpage are much more than a large and prominent font. Headings provide a visual hierarchy that breaks up content and allows a user to easily scan the page. However, unless the heading structure has been coded correctly the page hierarchy will be meaningless to non-sighted users

In this lecture I'll explain how to best structure a webpage using heading elements. I'll explain why headings need to be on every webpage, how you don’t need to use all of the headings to create a document hierarchy and understand the golden rule for headings which is do not skip heading levels.

At the end of this lecture you'll be able to use headings to provide a coherent structure to a webpage. You'll understand you don’t need to use all heading levels, and the heading levels you do use need to be applied in a sequence and that sequence not skipped.

think of headings as the webpage outline. Users who can see the headings can decided instantly if they wish to continue reading the page due to being able to quickly scan the heading levels.

When a page structure is coded correctly, screen readers and other assistive technology users can navigate the webpage by the heading level. Within the assistive technology users can list of all page headings, jump between heading levels and even navigate to specific headings.

If headings are used correctly the navigation of the hierarchy ultimately means users understand the structure of the page in a non-visual way.

There are six levels of headings available to structure the sections of a webpage. Even though six levels exist they don’t all need to be used, use as many heading levels as is appropriate.

Pages should apply headings in a logical order. A heading one <h1> is the most important and is the title of the page, think of it as the master heading for the document, and importantly a page must only ever have one heading level one element.

Following a heading one element is a heading two <h2>, heading three <h3>, <h4>, <h5> and <h6> with each level denoting a subsection of content from the previous parent heading level. Heading three content is the subsection of heading two content which is a subsection from the main heading one.

Before adding a new heading level decide if a new level is in fact appropriate. Is new content being introduced or is it a continuation of previous content and more detailed?

If it's new content, a further heading of the same level is probably more appropriate, if the new content is a continuation from the previous heading level and is more detailed again this is where you would step down to the next level in the sequence.

For example, if the previous heading level was two, and you had content which was more detailed but still part of the theme of the previous heading you would nest it under a heading three, as its related content and going into more detail.

Heading levels must always be used in sequence and skipping heading levels must be avoided. Screen reader users rely on the document structure to understand the page hierarchy, if levels are skipped it can make it difficult for a user to understand relationships. That said, the only time it is acceptable to skip heading levels is when closing a section. For instance, a heading two <h2> can follow a heading four <h4> when it is in a new beginning section.

Providing heading levels for webpages satisfies the HTML specific technique H42: Using h1-h6 to identify headings as a relationship has been established which is conveyed visually by a different font size and style and is programmatically identifiable as well using heading elements. Which means this passes 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text at level A.

I explained how heading elements provide a navigable hierarchy for screen reader and other assistive technology users. The heading elements must be coded correctly and in sequence otherwise the hierarchy will be difficult to understand.

Headings must be used in a logical order with heading one as the first primary page heading, followed by a heading two, three, four, five and six. Even though there are six heading levels they don’t all need to be used, use as many as is appropriate for your content.

If you want to stay up to date with web accessibility and to learn cutting edge techniques, consider subscribing and click the bell icon to be notified when new videos are uploaded.

Avoid an Artificial Tabindex

2020-08-03T00:00:00Z

Transcript

Every interactive element on a webpage receives keyboard focus when the user presses the tab key. That is unless the attribute tabindex is added to elements. When the value of tabindex is artificially altered and used incorrectly it causes many headaches.

In this lecture I'll discuss the tabindex attribute, an attribute that has the power to really ruin the logical tab order of any webpage. I'll explain the implied tab ordering of interactive components, how this can be changed using tabindex and show how the values of -1 can be used to restrict keyboard focus from hidden elements and a value of 0 creates a sequential ordering sequence.

By the end of this lecture you'll understand how an incorrect tabindex value can adversely affect the keyboard navigation of a webpage. You'll be able to hide content from the keyboard tab sequence using the value -1, introduce content into the regular keyboard sequence using a value of 0 and understand nothing good ever comes from a positive tabindex value.

Every tab key press advances the screen focus one position to the right onto the next interactive element. Links and form controls have an implied focus and these elements receive screen focus in the order they're laid out on screen.

This ordering begins at the very first interactive element and is at the top of the screen before moving across and down in a sort of Z pattern, depending how a page is structured.

The tabindex attribute on elements can be used to reorder the sequence in which interactive elements receive focus. Elements laid out on screen in no particular order receive keyboard focus in the same way they are displayed visually, and it's how users expect the behaviour to work.

The tabindex attribute accepts three possible values, -1, 0 and 1 and above. The most problematic values are 1 and above, the positive numbers bring negative outcomes.

Adding tabindex=-1 to any element removes it from the documents tab order and renders it unfocusable from the keyboard. Elements with a tabindex of -1 are displayed to the screen as expected so nothing visual changes, but when navigating via the keyboard, these elements which should be natively focusable from the keyboard are now ignored.

Using this value is useful to alter the focus sequence on elements. links in a hamburger menu where many of the navigation links are hidden in a popout menu aren't required to be focusable until the menu is shown. When the menu is shown tabindex=-1 is replaced with tabindex=0 and the items are now focusable.

Tabindex=0 will allow a component to become focusable and part of the documents natural tab sequence. Native HTML elements provide this behaviour as standard and the attribute isn't required to be added to those elements. If it is added it won't change anything to an ordinarily focusable element, but it is redundant.

This attribute and value are used when custom components are developed. Custom components constructed with DIV and SPAN elements don’t receive keyboard focus natively because the span and div elements are non-semantic and have no meaning. Adding a tabindex=0 onto the element fixes this and allows the elements to become focusable and its focusable in the order it's laid out onscreen.

But when using regular interactive HTML elements, it's unlikely this attribute and value would need to be used as the behaviour is default.

Tabindex=1 and above, this is the problem value. Users expect the focus elements on a page to be navigable from the keyboard in a sequential order. How elements are laid out on screen should be how they receive focus. But this all changes with a tabindex value of 1 or above, this is repurposing the elements natural tabindex ordering.

Elements with a tabindex=1 and above take precedence when the tab key is pressed, and they have an elevated priority to be focused first. Interactive elements which may be laid out visually at the very top of the page will not be tabbed to first and instead any elements with a positive tabindex will be focusable first. Confusing isn't it?

When all links in the footer region of a page have positive tabindex values, the value elevates the focus priority of elements. A user tabbing through the page would tab to these links first before the focus jumps to the top of the page to focus on links which don’t have the tabindex value. This small change has resulted in the page becoming a confusing sequence of tab positions.

A positive sequential tabindex can be used on every interactive element and this will result in in a logical focus sequence if it also matches the visual order. But this behaviour is already available when regular interactive elements are used which already have an implied tabindex=0 value.

Avoid tabindex values of 1 and above, unless used very carefully it can end up making a page really difficult to understand and navigate around.

Avoiding an artificial tabindex on interactive elements satisfies the general technique G59: Placing the interactive elements in an order that follows sequences and relationships within the content and the HTML specific technique H4: Creating a logical tab order through links, form controls, and objects. Which means this passes 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability at level A.

I explained the tabindex attribute and how its values can have a big impact on the tab ordering sequence of a page. The only values which should be used are -1 and 0. A value of -1 removes the element from the focus sequence and a value of 0 adds the element into the natural document tab sequence. If values of 1 and above are used without understanding how it affects the page focus it can result in the focus order of the page being different to its visual order.

If you want to stay up to date with web accessibility and to learn cutting edge techniques, consider subscribing and click the bell icon to be notified when new videos are uploaded.

Using Azure to help users with lower levels of literacy

2020-08-13T00:00:00Z

*Update 20/10/2021 Since publishing the original post the Immersive Reader demo has been updated with a TailwindCSS UI and fixed text selection

Quick Summary

Immersive reader is a Microsoft Azure cognitive services tool to help a user's ability to understand content on a page.

If complex web content can't be rewritten immersive reader can be a helpful addition to allow users with dyslexia, ADHD and autism to understand complex terms and conform to WCAG 2.1 AAA success criteria.

It's a single API call which displays a dialog containing the page content and a range of reading options including highlighting nouns, verbs and adjectives.

Integration with Boardmaker's picture dictionary provides augmentative and alternative communication (AAC) capability to support users who have difficulty with verbal communication.

Demo

Webpage legalese #

There are often situations where creating content in an organisation is at the mercy of the legal department.

All the good intentions of creating an accessible application can be undone with the insertion of large and difficult to read legalese describing the user's rights and obligations and the organisations limits of liability amongst other things.

You have probably seen it with the terms and conditions for Apple iTunes which stretch to a whopping 19 A4 pages and close to eight thousand words!

Only the most diligent give it anything more than a cursory glance, and if users have lower levels of literacy understanding the content becomes increasingly difficult.

Immersive Reader #

I've been researching cloud technology accessibility tools and Microsoft Azure is previewing a new addition to their suite of cognitive service tools called immersive reader.

This is a tool which can be used to enhance a user's ability to understand content on a page which can be particularly helpful for users with dyslexia, ADHD and autism.

The open Immersive Reader dialog

It's a single API call which displays a dialog containing the page content and a range of reading options.

Understanding of grammar can be enhance with highlighting nouns, verbs, and adjectives whilst the tool has the capability to read aloud the content.

There are also several options for reducing the viewable number of lines, increasing the font size, and selecting one of three fonts all to assist a user's ability to understand content their own way.

AAC Support #

What is particularly impressive is the integration with Boardmaker's picture dictionary, an augmentative and alternative communication (AAC) system which can be used to enhance and support a user's communication.

Picture dictionary is a collection of symbols and icons paired with a word for users who have difficulty communicating verbally, with the symbols and pictures used to describe the situation.

Boardmaker's picture dictionary describing the word 'enhancing' visually

Selecting any word within the immersive reader tool displays an image of that word, along with the ability for the word to be read aloud. This increases the number of ways content can be understood by more users.

Implementation #

The typical implementation of immersive reader onto a web page is with a button adjacent to a block of content. Clicking the immersive reader button will trigger the tool to use the content which has been specified in the Javascript.

However, I wanted to create something a little more contextual, acknowledging users may not want all content loaded into immersive reader and instead allow sentences, sections of sentences or even individual words to be loaded.

The demo uses Apple iTunes terms and conditions for demonstration purposes. The getSelection() Javascript method is used to select any highlighted text either via the keyboard or mouse.

if (window.getSelection)
{
    text = window.getSelection().toString();
}

If no text is highlighted rudimentary error handling is added where the whole container is specified.

if(text == "")
{
    text=$('#default').text();
}
return text;

The immersive reader is then triggered from a button click, equally remappable keyboard controls can be used.

$('button').click(function(){
    handleLaunchImmersiveReader();
});

Reach more WCAG 2.1 SC #

Using the immersive reader can become a way to allow your applications to pass Web Content Accessibility Guidelines (WCAG 2.1) success criteria at greater levels, addressing 3.1.3 Unusual Words, 3.1.5 Reading Level and 3.1.6 Pronunciation all of which are at level AAA.

The traditional approach of creating a glossary of terms and adding in page anchors requires substantial extra resourcing to implement and maintain.

If the content changed in either the glossary or page broken links could begin to creep in. The immersive reader tool can overcome this by being a relatively straightforward addition to the page.

Existing WCAG 2.1 AA support #

In addition, the tool supports existing WCAG 2.1 criteria including keyboard support and accessible names for controls.

Product evaluation #

Katherine McKnight of RTI evaluated immersive reader as part of Microsoft's learning tools to determine if it is useful for enhancing reading and writing.

Research was carried out with several teachers from Bellevue School District in Bellevue, Washington USA with research indicating the tool is a useful addition for reading and writing for elementary, middle and high school students, who range from struggling to above grade-level in their skills.

Special education teachers could see how the tool could be used to help students and adapt the tool for specific students with specific needs.

I have students who have difficulty in both reading and writing…Once I used the tools, I could see how to train students who have other learning disabilities to use them and I could see how to adapt each individual tool for specific purposes for specific students…I did initial trainings and then followed up … to make sure they were practicing on a weekly basis. Then I alerted parents to the tool so that they could support it at home and help kids troubleshoot it and use it independently

However, a special education teacher acknowledges difficulty getting neurodiverse students to become comfortable with using the tool.

It is NOT easy to get Special Ed students to use technology. Often times these are students who struggle with technology use, both the appropriateness—i.e. being on task with it, not choosing to do something they shouldn’t be doing in class—but also being able to navigate; they really struggle with that. While Learning Tools is really easy to understand…the reality is … it was outside of the norm of how they used their technology and because a lot of them just struggle with being able to remember how to access it…Also the voices…a lot of my students have social-emotional challenges and so…things that a neurotypical person could get over, like ‘this voice sounds a little funny,’ they couldn’t get over that. It was really challenging for them, so they wouldn’t listen to it

Should you use it? #

If you can reduce the complexity of your content this is the first step and arguably the most achievable.

However, sometimes particularly in large organisations or government departments legal disclaimers must be displayed and there's no way to avoid this.

In these instances, immersive reader can be a good addition to a website to help users with a range literacy levels to understand your content. But as the research from RTI showed neurodiverse students had difficulty getting used to the voice of the tool.

As a complementary learning aid, its use combined with other technologies including structuring existing web content to conform to WCAG 2.1 is promising, but some users will still experience difficulty and other levels of support need to be considered.

Immersive reader is currently in preview and has zone availability on Australia's East Coast and several regions around the world.

Resources #

Demo
Code
Azure cognitive services Immersive Reader
Immersive reader documentation
Levelling the playing field with Microsoft Learning Tools [PDF]

What's new in the WCAG 2.2 working draft

2020-08-17T00:00:00Z

Quick Summary

The Web Content Accessibility Guidelines (WCAG) 2.2 working draft has been released and is accepting comments until the 18th September 2020.

The Accessibility Guidelines Working Group recommend adopting WCAG 2.2 as the new conformance target to anticipate future policy changes.

In this working draft release there are 9 new success criteria. 4 single A success criteria, 4 double A success criteria and 1 triple A criteria with a stronger focus on cognitive impairments.

As it’s a draft, what's contained should be treated cautiously because it isn't a stable release and may change based on feedback.

The Web Content Accessibility Guidelines (WCAG) 2.2 working draft has been released and is accepting comments until the 18th September 2020. It doesn't deprecate or supersede WCAG 2.0 or WCAG 2.1 but is an extension.

The numbering convention is maintained, and it uses the same conformance model as WCAG 2.0.

The Accessibility Guidelines Working Group recommend sites adopt WCAG 2.2 as the new conformance target even if the formal obligations in your organisation mention previous versions.

This is to anticipate future policy changes and ensure you're better positioned.

As it’s a draft what's contained should be treated cautiously as it isn't a stable release and may change based on feedback.

Generally, the working draft document does give a pretty accurate picture of what new accessibility requirements to expect in the recommendation document due later this year.

In this working draft release there are 9 new success criteria.

4 single A success criteria
4 double A success criteria
1 triple A criteria.

In addition, WCAG 2.1 Success Criterion 2.4.7 Focus Visible has been promoted to a single A technique.

3.3.7 Accessible Authentication (Level A) #

Memorising usernames and passwords can place a high burden for users with some cognitive disabilities.

Users with cognitive impairments relating to memory, reading, numbers and recalling information may have difficulty remembering passwords and usernames.

This success criterion ensures an accessible and easy to use method is available to log in and access content.

A technique to pass this success criterion is to require login input fields have the autocomplete attribute added, and the HTML 5.2 value tokens applied to allow browsers to remember the details.

<label for="username">Username</label>
<input type="text" id="username" autocomplete="username">

<label for="password">Password</label>
<input type="text" id="password" autocomplete="current-password">

If you're already applying these attributes as part of WCAG 2.1 AA conformance then this is one way you've addressed WCAG 2.2 conformance.

2.5.7 Dragging (Level AA) #

Maintaining a constant mouse pressure whilst dragging content such as a slider control can be difficult for users with mobility impairments.

This success criterion ensures all functionality can be achieved using single mouse clicks unless a click and drag operation is essential.

WCAG 2.1 already has a requirement that relates to drag and drop, this success criterion takes that further by ensuring it’s a specific success criterion and it's activated by clicks or taps as well as keyboard events.

A general technique exists (G219) which gives more flexibility to decide how you want to pass the success criterion.

If you had content that operated by dragging, an additional alternative option could be the use of buttons to accomplish the same action.

3.2.6 Findable Help (Level A) #

Users encountering difficulties on a site may not be able to complete their task without further assisted help, such as completing a form, or logging in.

This success criterion ensures a human contact mechanism is available and displayed in the same consistent location throughout the application, and at least one of the following exists:

Human contact details
Human contact mechanism
Self-help option
A fully automated contact mechanism

The human contact details should take the user to the area within the organisation that is responsible for the content and not be a catchall contact point for the whole organisation.

If the self-help option is provided, the help should state no human support is available and should go beyond a search option for the whole site.

If the chatbot option is provided this as well should meet other WCAG 2.1 success criteria. See Accessible chatbot design

2.4.13 Fixed Reference Points (Level A) #

Fixed reference points help users navigate and understand digital page content when magnified where indicators like page numbers may be hidden.

The objective is to provide a way to navigate to static page breaks allowing printed and digital content be synchronised.

This success criterion is primarily for electronic publishing formats including EPUB and PDF and appears to be less relevant for web applications.

2.4.11 Focus Appearance (Minimum) (Level AA) #

Knowing where the screen focus is for vision impaired and keyboard users is critical as it assists navigation. The greater the contrast of the focus state, the easier the component is to see.

This success criterion is closely related to existing WCAG 2.0 success criterion 2.4.7 focus visible and defines a minimum level of visibility.

The focus indicator must be at least a 1px border around the focused area.

For example, a button element 90px wide by 30px tall would have an outer border width of 1px and an effective target area of 240px (90px * 2 – both of the longest edges + 30px * 2 both of the shortest edges).

The border focus effect is probably the most straight forward technique to implement, however other focus effects can be applied including at least an 8px thick line along the shortest edge of the element.

It's important to understand these measurements define the minimum requirements and you're encouraged to go above the minimum and make the effect more prominent.

2.4.12 Focus Appearance (Enhanced) (Level AAA) #

This is the enhanced success criterion for 2.4.11 Focus Appearance and it defines a higher level of visibility for the focus indicator.

It expands the minimum area around the focused area to 2px, Increases the change of contrast to 4.5:1 and does not allow any part of the element to be obscured.

A visible border effect once again is the most straight forward technique to apply. As this is at a greater WCAG conformance level it emphasises a 2px border thickness.

A button element 90px wide by 30px tall would have an outer border thickness of 2px and an effective target area of 244px.

3.2.7 Hidden Controls (Level AA) #

Users with cognitive impairments may have difficulty finding controls if they are selectively hidden as part of the screen design when progressing through a workflow.

This success criterion ensures all controls which are part of advancing through a workflow are always visible without requiring user interaction.

However, it doesn’t require inactive controls to be visible all the time. So, for example a submit button which is conditionally visible when all fields are completed is acceptable.

Video players and other content which have an overlay visible only on hover and are not part of a workflow don’t require the controls to always be visible.

However, if the video player is part of the workflow, for example a person must watch a video to progress then those controls need to be always visible.

2.5.8 Pointer Target Spacing (Level AA) #

Users with hand tremors, limited dexterity or fine motor movement challenges may accidentally activate adjacent controls if the target area is small.

Additionally, users with a touch screen device can also be affected due to a narrow control activation area.

This success criterion features in WCAG 2.1 AAA criteria and has been promoted to WCAG 2.2 AA.

It ensures that any target activation area on links and form controls is at least 44px wide by 44px tall.

This isn't to say a target area alone must be those dimensions but the target area and the white space surrounding it must add up to 44px in both directions.

.enhanced-target
{
	min-width: 44px;
	min-height: 44px;
}

The CSS technique min-width and min-height is a straightforward way to ensure adequate spacing is applied to targets and the properties are very well supported in all major browsers.

3.3.8 Redundant entry (Level A) #

Users with short term memory difficulties or cognitive impairments may have difficulty recalling information multiple times as part of a workflow.

Additionally, all users encounter gradual mental fatigue if asked for the same information multiple times.

This success criterion ensures that any information the user has entered as part of the current session is persisted and used again if there is a requirement for further data entry of the same information.

There are exceptions to this success criterion where password entry and games involving the user's memory wouldn’t be in scope.

Summary #

It's good to see users with cognitive impairments are increasingly better supported with improved authentication techniques. Ensuring controls remain visible when navigating a workflow and persisting user's information throughout the current session.

Whilst more support is provided not all users will benefit from these techniques and will still require support from alternative ways.

A surprising addition is success criterion 3.2.6 Findable Help. The Accessibility Guidelines Working Group perhaps recognise a user's accessibility support request can become lost in large organisations.

The traditional approach of a contact us form or email link can result in a request being redirected, and this technique provides several options for immediate support when the user requires it.

Add Labels to Controls

2020-08-24T00:00:00Z

Transcript

Nearly all form elements need a label. Without a label form controls that receive keyboard focus will only announce the type of control to the screen reader user not what type of data is required. When a label doesn’t provide enough information describing what to enter, more errors are likely.

In this lecture I'll explain the label element and show how correctly labelling controls makes it much easier for a screen reader user to understand the type of data a control requires.

I'll use the FOR and ID attributes to create a programmatic relationship between labels and form controls, this programmatic relationship means when the control receives keyboard focus the label element will be announced automatically by the screen reader.

By the end of this lecture you'll understand why labels are critical in helping a user understand the type of input a form control requires and you'll know how to use the FOR and ID attributes to create a programmatic relationship which triggers the screen reader to announce the label when the control receives keyboard focus.

When form controls receive keyboard focus, the screen reader will announce the type of control. Form controls often have a text label adjacent to the control which gives the user a hint as to what type of information is required, if the input control had a label of first name, you'd know that that control accepts a first name.

However, just relying on physical placement of the label to provide that information means screen reader users won't be able to understand what type of data the control requires.

When the control receives focus it will only announce the type of input control not the adjacent label, the screen reader may announce “input type and text”. It's an input control and the type of input is text, the screen reader user is aware a control is there but not what data the control requires because the label hasn't been programmatically associated to the control. Because the label is not programmatically associated, the label remains unannounced effectively hidden.

Creating a relationship between a label element and the input control overcomes this by using the FOR attribute on the label element with the ID of the form control. In this example the ID of the input control is "firstname" and this is the value in the FOR attribute on the label. A programmatic relationship is then created, this establishes a physical connection which the screen reader can use when the form control receives focus.

When the same process of navigating through the form is repeated. On keyboard focus the screen reader will announce the text label describing the type of input required for the control, providing a really clear indication that the control is for a certain type of data. In our example it will announce “first name input type and text”.

Not all form controls require an explicitly associated label, the following controls do require a label:

Text input
Checkbox
Radio button
File upload
Password
Textarea
Select

Several controls don’t require a label, as a text description is provided by the value attribute of the control, the ALT attribute or content within the element:

Submit and reset buttons have a text description provide by the value attribute
Image buttons have the description provided by the ALT attribute of the control
Hidden input fields don’t require a text description
Button elements have the description provide by the enclosed text

An additional benefit of programmatically associating a label to a form control is it provides a larger clickable area for the control. Rather than just clicking within the control to activate it, the activation can now happen from either the label or the control which is especially helpful for users with dexterity problems as it presents a large clickable area.

Using programmatically associated labels with form controls satisfies the HTML specific technique H44 Using label elements to associate text labels with form controls which means this has passed success criterion 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text at level A.

Using programmatically associated labels with form controls is a nice quick win to improve the accessibility of online forms. I showed how to associate a label to a form control using the FOR and ID attributes, explained which form controls require a label and which don’t and describe an additional benefit of a larger clickable area to activate a control.

If you want to stay up to date with web accessibility and to learn cutting edge techniques, consider subscribing and click the bell icon to be notified when new videos are uploaded.

Stopping the bots with Javascript

2020-09-14T00:00:00Z

Quick Summary

CAPTCHA is a convenient go to technique for stopping spam, but it's also inaccessible. Using Javascript to remove critical form attributes, loading form content dynamically and replacing submit buttons can be an effective alternative which maintains your sites accessibility.

Previously I had used .NET MVC as the framework for the CANAXESS website. The contact form had to be accessible and couldn’t rely on any plugin which would adversely affect a user's ability to contact us. The form had a CSS hidden form field using the honeypot technique and server side logic rejecting all submissions if the form field contained data.

The theory being bots can't understand what's a legitimate field and what's not and so the bot identifies and completes all input fields and sends the form. If the field contains data, we assume that as a user hasn’t been able to navigate to the hidden form field, a user hasn’t submitted the form and discard the entire input.

Honeypot techniques are always identified as an effective way to stop spam emails and for me the technique worked ok to reduce the spam to a manageable level a day. Within my mail client I would select all the spam emails and delete them on mass, all pretty straight forward if time consuming.

Moving to Netlify #

As part of changing infrastructure, the CANAXESS website was moved to Netlify which meant the existing spam filtering technique relied upon would have to be rethought as the previous site was built in .NET and hosted in a .NET environment.

Initially I opted to go for no spam protection and just see how it went. As you'd expect the spam posts came thick and fast.

Using a honeypot #

Netlify provide a honeypot feature that follows the same technique of using a hidden input field and if this is prefilled all emails get sent to the spam folder.

<form name="contactSubmission" id="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">
<input class="actual-hidden" name="bot-field" tabindex="-1">

The technique worked very effectively; no legitimate emails were ever reaching the regular email folder.

But the spam folder told another story. There were pages of spam results, where previously I could select all emails on mass and delete, the Netlify approach meant only 10-20 emails were returned at a time with paging used to move to the next ten emails. There was no mass delete feature and I had to delete individual ones.

This was incredibly time consuming and tedious. I wrote a Javascript bookmarklet which I hoped would make it easier to check all checkbox controls on the page and delete all records.

Unfortunately, the page logic wasn’t recognising my bookmarklet as having physically interacted with each control and wouldn’t allow selection of all emails on mass.

I also couldn’t be sure if any emails in the spam folder were false positives - incorrectly identified emails, which meant I had to trawl through all emails to confirm.

Discounting reCAPTCHA #

Netlify provide Google reCAPTCHA and I initially did consider its use as the emails were increasing daily.

However, the perception of a web accessibility company using a known inaccessible method for people to contact them wasn’t a good look.

I've written previously about how terrible a technique CAPTCHA is for undermining the accessibility of a website and thought if I couldn’t solve this problem what hope is there for others.

I decided to program my way out of it.

Make the form less attractive to bots #

I needed to make the contact form look less like a contact form and less attractive to bots. I began removing the method attribute on the form element. If there is no method attribute, I figured the form couldn't be sent.

<form name="contactSubmission" id="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">

Unfortunately, even though the attribute was removed, Netlify applied the method attribute back onto the form as the site was deployed and this was something I couldn’t control.

<form name="contactSubmission" id="contactSubmission" method="post">

Using jQuery to remove an attribute #

I decided to use Javascript (jQuery) to dynamically remove the method attribute after the page had loaded. Using the jQuery ready event, the form element is selected, and the method attribute is removed.

$(function(){
    $("#contactSubmission").removeAttr("method");
});

I then required a way to add the attribute back onto the form element before sending. I had to add it back in a sequence to make sure the attribute exists before the form is sent otherwise the form will error out and the user will encounter a broken contact form, hardly ideal!

Replacing the submit button #

Additionally, I had decided to remove the submit button as well. Figuring if there was no submit button the form can't be submitted via a headless browser (if spammers used that technique) as it looks less like a contact form and more like a collection of input fields.

Form submission would take place via a regular button element programmatically only.

<input type="button" value="Contact CANAXESS" 
class="contactForm-button submit">

Adding the method attribute on submit #

The regular button had a click event handler which added the method attribute and value back onto the form element.

When the button is clicked the attribute is added, but there may be instances where the timing of script elements happens contrary to how I wanted it to.

To overcome this, I added a timer interval. This repeatedly checks the form element for the method attribute every 100 milliseconds, if no method attribute exists the form isn't submitted.

$("input.contactForm-button").click(function(){
        $("#contactSubmission").attr("method", "post");
    
        var checkExist = setInterval(function(){      
            var attr = $("#contactSubmission").attr("method");
            if (typeof attr !== typeof undefined && attr !== false)
            {
                $("#contactSubmission").submit();
                clearInterval(checkExist);
            }
        }, 100);
    });

Form submission only occurs when the method attribute exists, and this would occur programmatically. When the form had been submitted the interval timer would end.

clearInterval(checkExist);

I thought this was a pretty effective way of over engineering a contact form to stop bots, but my confidence wasn’t to last. I came back a few hours later to find spam emails collecting again.

Form submission is happening via HTTP #

And then it dawned on me, bots probably aren’t even visiting the page via the browser, they don’t care for all the jQuery script which runs on the clientside removing elements.

The method attribute exists when the page is loaded, and from there it’s a simple scrape of the HTML and submission of the form via a HTTP post without ever interacting with the page.

And it was this realisation which then made me identify the technique that would not just slow down the spam emails but stop them. Since applying this technique I've had no emails, none, zilch.

Separating the page from the form #

The technique is loading the form fragment via Javascript after the page has loaded. Realising spam bots probably aren’t using a headless browser to navigate the contact page and submit the form I instead made the form only appear when the page has been loaded from a browser.

The contact page rendered in the browser is one page, but is in reality is composed of two parts. The main page with a placeholder for the form component and the form content itself.

<div id="formContainer"></div>

Loading the form on page load #

When the page is loaded, a jQuery ready event loads the additional form fragment into the form container DIV almost immediately.

The form fragment page is never identified by a bot as the initial page the bot is seeing has no form element, this is only loaded after the page has loaded through Javascript.

<script>

$(function(){
    $("#formContainer").load("formfragment.html");
});

</script>

In summary #

The technique does require Javascript to operate. As Javascript has become an accepted part of web development I think it’s a realistic solution to stopping spam in certain specific situations.

The other technique of using honeypot fields is always problematic as from my experience it wasn’t that effective.

Spam would still find a way through and if I'm honest the honeypot technique can only be classed as a spam limiter, reducing the instances of spam getting through.

Whilst using CAPTCHA would work and be a quick fix, its use is undermining making the web accessible for people with disabilities.

By removing the contact form from being rendered as part of a regular HTTP get request, its visibility to bots appears to be significantly reduced and therefor reduces (and in my instance has stopped) bots from being able to submit spam through the contact form.

Things for you to try #

Regardless of the framework your site is using, if your contact form is being compromised by spam try these approaches:

Separate the page and the form
Load the form after the page has loaded
Only submit forms programmatically using button elements
Remove the method attribute on forms and add them as part of the form submission

Not another checklist!

2020-11-20T00:00:00Z

Resources

Read the entire transcript
Check out the repository for code snippets and a starter spreadsheet

Here's how to get the best accessibility review

2021-04-24T00:00:00Z

You've built your website but you're not sure if its meets WCAG conformance? This is where a review can help you understand if your website is accessible and if not what you can do.

The first step

An accessibility review is the first step in understanding how accessible your website is. A review for an averaged sized site of 10-15 pages takes approximately 2.5 weeks to complete where your website and the HTML, CSS and Javascript code which make up your site is analysed against the web content accessibility guidelines (WCAG).

There are 50 success criteria in the latest version of WCAG, and these are tests which are used to determine if your site passes.

These are things like do images have a text alternative for people who use a screen reader, are colour contrasts correct all the way to testing whether forms have messages describing why an error has occurred.

The essence of a good review

A good review identifies if errors exist and where on the site the errors are. The implication for a user by assigning a severity level - in essence whether it's a large or a small problem helping you prioritise which to fix first and, most importantly the review provides a solution to how you and your team can fix the errors.

How the review is performed is crucial in making sure you're getting value for money.

A good review uses automated tools in the browser followed by an in-depth manual code review by an expert reviewer, as automated tools alone won't find all accessibility issues.

Websites have lots of tech in use

If a reviewer doesn’t understand this technology, they may identify "errors" which aren’t or give undue prominence to easy to find WCAG failures whilst ignoring more complicated challenges, potentially the things which will really affect users being able to use your website.

How much a review costs can vary a lot, but don’t think the more you pay the better the review is. What matters is the technical detail, look for reviewers who have a technical background, are familiar with how websites are built and know web accessibility.

As a rough estimate expect to pay somewhere in the region of about $6-8000 AUD for a good web accessibility review, and that generally is testing approximately 15 pages.

We're proud of our review process

We apply 96 individual tests over each page of your site, giving you an accurate picture of how accessible your website is. We're also developers.

As well as describing accessibility problems we provide in-depth code solutions in HTML, CSS and Javascript giving your developers actionable accessible code ready to use.

We identify accessibility errors, rank them by severity, and provide solutions which fix those errors making your website accessible and conformant to the latest WCAG version all detailed in an easy to understand report.

Contact us to understand the accessibility of your own site and move from accessibility unknowns to actionable information and WCAG conformance.

How to create a session timeout using ARIA, CSS and JQuery

2021-05-24T00:00:00Z

A session timeout message is a common UI design pattern in web applications where authenticated users are logged out after a period of inactivity.

WCAG 2.1 provides two relevant success criteria for this pattern. Success criteria 2.2.1 Timing Adjustable ensure users with disabilities are given adequate time to interact with web content whenever possible, and success criteria 4.1.3 Status Messages make users aware of important changes in content that is not given focus.

A robust accessible timeout message pattern which conforms to WCAG 2.1 can be created when these two success criteria are combined.

Check out the full example on Glitch.

The term "status message"

Status message as a term is defined in WCAG and can only be applied to clearly defined examples. Things like search results loading into the same page, or validation messages being shown, basically actions which add text to the screen without a full-page refresh and without focus are status messages.

Non-status messages however could be triggering the screen to reload, or displaying a message in a dialog box. These are not status messages since in these two instances the dialog has taken focus or a change of context has occurred - a screen reloading for example, causing the screen reader to be refreshed.

The markup

Two live regions are created on the page using DIV elements with role=alert for the alert indicating the page is 20 seconds from timing out and the session ending and role=status for a status message indicating the completion of the timeout.

<div id="timeoutWarning" role="alert">
	<div class="hidden">
		<h2>Do you wish to continue?</h2>
		<p>Your session is 20 seconds away from ending, please press the spacebar to continue.</p>
	</div>
</div>

<div id="timeoutEnd" role="status">
	<div class="hidden">
		<h2>Your session has ended</h2>
		<p>You did not indicate you wished to continue and your session has ended.</p>
	</div>
</div>

20 seconds as a minimum for extending the timeout was based on clinical experience for Success Criterion 2.2.1: Timing Adjustable.

20 seconds to hit 'any switch' is sufficient for almost all users including those with spasticity. Some would fail, but some would fail all lengths of time. A reasonable period for requesting more time is required since an arbitrarily long time can provide security risks to all users, including those with disabilities, for some applications.

Don't hide the entire live region

An approach initially taken was hiding both parent div containers using the CSS property display:none and toggling each style showing each message when appropriate.

However showing an entire hidden live region container triggered inconsistent output in screen readers. The role=alert message would always be announced but role=status wouldn't.

This could be overcome by adding a fallback aria-live="assertive" attribute but this begins moving away from the spirit of accessibility into the territory of making it work using whatever live region works.

This Irregular screen reader behaviour could have just been on one screen reader, but testing it on both JAWS and NVDA and in the browsers Chrome and Firefox showed (or in this case not) the same result, and this is confirmed against the guidance that a live region container must always exist on the page on startup to work correctly.

Hidden from the accessibility DOM

Whilst the live region existed on the page, using the display:none CSS property effectively removed it from the Accessibility DOM and for the screen reader to identify and communicate its changed state.

.hidden
{
    display:none;
}

Toggling the display:none CSS property will make the live region visible but won't consistently trigger the output to the screen reader.

This was overcome by only toggling the visibility of the content within the live region container and showing it when necessary, since it is the content that is changing not the container for the content.

A little JQuery for interaction

Using JQuery to show the warning message at 20 seconds enables an event handler to become active only when the warning is shown since we don't want to trap for the spacebar all the time.

if(timeLimit==20)
{
	
	$("#timeoutWarning").addClass("alert alert-warning");
	$("#timeoutWarning>div").removeClass("hidden");

	$("body").keypress(function(e){
		if(e.keyCode == 32){
			clearInterval(timerObject);
			$("body").off("keypress");

			$("#timeoutWarning").removeClass("alert alert-primary");

			$("#timeoutWarning>div").addClass("hidden");
			$("#timeoutEnd>div").addClass("hidden");
			$("#start_countDown").addClass("hidden");
		}
	});
}

If the spacebar (key code 32) is pressed the timer event ends removing any countdown messages from display.

If however the spacebar isn't caught, and the timeout ends the warning message is hidden by toggling the CSS class (just the message not the entire container) and replaced with a status message indicating the progress of the timeout is complete.

The user can then be logged out or redirected or whatever the action you want the user to follow up with.

The spacebar was trapped only to ensure any hotkeys for the screen reader aren't affected, the keyboard commands for JAWS and NVDA identify the spacebar alone as not being a hotkey and less likely to override screen reader keys.

Why two different aria live region roles?

The first message is a warning of an approaching timeout within 20 seconds whereas the next message describes the users session has timed out and is part of a complete process and so role=status is used.

We're free to user any aria roles of log, status or alert in whichever combination but by going against the WCAG 2.1 guidance means we're at risk of introducing unexpected behaviour in the screen reader and assistive technology.

Key takeaways

Status messages are a clearly defined term in WCAG 2.1. Use the appropriate aria roles for warning of an approaching timeout alert and the completion of a timeout status.

Using display:none allows us to work with the behaviour of the screen reader to ignore text until we want it to be outputted, but crucially only hide the text of the timeout message not the entire container to prevent inconsistent screen reader behaviour from occurring.

Check out the full example on Glitch.

Screen reader results

	NVDA 2019	JAWS 2021	VoiceOver	TalkBack 9.1	Voice Assistant
Chrome 90	pass	pass	n/a	n/a	n/a
Firefox 88	partial	partial	n/a	n/a	n/a
Edge (Chromium) 90	pass	pass	n/a	n/a	n/a
Internet Explorer 11	fail	fail	n/a	n/a	n/a
Safari iOS 14.3	n/a	n/a	pass	n/a	n/a
Chrome Android 10	n/a	n/a	n/a	pass	partial

Voice Assistant in Chrome Android 10 does not announce <h2> within live region container
NVDA and Firefox does not announce <h2> within live region container for role="alert"
JAWS and Firefox does not announce the live region container with role="status"
Internet Explorer 11 does not announce any of the live region containers

Link labels to form controls using the FOR and ID attributes

2021-07-03T00:00:00Z

Resources

Read the entire transcript
Check out the Exercise repository

Using screen readers to evaluate the compatibility of a website

2021-09-24T00:00:00Z

Summary

Blogs and articles discuss testing with a screen reader as being a vitally important part of creating accessible digital experiences. But these same blogs and articles jump into which commands to use in the screen reader and not necessarily what to test or how to interpret the results. It's a little like baking a cake, where you have the ingredients but not the instructions

A structured approach towards screen reader testing means where time is often limited, our efforts are focused on the critical parts of the digital experience. The things which users will use and interact with rather than the static components like headings and lists which are picked up earlier in the development cycle.

This approach is ultimately compatibility testing. It's identifying whether unusual behaviour identified in one browser and screen reader combination is due to poor coding practice or a quirk of the combination. It's confirming, if it's coded correctly and tested comprehensively against all the combinations potential problems can be escalated or ignored. We're not chasing our tail fixing behaviour in one combination which is a quirk and not a legitimate bug.

Resources

Check out the Repository

Gotta Catch 'Em All

2021-12-20T00:00:00Z

Automating accessibility testing is a convenient way to catch low hanging accessibility vulnerabilities. It can't find all accessibility problems though and conservative estimates indicates less than 30% of the total WCAG failures are identified. But when automated testing is introduced into your workflow some issues can be identified in a consistent way quickly.

When solutions are hosted on GitHub, GitHub actions can be leveraged to run every time a commit is made, or a Pull Request accepted. Cursory accessibility checks can be automatically carried out ensuring many straightforward accessibility issues haven’t crept and deployment is halted if accessibility problems are found.

Setting it up

Within a project create the folder .github/workflows in the root directory. This is where the GitHub action will reside. We're using the pa11y accessibility engine, and create the file pa11y.yml.

The name of the action is set to pa11y and specifies which Continuous Integration events the tests are run against. In this instance the test will run against push and pull requests to the main branch.

name: pa11y
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

Generic boilerplate configuration exists for the virtual machine workflow, this pulls down dependencies and specifies the version of node.

There are several steps which run the build command within the projects package.json outputting the compiled solution to the /dist/ folder. This is followed by the start command which creates a http-server using the /dist/ folder as the source directory.

- run: npm run build --if-present
- run: npm start & npx wait-on http://localhost:8080

Pa11y is installed on the virtual machine runner and the pa11y accessibility engine is run against the localhost created from the compiled solution in the /dist/ folder.

run: |
    npm install -g pa11y
    pa11y http://localhost:8080

The Actions tab within GitHub lists this workflow, the branch it's run against and whether it has run successfully.

GitHub actions listing all actions created

Clicking through to the jobs output lists in the console or steps that been run. For this demo a deliberate accessibility error has been introduced. The boilerplate HTML the Action runs is missing title text and this is shown in the pa11y output.

pa11y error output

The panacea for time consuming audits?

Just before you think this solves accessibility in your project, it's time to be realistic. It doesn't. At best it finds low hanging accessibility issues in a consistent way which may have been missed.

It lacks the ability to identify accessibility failings with complex functionality or even WCAG issues that require a nuanced understanding. Pa11y, in fact any automated testing tool won't uncover whether appropriate ALT text exists on descriptive images, an expert reviewer is still required.

But if your accessibility maturity is low, this can be a good initial addition to the development lifecycle as the effort to implement a rudimentary accessibility check is modest.

Think of this as a layered defence towards inaccessible code reaching the production environment.

When this is used in combination with many other accessibility efforts including manual auditing, browser, and AT compatibility testing, and testing with users it results in a consistent way to reduce syntactic accessibility issues from creeping into production.

Resources

Check out the Repository
Automating the accessibility tests of your source code with GitHub Actions

The challenge interpreting WCAG

2022-02-21T00:00:00Z

Understanding which accessibility guidelines apply when building digital services isn't easy. Differences in how two people interpret guidelines, differences in opinion with what constitutes a failure and even best practice accessibility principles all get combined into a lot of unclear approaches.

So, we created www.thisiswcag.com to help teams encourage testing against WCAG 2.1 success criteria using plain language. It's a deliberately catchy name to try and make it easier to understand how to interpret success criteria.

www.thisiswcag.com is a starting point when building against WCAG 2.1. Many of the tests have made arbitrary decisions for things which must be done to be conformant. Regular community feedback is shaping each of the tests to give sufficient guidance for people new to accessibility yet flexible enough for alternative techniques to be applied.

It’s a separate community effort where if you disagree with any of the tests there’s several ways to contribute to help make them better. We wanted to encourage teams to move away from statements of "I think it means this…" when discussing WCAG and to establish a consistent set of tests which are clear to understand and unambiguous.

These tests are based on the intent of the success criteria, not the sufficient techniques. Sufficient techniques are identified ways which describe how a success criterion can be passed, but by unpicking the intent means we get to the core of what each success criteria really means.

This establishes a baseline, and a common vocabulary of what WCAG means. This isn't replacing best practice accessibility; rather best practice includes building to WCAG consistently and then beyond.

Resources

Check out the www.thisiswcag.com
Check out the Repository

Effective live regions to convey the loading state of your web app

2022-05-17T00:00:00Z

Summary

Single Page Applications have a rocky history with web accessibility. Dynamically loading page content won't be outputted by assistive technology without using an aria live region. But just adding a live region alone isn't the end of the problem, any text to describe the loading needs to be continuously communicated for the length of time the loading is taking place.

I'll show you a technique how to use an aria live region effectively, the pitfalls to avoid and how this simple pattern can be used to great effect to describe your web app's loading state.

Resources

Check out the Repository

High standards and the quest for perfection

2022-10-03T00:00:00Z

A fictional celebrity chef and a former British special forces soldier and their attitude to success embody the qualities to succeed with web accessibility.

A temperamental fictional chef

The film Burnt stars Bradley Cooper as Adam Jones. A temperamental celebrity chef striving to do the absolute best in his kitchen.

Demanding perfection from his staff with the food they are cooking. This all comes undone when what he believes are Michelin reviewers arrive at his restaurant.

The food ends up being sabotaged by his sous chef Michel in revenge for ruining Michel's reputation in Paris many years earlier.

What follows is a classic redemption story. Adam wins around his alienated kitchen by being humble and working collaboratively.

When the Michelin reviewers do arrive in the restaurant several weeks later – the first people were businessmen unconnected to Michelin, there is a nervous activity from the kitchen staff and Adam calmly replies, "we do what we do".

Being humble and working collaboratively with the Kitchen he delivers a Michelin-starred experience and redemption from the kitchen staff.

A decorated special forces soldier

Mark Billingham is a decorated British special forces soldier who appears as the directing staff on the reality TV show SAS Who Dares Wins in Australia and the UK.

His attitude to challenging situations is "a little bit further", meaning don’t make unrealistic goals of achieving absolute perfection but do something a little bit better than yesterday. A little bit more effort than normal.

The perfection millstone around the neck

What these two people demonstrate is a willingness to perform better than yesterday but accept that striving for perfection becomes an unattainable goal, an Achilles heel.

Which instead of contributing positively to progress in fact becomes a hindrance and the millstone around the neck.

Working in accessibility can mean we get in the mindset of expecting absolute perfection when supporting accessible digital project development.

Headings might be incorrectly rendered on a page. And to us, this becomes unforgivable and a further slight on those users with disabilities who need that support the most.

We become blinkered and unflinching in demanding absolute accessibility perfection from any digital project.

Regardless of the technical challenges or knowledge gaps from the colleagues, we work with. This attitude becomes untenable and alienates us from the goal of improving digital accessibility.

Reinforcing the perspective that accessibility is hard.

Moving forward by doing a little bit more

Working to our best abilities and doing a little more than yesterday means progress IS being made. The forward direction is better than striving for the absolute best and not making any progress at all.

We sometimes make recommendations that are not taken on board. Or emphasise the challenges of progressing with a flawed UI design pattern that is ignored.

The mantra "We do what we do" underlines that we can only control the things which we do. Sometimes things don’t go the way we want, there are things outside of our control that we can't influence and that’s ok.

We do what we do, we work collaboratively and accept sometimes that decisions go against us.

Sarah Edelman in her book "Change your thinking" sums up this desire for perfection and the negative consequences best.

"While having high standards can have its benefits, the belief that things must be done perfectly is anxiety-producing, because of the ongoing possibility that we will not live up to our expectations. Perfectionist attitudes often cause procrastination, as the fear of falling short makes it hard to get started. It also makes us inefficient, as our inability to say 'That's good enough' causes us to spend too much time on tasks that don't warrant it"

Change your thinking – Sarah Edelman Phd

Good enough, is good enough

For accessibility do a little bit more than yesterday, do it well, and "we do what we do". If you find yourself not making progress re-evaluate your expectations.

You may just be aiming for an unattainable goal of perfection when in reality good enough is just that, good enough.

How Australian supermarket Coles creates accessible user stories

2023-03-23T00:00:00Z

Creating user stories with included accessibility information is hard. Is so much accessibility detail added into each story describing how a developer creates it? or just reference WCAG and hope that by osmosis the requirements appear in the finished feature?

Accessibility needs to be an integral part. But accessibility specialists in organisations are so few and often support many teams. Each team creates user stories for new features. And it becomes challenging balancing the accessibility needs of the teams, with the limited resources of a central accessibility team.

Unnecessary navel-gazing

The best intentions begin where accessibility guidelines are meticulously described in each user story with coded samples acting as instructions for a developer to apply. But this is the problem, it's navel-gazing.

There's a tendency for us to write requirements for accessibility experts and we end up writing so much information and technical detail that's added to the user story.

But when the features become more numerous, this approach begins to slow down. And ultimately devolves into hastily copied code, or referencing WCAG guidelines which are incredibly difficult to understand for non-accessibility people and time-poor developers.

Overly comprehensive accessibility requirements become separated and de-prioritised. With the familiar argument of accessibility being too hard thrown around!

There just aren’t enough hours in the day for accessibility to be described in depth for developers to apply and confidently carried through into a finished feature.

Guard rails and an undefined solution

Accessibility Acceptance Criteria (AAC) are one solution to this problem.

AACs are broad accessibility criteria applied when user stories are created. Instead of developer-focused, they’re BA-focused. And describe key behaviours the finished feature needs to display – an outcome, but they don’t go so far as in specifying how to do it.

Instead, they act as guard rails allowing a developer to implement the feature in any possible way, if the outcome is met.

They define the boundaries of a user story and are used to confirm when a story is complete and working as intended. They're written in plain language and easily understood by members of a team who have different expertise and varying levels of fluency in each other’s technical jargon.

They've been used incredibly effectively at the Australian supermarket Coles. We worked together with Accessibility Manager Mel O'Brien and the accessibility team to identify which WCAG criteria would be the most important to document.

Avoid reproducing WCAG

We didn't want to reproduce all 50 success criteria from WCAG in another format. Instead, we settled on 20'ish criteria before this was whittled down to 10.

This balanced the need to document core accessibility behaviour yet not be so taxing for BAs creating requirements.

We chose common failing, high-impact WCAG success criteria to include in the top 10. Each AAC aligns with one or more success criteria. The accessibility acceptance criteria

AAC1 Keyboard Accessibility
AAC2 Content on hover
AAC3 Page title
AAC4 Visible focus
AAC5 Semantic markup used appropriately
AAC6 Form control labelling and inline errors
AAC7 Screen reader
AAC8 Zoom & resize
AAC9 Alt text
AAC10 Orientation & reflow

Each accessibility acceptance criteria follow the format of user + action + outcome and centre the story on the user's requirement.

Generally, people are familiar with keyboard accessibility and the requirements around keyboard focus behaviour are the most straightforward.

AAC 01 Keyboard accessibility

Given I am a keyboard user when I encounter interactive content then I can control it solely from the keyboard.

This AAC maps directly to success criterion 2.1.1 keyboard. But the WCAG success criterion is far more detailed than this, where's the detail? We excluded anything that was difficult to understand, such as requiring specific timings for individual keystrokes and exceptions.

A requirement needs to be easily understood. If all the detail in SC 2.1.1 is documented then really, nothing is improved and WCAG has just been documented in another format.

AAC 07 Screen reader

Dynamic content on a page is captured with AAC 07 Screen reader. The Coles website is very complex and has a lot of parts that change. Text dynamically changes, and notifications announce items have been added to the trolley.

Given I use a screen reader when a visual change occurs on the page then I can understand the change audibly. E.g., search results displaying while searching, errors displaying after activating submit button

This maps to WCAG success criterion 4.1.2 name, role value. It’s a shorthand way to condense all the technical detail in the criterion into something easy to understand.

It doesn't cover everything; its essence however is when the page dynamically updates, the update needs to be conveyed to the screen reader.

The AACs aren't perfect

They leave out a lot of the nuance found in the WCAG success criteria but always aim for progress over perfection. They’re guidelines BAs confidently apply when developing user stories.

How successful have they been?

The AACs have been in use for over a year and over time it was found the handover point from BAs to testers was becoming challenging. Whilst the AACs were clear for BAs they weren't clear from a tester's perspective with a lot of uncertainty about how to test.

A companion document was introduced titled 'testing with the AACs'. This gave testers a consistent approach to interpreting and testing each criterion.

Centring the AACs to a BAs perspective creates a resource better suited to capturing high-level accessibility requirements upfront. Instead of forcing a BA or a Tester to understand technical guidelines the companion resource tailors the AACs to each role using familiar language.

The burden of decoding WCAG shouldn’t be placed on the shoulders of the BAs and Devs. This simplified approach is easy to understand, digest and apply. It accelerates the time new features reach production and ensures core accessibility behaviour is addressed.

The AACs developed by the Coles Accessibility Team were inspired by the UK Government's Government Digital Service (GDS) work detailed in the blog post Improving accessibility with accessibility acceptance criteria.

The Accessibility Acceptance Criteria are kindly shared by Mel O'Brien publicly through GitHub.

Resources

Check out the Repository

Combining Tab and Arrow key navigation for Australian supermarket Coles

2023-04-08T00:00:00Z

Supermarkets spend millions of dollars strategically placing products around the store to make it easier for you to purchase items and impulse buy – that extra bar of chocolate doesn’t make it into your trolley on its own without some gentle encouragement!

Space that isn't used effectively is wasted and costs the company money and the online space is no different.

It's these constraints that accessibility and business objectives become uneasy friends. Where compromises are made to support users and help the business do what it's good at.

And it's these challenges we found working with Coles.

Reusing existing features

The team had a request for the established product search feature on coles.com.au to include items that a customer had bought previously.

When a customer is searching for items, they're reminded of previous purchases. Whilst a win for the customer and business, the approach had significant challenges for accessibility and the user experience.

The existing suggested results combined with the previous purchases component within the search component

The existing search feature was navigable using the arrow keys. A search for "milk" yielded several suggestions each rendered in a DIV element. Pressing the up and down arrow keys and pressing Enter selects the product in focus and triggers a search.

Whilst the bought previously feature reused a component from the product listing page. This component was built using native HTML headings and link elements.

The reused product listing component

Where each product tile is navigable via the Tab key. Using native HTML meant the keyboard focus sequence was how the items were displayed, allowing users to navigate from top to bottom using familiar key presses on the Tab key.

Two different yet valid navigation approaches

Combining these two separate components into one new composite component sounded straightforward. Both had been created with accessibility in mind, both traversable via the keyboard and both supported keyboard interactions.

But this is the problem. The way a user navigates through the two components is fundamentally different. The arrow keys navigate the list for the search results, yet for the product tiles, it's the Tab key.

These are two different yet equally valid ways of navigating for products in two different scenarios. Yet when combined these two ways become opposites, an uneasy mix of two navigation patterns.

So, what to do?

Introducing a new navigation pattern?

We discussed changing the way the user navigates in each component. Could the arrow key navigation in the search results be replaced with the Tab key to better align with the navigation on the product tiles?

It could, but the search results aren't links. They're clickable DIV elements and items to be selected so it feels like the enter key is the right keyboard interaction to maintain.

Besides all users with an established mental model familiar with navigating via arrow keys would be forced to relearn how to navigate. Clearly, that's not a great user experience.

Equally forcing all users to navigate native HTML product tiles (already navigable with the Tab key) via the arrow keys is also a poor user experience.

Sure, the navigation and user experience would be harmonised on the composite search component, but the user experience is impacted.

It's been made worse for everyone all for the sake of trying to establish a consistent keyboard navigation pattern.

Each approach had a small benefit and an incredibly large detrimental effect. Each approach would deliver a poor user experience for the keyboard user.

No good outcome

Collectively the team recognised neither approach would work. Instead of forcing a new keyboard navigation pattern onto the user, maintaining the existing keyboard navigation behaviour in each component was the best approach.

The two elements when combined retained the arrow key navigation for the search results and Tab key navigation for the previously bought items.

The composite component retaining existing keyboard navigation behaviour

There is no overlap between the two navigation methods. The arrow keys do not move focus to the previously bought products, the Tab key does not move focus to the search results items. It's the digital equivalent of chalk and cheese.

Two unrelated components are forced together but still operate independently.

Picking at the digital thread

It's not the outcome hoped for. But this is how accessibility often is. The best approach can become a compromise. A tug-of-war battle between business objectives and improving the user's experience.

It's tempting to try and find a better solution. a neater approach that establishes a consistent way a user navigates across multiple screens and features, but this becomes scope creep. The unwanted picking at a loose digital thread.

In this instance, the best outcome was to keep the components operating independently. Either approach would have forced the user into re-learning navigation patterns, and with online supermarkets, reducing the friction for the end user is the goal.

How Australia's spy agency created accessible complex images

2023-06-13T00:00:00Z

Describing complex images using just an ALT or aria-label attribute is difficult. When descriptions begin to move beyond a single sentence other alternatives are more appropriate.

One of which is semantic HTML. This can be used to describe any differences visually as an alternative but less intrusive approach than screen reader text.

Celebrating the 75th anniversary

In September 2022 the Australian Government's signal intercept agency Australian Signals Directorate (ASD) celebrated its 75th birthday with the creation of a commemorative coin. The announcement made via their website, presented some unique opportunities to provide alternative text for people with disabilities.

How to make a complex image multimodal and accessible to the widest possible audience using assistive technology?

The coin image on the website used multiple layers of codes on both sides with a hidden message revealed after each layer was solved.

The obverse and reverse of the Australian 50 cent coin.

An alternative to ALT text

For an information-rich image, relying on ALT text alone isn't particularly helpful. ALT text only describes the letters, yet cannot easily describe the different textures, emphasis, shapes, and arrangement which all feature prominently.

The go-to approach when describing images for assistive technology users is an alternative text description via ALT attribute on the <img> element. When encountered by assistive technology it then presents the description in another format. A screen reader user for example may hear the text description announced.

<img src="image1.gif" alt="a description">

Another equally valid approach is the aria-label attribute.

<img src="image1.gif" aria-label="a description">

The general advice is to provide a succinct text description of what the image conveys and most times this approach works well.

The other piece of advice is to avoid literal descriptions. A literal description may describe what's contained in an image, but they don't describe the meaning of the image, why is the image important? what is its relevancy?

But applying either technique (ALT text or aria-label) to an image with this level of detail becomes an exercise in hopelessness. Whilst the image of the coin could be described in text, the amount of additional text to include to describe the formatting, placement and emphasis would be immense.

ALT="letters rotating around the edge of the coin, VKG are emphasised, the reverse of the coin is segmented into 3, with the letters E3B8287D4290F7233814D7A47A291DC0F71B2806D1A53B311CC4B97A0E1CC2B9…"

You get the point.

Using the ALT or aria-label attribute to provide a text alternative for this image is a lost cause. Taking this approach may be deemed "accessible" as alternative text has been provided but few can confidently say that it's in any way helpful or even useable.

The descriptions of the formatting, placement and emphasis of the text get in the way of the text content. The user has to context switch and understand the text whilst trying to mentally construct the text arrangement all of which is described in text.

ASD's approach

What ASD did was clever. Instead of providing an ALT or aria-label attribute, they used HTML elements to provide the context. They leveraged the semantics, HTML elements that describe meaning to content, allowing assistive technology to describe the visual difference.

The HTML elements <strong> and <u> were applied to describe the context without resorting to a text description. Depending on the assistive technology used when these elements are encountered it may output a difference in sound or provide an audible cue. The visual difference is explained without losing context for the user.

Prompting the user

The first part of the alternative text description begins on the image, asking the user to "See the accessible text version below for a detailed description of Side A (Non-Queens head) of the coin".

<img loading="lazy" class="img-fluid image-style-medium-ratio" src="/sites/default/files/styles/medium_ratio/public/2022-09/ASD-50c-FRONT-Web-tx.png?itok=hnsXsuyd" width="416" height="416" alt="See the accessible text version below for a detailed description of Side A (Non Queens head) of the coin" typeof="foaf:Image">

Although the wording for the description may be a little clumsily written, "see" provides a prompt to the user that further detail follows the image.

Immediately following is an accordion control with a clickable link for an accessible text version. This follows the aria authoring accordion pattern and uses dynamically changing aria attributes when the panel is activated. Triggering the screen reader to indicate content has expanded.

The expanded content section showing Side B (Queens head) separating the coded sections of the coin with emphasis and spacing.

Within the accordion control's expanded content the elements <strong> and <u> are used repeatedly to markup the visual emphasis in a way that doesn't diminish the content.

A section of the side B (Queens head) content with the letters "B TH" of Elizabeth and "A S A" of Australia highlighted in bold.

<strong>Side B (Queens head)</strong>
<br>
ELIZA
<strong>B</strong>
E
<strong>TH</strong> 
II - 
<strong>A</strong>
U
<strong>S</strong>
TRALI
<strong>A</strong>
 - 2022 - 50 CENTS
<br>
The following letters have a series of dots shown below them.&nbsp;<br>

For the Side B (Queen's head) of the coin, the letters "ELIZA E II U TRALI - 2022 - 50 CENTS" use regular text with no semantic HTML applied whereas the letters "B TH" of Elizabeth and the letters "A S A" of "Australia" are individually contained in the element <strong>.

Elsewhere on side A of the outer ring of the coin, the period character and letters "Z L L Z M" (amongst many others) are individually contained in the element <u>.

Semantically describing the meaning

The <strong> and <u> elements are semantic HTML that describe the meaning of content. This is how individual characters with a visual difference should be marked up. These elements provide a structure that allows assistive technology to potentially be interpreted in a particular way different from regular text.

Some assistive technology (depending on the tool) may use a difference in sound to convey the visual difference. Although screen readers JAWS and NVDA don't currently announce the difference, that isn't to say we should not use these elements as accessibility is more than just for people with a vision impairment.

When semantic HTML is used there's a greater likelihood the output can be interpreted into a different mode which can help with user understanding. It may be reformatting it, using audible cues or an as-yet undecided option.

As a segue at the 2023 Microsoft Ability Summit conference. Blind developer Roberto Perez in the presentation "Inclusive Development: Empower Every Developer and Their Teams to Achieve More" describes intentional audio cues in Visual Studio as being easier and faster to process than screen reader speech.

This future-proofs web content and allows it to become more flexible to the demands of assistive technology.

So far so good. ASD future-proofed the alternative text to allow assistive technology to use a different mode to highlight the visual difference described in the image. Whether the assistive technology implements the functionality is another matter.

Great intention, poor implementation

But this is where the best of accessibility intentions suddenly takes a 180-degree turn and places the user back at the start of inaccessible content.

This article intended to show how Australia's spy agency created an accessible complex image. Detailing an incredible example of how feature-rich images could be provided in an alternative accessible format.

But unfortunately, even the smartest people in the country have a challenging time implementing accessibility. This innovative approach using semantic HTML to describe a very complex image has an Achilles heel.

Testing out the accessible text I repeatedly found the screen reader wouldn't output the accessible text at all, even though visually it was onscreen, structurally it was as if it was … invisible. And checking the HTML confirmed this.

An aria-hidden attribute applied on the parent container of the accessible text had its value of true remain unchanged when the content expanded. Causing the child content to remain inaccessible for screen readers.

The aria-hidden attribute remains unchanged when the accordion content is expanded.

This approach is acceptable when your motto is "Reveal their secrets. Protect our own" and you're hiding national secrets. But perhaps not so helpful when the accessible text version becomes invisible to screen reader users.

The expand and collapse content uses a familiar aria authored accordion component pattern built following the aria authoring patterns.

Because the control is not a native HTML element, aria attributes are applied to make the component announce its state (whether it is collapsed or expanded) to screen readers.

Triggering each section should toggle the aria-hidden attribute from true to false, rendering the expanded content to be visible to a screen reader user. But the toggling of the attributes doesn't happen automatically, the behaviour needs to be coded correctly by a developer.

Overlooking one stray aria-hidden value hides all child content from assistive technology.

And it isn't isolated either. The same issue repeats in the sections "Substitutions", "Atbash", "Transpositions" and "Binary data using the Exclusive OR (XOR) operation" and the entire "How to solve the cryptographic code on ASD's coin" section.

All the content in these sections is hidden from screen reader users.

The entire accordion control rendered hidden to a screen reader user.

Fortunately, the fix is straightforward. When each accordion section is expanded ensure the corresponding aria-hidden attribute is toggled from true to false. Making the expanded child content viewable by a screen reader.

The aria-hidden attribute toggled to "false" when the accordion content is expanded.

Summary

Aside from the unfortunate overlooked aria-hidden value not changing. ASD demonstrated a clever approach to leveraging semantic HTML to allow assistive technology to interpret content in a different way.

It makes the content flexible to be reformatted in any number of possible ways by people using assistive technology. Complex descriptions in images can be described without always necessarily relying on a text description alone.

Using semantic HTML elements can describe the difference easier than a text description.

When the alternative text description for your complex images becomes itself complex, is there an alternative approach where the complexity can be described in another format?

Things to consider

Use semantic HTML to describe differences where a text description alone would become too complex.
Semantic HTML may not always be interpreted by screen readers, but assistive technology may use those elements in other ways to describe meaning.
Apply aria authoring patterns correctly and confirm all dynamic aria attributes change as appropriate.

Resources

Australian Signals Directorate 75th Anniversary Commemorative Coin
Microsoft 2023 Ability Summit Inclusive Development: Empower Every Developer and Their Teams to Achieve More
em and strong are not announced by screen readers
Screen Readers lack emphasis (2008)

WCAG 2.2 is finally here!

2023-10-09T00:00:00Z

After a long wait and several false starts WCAG 2.2 is now a W3C recommendation. 2.2 is a modest update and has nine new criteria to build and test against.

2 criteria at level A
4 criteria at level double A
3 criteria at level triple A.

But it’s not all new, there is also a deletion. Success criterion 4.1.1 Parsing has been marked as obsolete and is out.

Since WCAG 2.0 was published, browsers have improved their handling of parsing errors. Parsing problems either no longer exist or are addressed by other criteria.

How can the criteria be arranged?

Seven of the new criteria are designer focused. Look at adding these requirements to any design assets (such as Figma) before coding.

That said there are two developer focused criteria. If you're responsible for implementing authentication in a developer role 3.3.8 accessible authentication (minimum) and 3.3.9 accessible authentication (enhanced) are the relevant criteria for you.

Seven criteria for designers

Single A criteria

Double A criteria

Triple A criteria

2.4.12 focus not obscured (enhanced) and 2.4.13 focus appearance are triple A criteria and not necessary if you're conforming to level double A only.

However, where possible understand if there is scope to adopt more criteria at the higher conformance level to support more users with diverse requirements.

Two criteria for developers

Double A criteria

3.3.8 accessible authentication (minimum)

Triple A criteria

3.3.9 accessible authentication (enhanced)

3.3.8 accessible authentication (minimum) and 3.3.9 accessible authentication (enhanced) are functionally the same.

The detail between these two criteria is identical except where 3.3.9 is a triple A requirement removing authentication via user submitted content or object recognition. A test which was allowed at the double A level.

Our opinion is if you’re developing with familiar login and authentication patterns it’s unlikely you’ll encounter a requirement for authentication via object recognition or user submitted content.

This means passing at the double A level also passes at the triple A level if standard authentication patterns are used.

Do I need to start thinking about WCAG 2.2?

This is a firm yes. Internal accessibility policy in organisations and governments tends to lag behind the WCAG version changes. Adopting the new 2.2 criteria will future proof digital content when policy changes catch up.

If you’re already meeting WCAG 2.1 criteria you’re most of the way there with meeting 2.2 criteria.

Even though it isn’t yet a requirement it’s good to begin thinking about how to improve processes, design assets and digital service details to incorporate the 9 new criteria when internal policies change.

New WCAG 2.2 course

To help familiarise you with the requirements we’ve created a new course Master the 9 new WCAG 2.2 success criteria on Udemy.

We've poured over each criterion, unpicked what it means, tested it, read background information including both the official guidance from the W3C and from the accessibility community to give you the best outcome.

The course contains practical patterns and clear guidance with what to do (and not do). Some of the topics taught on the course include:

Relate the new requirements to real users through the use of personas
Understand design patterns which pass WCAG 2.2
Avoid design patterns which fail WCAG 2.2

For the next 30 days the course has 25% off the full price using the code MASTER-WCAG-22. Follow the Master the 9 new WCAG 2.2 success criteria link with the code applied.

ThisIsWCAG.com update

We’re also finalising updates to thisiswcag.com. Along with a newly designed UI the 9 new WCAG 2.2 criteria have expanded into approximately 15 new tests.

Although WCAG 2.2 is a modest update it’s an important one. There’s a stronger emphasis with unobscured and clearer focus indicators with 2.4.11, 2.5.8, 2.4.12 and 2.4.13. Increased support for cognitive impairments with 3.2.6, 3.3.8 and 3.3.9 and support for alternative input interactions with 2.5.7.

Understanding the criteria and knowing how to add the techniques to projects isn’t always straightforward. Drop us line if you’re interested in working together and would like help to apply the new criteria to your digital projects.

Stay up to date and subscribe to our newsletter and digital channels on YouTube, LinkedIn and X (formerly Twitter) as we’re sharing more information on WCAG 2.2 over the next few weeks.

WebAIM's 10th screen reader user survey

2024-02-28T00:00:00Z

The results from WebAIM’s most recent screen reader user survey have been published. There are no surprises with the perennial CAPTCHA shown to be the most problematic of web content.

There is a sense of cautious optimism that web accessibility hasn’t gone backwards in the web industry. 47% of respondents felt web accessibility hasn’t changed whilst 35% felt it has become more accessible. Although they’re not hugely promising numbers and show the industry has a way to go.

This was WebAIM’s 10th survey results, with 1539 people responding over December – January 2023-2024. Most respondents were from the USA (47%), Europe (31%), followed by Asia (6%), Africa/Middle East (5%) and Central America and the Caribbean (2%).

Whilst 50 people (3%) from Australia and Oceania region responded.

The age breakdown was near even between 21-40 age bracket (38%) and 41-60 (36%).

Recorded disabilities

90% of the respondents identified as having a disability.

Blindness was the most reported at 77%,
followed by low vision at 20%,
and lower numbers of users reporting cognitive, deafness, motor, and other disability types.

Interestingly the other disability types include impairments not typically associated with screen reader usage. Showing screen reader users are not just blind people.

58% of respondents identified as Advanced users,
followed by 36% Intermediate.

It may be tempting to draw conclusions from these figures and consider all screen readers are power users but don’t. This is a small sample of users who identify as being tech-savvy and not representative of all screen reader users.

Screen reader usage

40% of respondents use JAWS as the primary screen reader,
followed by 38% with NVDA.

Yet for screen readers commonly used NVDA is on top at 66%, with JAWS at 60%. The change could be due to workplaces using JAWS whilst at home cost-free NVDA is preferred.

Primary browsers for screen readers users were Chrome at 52% followed by Edge. This has remained unchanged for several years. JAWS and NVDA with Chrome being the most popular combinations.

Because JAWS and NVDA are Windows programs, Windows therefore is the dominant reported operating system at 86%.

Navigational elements

On the technical details. Landmark regions still don’t feature prominently as a navigation mechanism.

31% sometimes using them,
21% seldom,
and 18% whenever they’re available.

After a high of 44% in 2013, this figure dropped over the years and is now beginning to increase. With the increase in their use, it’s perhaps time to adopt landmarks as a regular feature of navigation.

Problematic features

Most telling are the problems facing users on websites. The perennial CAPTCHA is the most problematic followed by interactive elements and ambiguous links and buttons.

We always anticipate interactive elements to feature prominently. They're often built with copious aria attributes and have irregular interaction behaviour and compatibility issues between browsers and screen readers.

Respondent's perceptions towards web accessibility are disappointing.

47% felt web accessibility has not changed,
whilst 35% felt it had become more accessible,
19% felt web content became less accessible.

It’s promising that collectively the web industry hasn’t gone backwards with web accessibility goals but it’s certainly not the significant strides hoped for.

The biggest impact

Just what is the biggest impact of improvements to web accessibility? If you had said more accessible websites, you’d be right. With 86% responding. This same question was asked in 2009 (69%), 2010 (76%), 2014 (81%) and 2021 (85%).

The report makes the point the increase in people responding with wanting more accessible websites could be reflective of improvements in assistive technology. A maturing of screen reader technology has made people expect more out of the web.

Either way, it shows there is a growing appetite for more accessible websites.

Read WebAIM's Screen Reader User Survey #10 Results for details.

*percentages rounded up

Uninterrupted keyboard focus: conquer popups, cookie consents, and overlays

2024-04-01T00:00:00Z

Transcript

Keeping focusable controls visible has always been great UX advice, now it's great accessibility guidance with the latest version of WCAG.

2.4.11 focus not obscured (minimum) is a 2.2 criterion requiring keyboard focus to remain visible. The goal is to keep keyboard focusable controls at least partially visible all of the time.

But to understand this success criterion, you need to understand the web of today. Popup and overlaying type content is everywhere. There’s sticky headers, sticky footers, newsletter popups and if you’re in the European Union numerous GDPR cookie banners.

This content has a significant disadvantage when displayed as it hides keyboard-focusable controls, things like buttons, links, and widgets. Making it difficult for a keyboard user to know where they are on the page.

Picture this, a user is navigating through the page, and the keyboard focus is on a control. But a GDPR cookie banner appears hiding the control. Resulting in the user no longer knowing where the keyboard focus is.

At this stage, you’re probably thinking let’s just avoid creating content that hides focusable controls. Whilst that would undoubtedly pass this requirement, that isn’t what the success criterion is saying.

Whilst avoiding popup content is a good UX decision, the requirement for 2.4.11 is to make sure keyboard-focusable controls are not fully hidden. What I mean is, a focusable control can be partially hidden if its focus remains identifiable.

So, an in-focus button, partially hidden by a newsletter popup is allowed. It isn’t a good design decision, but it is allowed.

Now the term “partially hidden” is wildly open to interpretation. How much hiding is too much? There’s no figure. But a principle to follow is when more of a focusable control is hidden by dialogs, popups, or sticky content the user has greater difficulty finding and using it.

While one approach is to avoid hiding any keyboard focusable feature at all. In practice this is difficult to do. A better approach is allowing keyboard focus to follow onto the popup. When popups, dialogs or banners appear, move keyboard focus to a control within.

This content typically come with one or more buttons to dismiss or perform some action. What I mean is a dialog has a dismiss button and a GDPR cookie banner has accept and reject buttons.

Making the focus follow onto the popup content means this criterion is automatically passed. As the focus can no longer be hidden by the popup as its now become part, of the popup.

Those are the requirements defined in WCAG, but how would designers or developers apply them?

If you’re a designer, you want to be aware of positioning content which doesn’t hide focusable features. Is there generous top and bottom spacing on sticky headers and footers to allow content to scroll and not be hidden? Can popups be shown in such a way that focusable content is not hidden?

Whilst if you’re a developer you need to understand if content is shown above interactive controls, keyboard focus is always following.

What I mean is if a GDPR cookie consent banner is used which has a dismiss button then that button has keyboard focus when the banner is visible. And the keyboard focus is retained in the banner until its dismissed.

What I’ve said goes beyond the WCAG 2.2 requirement of keeping a control partially visible. When more of the focusable control is hidden by dialogs, or sticky content the user has greater difficulty finding and using it.

And so 2.4.11 focus not obscured (minimum) reduces the distraction of hidden content and means the user always know which control is in focus, but its requirement should be viewed as the bare minimum.

Partially hidden content whilst accepted by WCAG means the user has greater difficulty finding and using it. Whenever possible go beyond the minimum requirement and avoid partially hidden content.

Australia's Digital Service Standard gets an update

2024-04-29T00:00:00Z

Transcript

7 years is a longtime in government circles. The standards for government digital services to be built responsibly including accessibly has had its first significant update to version 2. That’s right I’m talking about the Australian Government’s digital service standard.

Services covered by the Digital Service Standard (DSS)

With version 2, some former requirements remain, criteria reduced, and accessibility applied more comprehensively. What remains unchanged is it’s still mandatory for government websites and mobile applications, is applicable to both information and transactional services and applies to new and existing public facing digital services.

Implementation timeframes

Implementation timeframes are generous and occur in two phases. New services must meet the new version from 1st July 2024. Whereas existing public facing services have until 1st July 2025 to meet the new version.

As before state, territory and local government don’t need to apply the DSS. If you’re a designer working in state government, you’re not required to follow it. But state and territory governments generally follow what the federal government does so expect to see this adopted over the coming months in some form.

A new requirement

Whilst those requirements are familiar, applying the DSS to staff facing digital services becomes a new requirement. Traditionally users in government departments had a mixed experience with poor inaccessible products. What this means is that a greater emphasis on making the internal digital tools accessible becomes a new requirement.

WCAG versioning no longer followed

Version 2 of the DSS no longer requires following a specific version of WCAG. This is good, as it future proofs the standard and makes it applicable to the latest version of WCAG. So WCAG 2.2 is supported as are future iterations all the way to the yet unpublished WCAG version 3. No longer will the DSS lag behind WCAG versioning and become out of date.

Minimum WCAG conformance level removed

Whilst version one of the DSS required conforming to level AA of WCAG. The conformance level for version 2 is now removed which can be viewed two ways. It either encourages agencies to aim for increasing levels of conformance at triple A and support more diverse users with disabilities or do the bare minimum and aim for single A conformance. I like to remain optimistic and think it’s the former and not the latter.

The new DSS criteria

Have clear intent
Know your user
Leave no one behind
Connect services
Build trust in design
Don’t reinvent the wheel
Do no harm
Innovate with purpose
Monitor your service
Keep it relevant

Accessibility scattered throughout the DSS criteria

Up to this point, DSS version 2 requirements have been familiar. What’s changed is accessibility is no longer confined to a single criterion but scattered throughout. With 7 of the criteria most relevant for supporting accessibility and inclusive practices.

Criteria 2 know your user

You’re encouraged to gather different perspective and undertake ethical and inclusive user research using co-design wherever possible. User research has been a big focus of the previous DSS version, and this remains. Understand who you’re designing the service for.

Criteria 3 leave no one behind

Understand the diversity of your users, think back to criterion 2 who are you designing for? You need to build a service which complies with the disability discrimination act (DDA), the latest version of WCAG and the Australian Government Style Guide.

You may have designed and built a service with WCAG which is technically accessible, but this doesn’t mean practically usable for a screen reader user. That’s why it’s also important to comprehensively test the service across different devices, different assistive technologies, platforms and integrate their feedback.

Be respectful of user’s bandwidth and data constraints when developing digital services. Australia is an incredibly big country. A React, Angular or Blazor application with significant downloadable dependencies or API calls may not perform well on low powered devices with limited bandwidth in remote locations.

Connectively and low powered device responsiveness are also accessibility concerns.

Criteria 4 connect services

Design for easy connection between government services. If a user is requested to login across many connected services consolidate those logins as much as possible. People can experience reduced cognitive load if they’re required to repeat the same actions multiple times.

Criteria 5 build trust in design

Eliminate ambiguity in your service and provide appropriate validation feedback, progress tracking and provide information a user needs up front. Ensure error messages are understandable and appropriate.

These are all good accessibility principles to follow for inclusive design.

Criteria 6 don't reinvent the wheel

Are there existing platforms and patterns built to accessibility guidelines which can be reused. The former DTA design system was a good example of a common UI asset with accessibility applied that had potential for reuse across many government services.

Criteria 8 innovate with purpose

Choose new technologies appropriately. Will the adoption of anything new adversely affect the accessibility of your service.

Commercial off the shelf products may not have been procured in accessible ways and your service will absorb accessibility debt if adopted.

Criteria 10 keep it relevant

Continuously optimise the service and increase its compatibility. Accessibility is never done. Schedule regular assessments and make sure new features don’t impact existing accessibility.

It only takes 1 poorly implemented chatbot to undermine the accessibility of your service.

Summary

And so, version 2 of the DSS continues the trend of using user research to truly get a picture of your users. It encourages diverse user research with varied audiences and to build responsibility following WCAG, testing assumptions and evaluation with assistive technology users.

Promisingly it includes both public facing and staff facing digital services. Which is a big improvement.

Public service staff with a disability have traditionally had a poor experience where their needs with internal systems weren’t adequately addressed.

Overall, this DSS version is a long overdue update. It adapts to the current version of WCAG and leaves room for agencies to aim for high levels of conformance.

Though for those agencies with limited resources this may mean WCAG single A and the potential for a two-tier web experience across government to develop.

Time will tell how accurate this statement is.

Resources

Australian Government Digital Service Standard v2 (PDF)

Improving product tile navigation using landmarks

2024-05-20T00:00:00Z

Transcript

Most sites use landmark regions in some capacity, these are HTML elements that act as containers for sections of the page content.

Common site landmarks

There could be a footer positioned at the bottom of the page, header at the top, main content for of course main content, and these all segment the page into a defined region for screen reader users to navigate to.

Depending on the screen reader it may list all landmark regions, iterate through them individually or jump straight to that region.

WebAIM's most recent screen reader survey results

WebAIM’s most recent screen reader survey identified landmark usage which had for several years been on the decline begin to climb with the frequent usage up to 31 % of the users surveyed.

And it’s this navigation option and the increase in users navigating with landmarks which shows we can begin to apply them more effectively for describing product tiles.

Typical makeup of a product tile

Typically, product tiles on a lot of ecommerce sites contain a sectioning element with a heading, product image along with some text.

But these product tiles are often complex and crammed with pricing information, specials, bought before indicators, buy now, ½ price all being conveyed visually.

This isn’t an equivalent experience for a screen reader user.

How a screen reader user may find product specials

A screen reader user who wants to find products with some sort of specials indicator, would have to navigate through all product tiles individually to read that information. And this is either found further down in the product tile or in the image.

Or what’s most likely filter the page results. First find the filter options, apply a filter, wait for the page to reload and if they’re lucky keyboard focus remains where it was before the load. It all takes a screen reader user much more effort.

The way the product tile container is built is problematic. They all follow the same format. It’s generally comprised of a generic section element, or div, which provides no meaning.

But the scaffolding is in place to enhance this and provide a way to navigate to product items quicker.

If we think about it conceptually, it’s the product tile container that needs to provide additional context for the entire contents.

If a specials indicator is within the component it’s more effort to understand. Since the user must first navigate the component to understand the text and find out it’s a special product.

I think we can do far far better.

Replace the generic section element

Firstly, replace the generic section element with a more appropriate semantic landmark element.

Choose the article element

Choose the article element as its meaning more accurately describes the content. As the HTML specification describes an article element as representing “a self-contained composition which could be reused elsewhere”.

And this is what product tiles are, reusable web content. They not just found on product listing pages they’re found on other pages, the product tile component is reused a lot.

Now the article element is anonymous

The tweak is a good start, but whilst its now semantically appropriate and in theory identifiable in a screen reader it's anonymous. The product tiles are marked up as articles which means we’ve introduced the landmark equivalent of click here.

How does a user know what landmark leads to which product tile, what’s important about the product tile, the landmark of course needs a label!

Introduce aria labelling to the article element

Next apply aria labelling to the article element.

We could use the aria-label as its quick to add to the article element but is a little bit messy. We’re having to duplicate the existing text within the product tile making sure this aria-label text is the same as the text within the product tile and when coding it all it can get out of synch.

Use aria-labelledby to label the article element

Instead use aria-labelledby and reference the product name and specials indicator by ID.

The product tile now has a semantically appropriate element and a label to highlight those items which are specials.

The article element is used because the content can be reused elsewhere on the site and we’ve called out the type of special the product offers with aria-labelledby referencing existing text so no messy duplication efforts.

This is good!

Now exposed by the accessibility tree

This is now exposed by the accessibility tree, the element is an article and has been labelled with the product tile heading and the special indicator “down down discount” and means a screen reader user navigating through landmarks can understand which products are on special solely from the landmark text.

It provides another way to navigate product tile information without requiring a user to filter or manually navigate product tiles to find items on special. It’s making it easier for the user.

At this point you might be thinking let’s provide every product tile with additional detail, aria-labelledby everything! but avoid this.

Named landmarks can add a significant amount of screen reader noise. If there are 20 products each marked up with an article and label then the positive outcome you had from labelling key products with special indicators has now evaporated.

Follow the principle less is more.

Reserve the technique for only special products

Instead reserve the technique for only those elements which have some special indicator attached to them. They might be specials, buy now, or bought before.

Reserve the technique for those product tiles which benefit from being highlighted.

How well is the technique supported?

This all sounds like a worthy enhancement to make product tiles more descriptive semantically, but the elephant in the room is compatibility.

How well is it supported by screen readers.

This is where it gets interesting. In their default configuration

NVDA doesn’t announce the article element or list it.
JAWS lists the articles and infers the label from the article contents but does use the aria labelling if it exists.
VoiceOver on iOS lists the article if a rotor setting for articles is turned on but ignores the aria labelling.
and VoiceOver on MacOS lists all articles, and only provides the custom label for those articles which have it.

Just because the screen readers support is currently patchy it doesn’t mean don’t use the technique. Building with semantic HTML means when technology supports it, it’s used.

It’s about choice, it’s making it easier for a user to find relevant product information faster using other navigation mechanisms if that’s their preferred way.

Aria labelling combined with semantically appropriate landmark regions are a powerful way to call out important information for selected product tiles.

But consider this technique as falling into the goldilocks zone, too little landmark usage is unhelpful as is too much, using aria labelling and articles appropriately means it becomes just right and can become an additional help to the user.

Checkout the full code at codepen.io/canaxess and follow the link to Improving product tile navigation using landmarks and aria labelling.

I’m Ross I run CANAXESS, if you’re interested in working together boosting your accessibility efforts drop me a line at ross.mullen@canaxess.com.au.

Resources

Improving product tile navigation using landmarks and aria labelling

Google I/O 2024 conference

2024-05-26T00:00:00Z

Google I/O 2024

This year's Google I/O conference had several important accessibility updates for the Android operating system and it's screen reader TalkBack.

Our pick of the highlights were:

Android 15 updates

Version 15 includes the ability to pair and control audio hearing aids with support for hands-free calling, changing presets and a new quick settings tile.

Labelling images with AI

Unlabelled images become accessible with an update coming to TalkBack later this year. Which gives vision impaired users the ability to have photos described with clearer descriptions of what's happening.

This uses Google's AI "Gemini" with an on-device model called "Nano" working even when there is no data connection. Especially valuable in regions with low or no connectivity.

TalkBack 15 update

Improved support for refreshable Braille displays.
Improved container navigation.

Feedback from users describe it's challenging to navigate lists, grids, and other collections when they contain a lot of items. The feature will allow users to traverse the content more quickly.

New APIs

Conveying additional information about the size of collections is covered with new APIs. itemCount and importantForAccessibilityItemCount fields on the CollectionInfo class, provide a list's truer size outside of headings, dividers and other decorative content that can be picked up whilst navigating.

Using this feature means TalkBack adjusts the feedback to represent more prominently item counts when describing collections.

Updated developer guidance

Interestingly Google noticed developers favouring TalkBack over compatibility with other accessibility services. To counter this the guidance has been updated to discourage the use of TYPE_ANNOUNCEMENT and announceForAccessibility().

Instead, guidance now recommends developers use more semantic and less disruptive alternatives. So overtime expect less reliance on audible feedback for common UI elements and instead rely on element semantics more.

Some examples include descriptive labels to communicate actions avoiding the need to provide confirmation announcements for user actions. And using window and panel titles to convey a high-level description. Where UI elements require attention expose these as polite or assertive depending on time sensitivity.

Check out Google's Head of Accessibility and Disability Inclusion Christopher Patnoe's LinkedIn post where he outlines several more features, and watch the full list of Android accessibility updates in the videos below.

Resources

Spies, Screen readers and Semantic HTML

2024-09-28T00:00:00Z

Video transcript

The Australian signals directorate is Australia’s intelligence gathering organisation, think of it as the NSA in the US or GCHQ in the UK. They’re the ones breaking codes, listening to and collecting intelligence protecting the country from threats far and wide.

They’ve been around for 75 years and two years ago in recognition of their founding all those years ago they produced a commemorative 50c coin. For a code-breaking organisation you’d expect it wasn’t some boring logo on a coin, instead the coin had several codes embedded on both sides.

On the reverse side featured letters on the outer and inner ring – some embossed to make them stand out, whilst in the middle were 3 sections with the lower featuring letters and numbers. Whilst on the front of the coin braille lettering is beneath several letters of the words Elizabeth and Australia.

The coin has an accompanying webpage which describes the image, but it’s incredibly challenging to describe if you can’t see the image.

For people who are blind describing images on the web comes down to using and relying on other mechanisms to understand the image.

These users use a screen reader which is a piece of assistive technology that describes the image in an audible way. But the way the image is marked up in HTML can mean it's very easy to understand or very hard.

Navigating with a screen reader, means how the content is displayed becomes less relevant. When the ability to see content on the web is reduced or removed, the screen reader attempts to make use of other mechanisms. It may use the ALT attribute on the image, an aria label attribute or the content surrounding the image such as paragraph text or figure element. Think of this as meta data of the image.

For example, on the NVDA screen reader pressing the character G will cycle through all images on the page and assuming they’re correctly marked up will audibly announce the ALT text.

But what are some ways to describe this incredibly image? we could use ALT text, as that provides an alternative text for the image.

Perhaps Alt="commemorative coin". When the screen reader encounters the image, it would then announce the text "commemorative coin". Whilst this ALT text is accurate, it is an image of a commemorative coin, it’s not exactly helpful and a rich description of what the image conveys and isn’t providing an equal experience for users who can’t see the image.

If you were describing the coin to someone you would use a rich description. You wouldn’t say "commemorative coin", you’d describe its embossing, perhaps the inner and outer circles. And that’s what we’re wanting to convey. It’s a coin, but what’s so special about it?

When providing ALT text for images we need to provide just enough detail as if you were describing it to a someone. I could therefor use ALT="letters rotating around the edge of the coin, VKG are emphasised, the reverse of the coin is segmented into 3, with the letters E3B8287D4290F7233814D7A47A291DC0F71B2806D1A53B311CC4B97A0E1CC2B9…" but this quickly descends into a nightmarish approach of attempting to provide so much information that ALT text is no longer a viable method to describe the complexity in the image. I pity the person trying to understand the ALT text of such depth.

We could use adjacent paragraph text, but again we’re using text to describe the visual changes of the text. The description which is understood visually is becoming diluted with necessary text taking away the meaning of the image.

A way to describe the meaning of differences in text and placement without using text and overloading the user is required.

And that way is semantic HTML.

Semantic HTML is the backbone of an accessible web. What this means is when HTML elements are used to describe the meaning of content, that content can then be interpreted in ways not necessarily text based. Semantic HTML provides a solid skeleton which describe the meaning of content.

Semantic HTML may introduce a different sound in the screen reader, be consumed in non-visual ways or otherwise alert the user that this bit of semantic HTML content is different, and so describe it differently.

When semantic HTML elements such as headings, lists and form elements are used they provide extra features for the screen reader for free. When navigating with a screen reader headings , pressing the H and shift H key cycles forwards and backwards through heading levels announcing the heading text and level.

By pressing the letter I on the keyboard lists announce the number of items in the list as well as individual items.

Form controls provide extra meta data to be described such as the type of input required in this instance it's an edit control and its blank, controls may also make additional sounds to indicate when on a form control. And all this metadata richness is what we're wanting to tap into.

At the 2023 Microsoft ability summit conference blind Microsoft developer Roberto Perez described in his presentation intentional audio cues in visual studio allow him to understand information faster than just relying on screen reader speech. If we can rely on non-text ways to describe content using sounds or other metadata without having to describe it this sounds like a pretty good outcome.

Intentional audio cues that what we're trying to accomplish.

Additional non-text cues to content means that content can be understood in different ways. It may be tactile, audible or ways in which we haven’t yet identified. It’s allowing content to be consumed in multiple ways.

Traditionally a UI was one mode, it was visual. What we saw is what we got. But building a user interface today and embracing semantic HTML means thinking of it as a multi modal experience and not just visual. By building content to describe meaning and giving users the ability to consume content is any number of ways it opens up the opportunity of supporting more users who access it in ways which are convenient for them.

What ASD did to overcome the challenge of describing a complex image was very clever. Instead of only providing a lengthy description in ALT text or in separate text they used semantic HTML to enhance meaning to those elements that are visually distinct. What I mean by this is they used HTML to provide meaning to the content rather than changing how it looks.

On the Queen’s head side of the coin content with the letters B, TH of the word Elizabeth and A S A of the word Australia were contained in the HTML element strong. As this corresponds to the locations where braille is applied.

Whilst on the reverse the emphasised letters alternate from being contained in the strong element to not. The outer ring has the letter D R FHRM contained in the HTML element strong, and this is the same with the inner ring. Wherever there is a visual emphasis that emphasis is described with the HTML strong element. Visual emphasis using the strong element and then back to regular text.

The HTML specification describes the HTML strong element as representing important, seriousness or urgency in its content. And this is a great demonstration of importance in those bits of content.

When text is visually different to convey the importance the strong element is appropriate to use in this situation. Strong is providing meaning.

All this is good to describe the emphasis of the text and word elements but what about the actual ALT text on the image. How did ASD connect the ALT text which is the traditional way to describe images to this content? they used "See the accessible text version below for a detailed description of Side A (Non Queens head) of the coin".

Now this is clunky, asking the user to see the text below, "see" as not everyone can see the text and "see below" is referencing a direction which is in violation of the Web Content Accessibility Guidelines version 2.2 success criterion 1.3.3 sensory characteristics at level A.

At this point I was thinking that’s a good innovative implementation of using semantic HTML to describe complex visuals in a different and unique way, it’s not perfect and has some flaws but we're not letting perfect be the enemy of good, overall it’s pretty good. Providing the meaning of emphasised text all without relying on the fall-back method of just providing text. How well is it supported in the screen readers JAWS and NVDA, and this is where it gets interesting.

All screen readers don’t support text level HTML elements, what this means is the strong element is not announced in the screen reader JAWS, NVDA, Windows narrator, VoiceOver on Mac OS and VoiceOver iOS. No screen readers convey the strong element to users.

The screen reader NVDA did support a similar semantic element em for emphasis, but then found the element was often overused on websites it led to a jarring experience for NVDA screen reader users. And they promptly disabled NVDA from interpreting it.

NVDA said, having the emphasis element reported by default has been extremely unpopular with users and resulted in a lot of complaints about NVDA. The unfortunate reality is that emphasis is very much over-used in the wild.

And this applied to the strong element as well.

But let's jump back to explain a little more how screen readers understand content on the web. Screen readers and other assistive technologies understand the web through reading the accessibility tree. This is a representation of the physical page. It gathers information from the DOM tree and rearranges it in a format that can be understood by assistive technologies (AT) such as screen readers, eye-tracking systems, and speech input software. By using semantic HTML this allows the visual content to provide meaning to be consumed in any number of alternative ways (assuming it's created in the correct way).

Although browsers expose the strong element in the accessibility tree and in theory make the strong element available to assistive technology, the element is in no way supported in all the screen readers tested.

Simply put the strong element is not accessibility supported using current technology. If you’re testing your own apps and website for conformance to the Web Content Accessibility Guidelines, whether content has been created using these HTML elements shouldn’t be a factor in determining a pass or fail against criterion 1.3.1 info and relationships. The browser identifies the strong element in the accessibility tree, yet the screen readers refuse to acknowledge it.

Unless if a visual style accompanies the strong element in some situations this is announced by the screen reader with a few caveats. If the strong element is combined with say being bold and if that feature is turned on within the screen reader they are announced.

Visual CSS style changes of bold and italic are well supported across all screen readers on desktop and will be announced to users. But the setting within the screen reader needs to be turned on. If you’re relying on the user having a setting toggled within their screen reading software for your content to be better understood, it’s probably not a very good outcome for them.

Bold text for formatting purposes can be interpreted by the screen reader to make content audibly announce those elements in a different way. But as the web is awash with bold content, that too probably won’t be effective to describe the meaning of emphasised content.

So, with all that in mind what are some other ways that can be used to describe differences in text without having to describe those changes in text.

Emerging developments on the web is the CSS speech module which provides the ability to add emphasis to different content.

The big problem with screen readers is when they audibly announce content, there is no nuance with the synthesised text. The synthesised voice may vary slightly with volume, but content which is prominent or important is output the same way as other content. Monotone!

With CSS speech it would be possible to subtly alter the way the emphasised parts of the text are announced by the screen reader. Giving the content an aural texture. For example:

strong {
voice-volume: x-loud;
voice-rate: fast;
voice-pitch: high;
}

Notice the increased in pitch and tempo on the word important?

Making the strong element have an aural emphasis signals to the user the text is different and provides an enhanced announced output for those elements marked up in that way.

This is really promising, but as the CSS 3 speech module is yet to be ratified and is still subject to change its support is extremely limited across browsers or screen readers. This is purely hypothetical.

Current technology just doesn’t provide a consistent out of the box method to aurally identify visual changes in text content. ALT text is insufficient, the strong element isn’t accessibility supported, semantic HTML in many instances is ignored and the CSS 3 speech module is still a release candidate.

What then can be achieved with the current limitations. How can visual changes in HTML be conveyed to a screen reader user?

Semantic HTML, and using those elements which provide meaning such as the strong and emphasis.

Semantic HTML is the way to describe visual changes even though its support for conveying the text in other ways is currently limited. Semantic HTML allows us to adopt progressive enhancements for when technology catches up we don’t need to do extra to make the content accessible as we’re already provided the skeleton.

If screen readers begin honouring the semantics of the strong element, then its supported and we don’t need to do further work. If the CSS speech module is moved to recommendation by the W3C then a simple switch of the style sheet means vocal texture is applied.

Applying semantic HTML to describe differences in text makes progressive enhancement real and tangible and it makes the content become consumable in any other format. Just because it isn’t currently supported it doesn’t mean it won’t ever be supported.

Semantic HTML is the skeleton from where we add extra features when the technology supports it.

So how could a complex image like ASD’s be described in further detail without relying on just text alone and improving what's already there with the strong element. There’s always difficulty trying to use linear hierarchies and widgets to describe a complex image but let's give it a try, we'll use semantic HTML elements that are supported.

We first want to separate the front and reverse of the coin. And we'll use heading elements. Use a h2 element for the front of the coin and one for the rear. By using headings, the information on both sides of the coin is separated allowing a screen reader user to understand each group.

<h2>front of coin</h2>

On the rear of the coin are two rings, to describe the number of rings without marking it in text use the unordered list element. The unordered list element provides additional meta data without us having to do anything. When the element is navigated with a screen reader it should announce a list of two items and individually announce each list item. But it doesn’t. We've done everything right to enhance the list but the screen reader isn’t honouring it.

Let's apply this same technique with the inner segments. Each segment being a separate list item which describes when navigated with a screen reader a list item x of 3. But now we’re going down the slippery slope of adding a lot of techniques to try and describe an image without text.

So far the screen reader output isn’t great. We've improved the grouping of the items yet we would need to add better support for announcing individual letters and not entire words. And the screen reader isn’t honouring the extra labelling.

Ultimately the HTML elements we have at our disposal are limited, fixing the grouping and arranging of the text highlights further problems now of how the content is announced. There is really no efficient way to mark up differences in the text beyond using the text and poorly supported semantic elements.

If we built ever more complex relationships with HTML elements, it becomes a lesson in futility as the effort to build the HTML far outweighs the benefits of just using heading elements and strong elements to describe the image.

The most robust technique is the easiest to build and easiest to not get wrong. There's now a lot of moving parts to the description, every attempt to use ever more complex elements in complex relationships will mean a friction point with a developer where extra care and focus must be taken to build the image in just the right way and the likelihood of things breaking or not being created in the right way increases. The best option is the easiest, and that’s what ASD has chosen.

As developers its often tempting to build in complexity and try and answer problems with layering more code on top, and sure given enough time a better solution could be identified.

But deadlines mean we simply don’t have time to craft a solution like that, more so asking a developer to build the technique correctly with no errors is challenging in itself.

If you find yourself having to describe the level of complexity similar to the commemorative coin. Follow the principles with what ASD did to describe complex images.

Avoid unnecessary ALT text. Provide just enough detail which explains the image, if the image is complex reference a separate location where the description can be found.
Use heading elements to provide a hierarchy and segment a complex description into regions. For grouping of items, use list elements to describe number of items.
And apply semantic HTML elements such as strong, italic and em to describe changes in text. Whilst they’re not currently supported in screen readers, they do future proof the content and progressively it for when technology catches up.

What ASD did was clever, they used semantic HTML to describe visual differences in text content in a way other than text and layer the content in texture. But as we’ve seen the technology hasn’t yet caught up. But other things they have done are to provide a description in the ALT text of the image guiding the user to find more (although the wording is clunky), they used a collapse and expand widget to provide the text shown on the coin. This is accessibility in depth. Using a range of techniques to enhance access and understanding to the largest number of users. Just because the strong and other semantic elements aren’t supported now it doesn’t mean it won’t be.

But that isn’t to say ASD’s example cannot be improved, their use of ALT text is clunky, no heading elements are used to segment the two sides of the coin and there’s a significant accessibility defect where the collapse and expand content has unfortunately been coded incorrectly rending all the content hidden to screen readers.

ASD's motto is "reveal their secrets protect our own" and it's this line which unfortunately has been taken a little too literally. Up to this point what ASD did was a pretty good attempt to make a complex image more accessible, however it all comes down to the execution.

The contents are contained in an accordion control. It's been built with several aria attributes that convey the visual behaviour to a screen reader. When it's expanded the screen reader announces "expanded" collapsed for "collapsed" all pretty standard stuff and follows established patterns for screen reader usage.

Except when it comes to this little attribute aria-hidden"true". Every time a panel is toggled this too should be toggled to allow a screen reader to find the content. And this the problem, this remains set to true meaning all content now matter what is shown to the user is hidden from the screen reader rendering the shown content invisible to a screen reader. This is unfortunate but it demonstrates that accessibility is hard, time pressures and unfamiliarity with accessibility means that mistakes like this can and do creep in. The fix however is easy and that’s ensuring the value is toggled in line with the showing and hiding of the content.

For the nation’s top breakers, progressively enhancing a complex image using semantic HTML points to a technique you can take away for your digital projects.

The power in the web is its adaptability. Content created with semantic HTML means content doesn’t just need to look good, but it needs meaning and that is what semantic HTML provides. Don't just make your content look good visually, make your content have meaning. Semantic HTML for the win!

Thanks for listening, I'm Ross I'm director of CANAXESS a digital accessibility company based in Australia but working globally. We work with lots of interesting teams around the globe and if you're interested in working together, reach out to us at hello@canaxess.com.au that's "C A N A X E S S".

Mastering Accessibility Acceptance Criteria for better user stories

2024-09-29T00:00:00Z

Video transcript

Documenting accessibility requirements for user stories is hard.

When trying to describe which accessibility behaviour to build into the early requirements, it either becomes meticulously documenting all the relevant WCAG criteria for the feature or mentioning "refer to WCAG" and hope the accessibility gods look favourably on the developer crafting the feature.

Onscreen is a slide showing several people all shrugging their shoulders demonstrating uncertainty.

The people creating the user stories are Business Analysts who are confident translating business requirements into work tasks but understandably have limited knowledge of WCAG. They know it’s important but translating that importance into actionable detailed criteria which a new feature must demonstrate is unfair, it’s unfair to put so much emphasis on BAs to ensure the right accessibility criteria are highlighted when they're not experts in WCAG.

The people with this expert knowledge are accessibility specialists, but these specialists are also so few in large organisations that its impractical for every user story to have an accessibility specialists’ oversight and tick of approval of what criteria to include.

The accessibility specialists tend to be a small team supporting many other teams all doing a range of features with numerous user stories simultaneously. This model of operating works well with 2 teams as its usually quite manageable to provide constant focused accessibility advice, but with three teams it becomes challenging and adding a 4th and 5th team to the mix well it's not a great outcome, teams are trying to create numerous bits of functionality with increasingly limited resources and the delivery of new features isn’t going to slow down whilst they wait for this detailed advice to be provided.

The accessibility team's ability to provide timely and knowledgeable advice is impacted. As teams grow ever larger it becomes increasingly difficult to detail good accessibility practice.

Our collective best accessibility documentation efforts begin to break down into copy and paste from previous user stories, and a lot of holding our heads in our hands when a feature is inevitably created with less than stellar accessibility.

What if there was another way, that balanced the needs to document accessibility but not be so onerous for the BAs creating the user stories. Well, there is!

Over several months we co-created accessibility acceptance criteria with a supermarket. And they've been used incredibly effectively for all user story development. These accessibility acceptance criteria are applied when user stories are created.

And we flipped the perspective on how to provide detailed accessibility advice.

Instead of being developer-focused describing in intricate detail which WCAG guidelines to include, they’re BA-focused

and describe key behaviours the finished feature needs to display

but the criteria don’t specify how to do it

They describe an outcome which the feature must demonstrate

They define the boundaries of a user story and what to focus on for the developer and are used to confirm when a story is complete and ready to be developed. They're written in simple language and because of this they're more easily understood by all members of a team who have different expertise and varying levels of fluency in each other’s role.

The intention was accessibility criteria for a developer could be created by a BA.

In theory this all sounded great, a new way to document accessibility without having to wade through WCAG! but there are still 50 WCAG success criteria to document in some capacity. How to condense all of that?

We didn’t want to just replicate WCAG in another format, so our starting point was to identify and group common accessibility failings, those issues which crop up again and again from our testing and internal accessibility reports.

We added broad criteria like keyboard inaccessible content, unclear focus effects and form control labelling. This gave us 20 acceptance criteria, which is still quite a lot, and this was whittled down further to 10.

We settled on 10, because if there's less than 10 criteria we're probably missing out key accessibility requirements whereas greater than 10 it becomes a burden to apply. 10 seemed to be that sweet spot.

These 10 issues were common failing, high impact criteria identified from the prior internal work of the team which align to one or more WCAG success criteria.

They are:

Keyboard Accessibility
Content on hover
Page title
Visible focus
Semantic markup used appropriately
Form control labelling and inline errors
Screen reader
Zoom & resize
Alt text
Orientation & reflow

Each criteria uses the behaviour driven development format describing how the desired behaviour is described. The BDD format puts the user at the centre of the story development, describing a type of user, something they’re doing and the expected output. And it helps reduce the documenting of requirements to build gap between the business analyst and other technical users like developers.

This format usually has two sections:

The Narrative – This is where the purpose and the value of the feature are explained.

User Acceptance Criteria – This is where the scenarios of a feature are explained.

Given I am a: Type of user When I encounter: The type of content being created Then I can: The expected outcome

The main advantage of using the BDD approach for user story writing is that it improves team collaboration. The user story explains the requirement in non-technical language when delivering the feature.

Because it uses simple language, the developer can understand it as well as the BA, tester and product owner. The development team can refer to it to understand the requirements in an easy-to-understand way helping to reduce assumptions and the often back-and-forth communication between them and an overstretched accessibility team. Applying this format to accessibility acceptance criterion number 1 keyboard accessibility gives:

“Given I am a keyboard user when I encounter interactive content then I can control it solely from the keyboard.”

This identifies a keyboard user and the type of content which the user interacts with. Things like buttons and links and the outcome for those is that they must be controllable from a keyboard.

This maps directly to WCAG success criterion 2.1.1 keyboard and is easier to digest and understand, make interactive content usable from the keyboard is a lot easier to understand than simply providing the link to the success criterion.

A lot of the detail in this success criterion including specific timings for individual keystrokes and exceptions has been left out as we wanted something that was simple to understand and apply. If more detail is added it potentially slows down the delivery timeframe with teams having to understand and unpick the detail. We didn’t want to try and boil the ocean and document every possible situation for keyboard use, its balancing to providing broad guidance with just enough detail.

If we attempted to document all the detail in 2.1.1 then really, we've not improved things we would have duplicated WCAG. We didn't want to place the burden of having to decoding WCAG on the shoulders of the BA’s or developers when they don't really know it. This approach we found is easy to understand, digest and apply.

The accessibility acceptance criteria combine detail both global accessibility issues and localised accessibility issues. AAC 3, AAC 4 and AAC 5 describe an outcome which probably wouldn’t be relevant for many user stories. Accessibility acceptance criteria number 3 page title ensures a page is titled appropriately and is understandable. Accessibility acceptance criteria number 4 visible focus ensures a user's keyboard focus is always visible wherever they are on the page. And Accessibility acceptance criteria number 5 Semantic markup is used appropriately ensures lists of items, headings and tables all use the correct semantic HTML elements to describe meaning. It's unlikely these Accessibility acceptance criteria would be applied for every use story as the features they're describing are more global in nature.

I mentioned earlier that 10 accessibility acceptance criteria were created, but taking it account the global nature of 2 possibly 3 criteria, and how they probably won't be referenced regularly, means its 7 issues to be applied. This is quite a reasonable expectation for business analysts to understand and apply.

If we look at Accessibility acceptance criterion 6 form control labelling and inline errors it describes the requirement for labelling form controls and inline errors appropriately. Instead of multiple acceptance criteria for different parts of the form this combines several success criteria into one statement.

“Given I use a screen reader when I focus on form controls then I can understand what type of data is required.”

This maps to success criteria 1.3.1 Info and Relationships for accessible form labelling and 3.3.1 Error Identification.

This is centred on a screen reader user. So, if a form feature is being created and the screen reader can output form labels and error messages, there is a greater likelihood it's built correctly for other assistive technologies to understand. We assume that providing a screen reader specific user story will also mean we’ve supported other assistive technologies.

There is an expectation that as our development teams were building out a feature, they’re performing rudimentary screen reader testing. It doesn’t stop them from coding in incorrect behaviour but if they’re able to achieve the output determined by the accessibility acceptance criteria then we know we're developing form labelling and error messages correctly.

Accessibility acceptance criteria number 7 screen reader describes the requirement that any client-side screen updates are output by the screen reader. The technology the organisations web app was being created in was a single page application, we knew previously these sorts of applications had problematic issues when content is updated on the client side without a hard refresh.

So, we wanted to create a requirement that captures everything which updates once the page has loaded since these are often pain points where the change is only provided visually. Trying to capture all the complexity and nuance resulted in this requirement to be announced by the screen reader.

Using the same format for this criterion gives:

"Given I use a screen reader when a visual change occurs on the page then I can understand the change audibly. E.g. search results displaying while searching, errors displaying after activating submit button".

This identifies a screen reader user, the situation being encountered which is when something changes visually. And the outcome from that change should be output by the screen reader.

This maps to 4.1.2 name, role value. It’s a shorthand way for trying to distil all the technical detail in the WCAG criterion into something easy to understand.

Accessibility acceptance criteria number 9 ALT text describes the requirement that any descriptive images be understood non-visually.

Using the familiar format for this criterion gives:

"Given I use a screen reader when I encounter a descriptive image then I can understand the non-visually. This describes a screen reader user, the situation which is encountered a descriptive image. And the outcome should be descriptive images can be understood because a text alternative is provided.

This criterion maps to 1.1.1 non-text content. It's prefaced with ALT text as the technique to apply but really there is scope for any text alternative for descriptive images. We found most of the time it's just by providing ALT text but equally other methods which can do the same thing are included (although they're not mentioned).

Whilst we were pleased with these outcomes, I stilled struggled with this list of 10 items. There was a sense of they seem basic is there more to it, should there be more to it?

I've read lots of articles where people have baked in accessibility requirements early and everything becomes a well-oiled machine. But what the articles often leave out is the development teams are small, and the accessibility team is tightly integrated into the delivery process, and it makes it far easier to collaborate.

When there are several teams, each creating features simultaneously, this utopian model of documenting and building in accessibility and close collaboration becomes increasingly difficult.

We’re always looking for a “silver bullet” that addresses all the accessibility challenges to building an accessible web. Every approach has at least one downside when put into action. And perhaps the biggest challenge that comes with this technique is the absence of WCAG criteria in detail.

Onscreen shows two developers approaching the coding of acceptance criteria 6 form control labelling and inline errors differently. One developer codes the feature with a label element programmatically connecting it to the form control named "Name", whilst the other developer uses the aria-label attribute with a value of "Name".

The acceptance criteria do not discuss how the feature needs to be built they’re only focused on the outcome. A developer developing a user story may not fully understand how to proceed with the implementation without having the technical details in place. Or two developers approach the accessibility requirements in widely different ways. As long as the end result is met is this a problem if two developers approach it differently? This technical information still needs to be given to the developers via a different mechanism.

But we found accessibility acceptance criteria are a way to triage the documenting of accessibility information and keep it in focus and make it tangible to help teams document what accessibility behaviour is required. Rather than a hand wavy approach of “make it accessible”.

The accessibility acceptance criteria aren’t perfect, there are gaps, and they don’t replace the accessibility support provided by a dedicated team, but they do complement the training we were already providing to the BAs and developers.

Taking lessons from the computer security industry this is defence in depth, it’s ensuring the often-quoted advice of bake in accessibility or shift left means every member of a team is doing a little bit with accessibility. Even though accessibility is reliant on good accessible code it’s no longer a developer centric task only.

The criteria encourage progress over perfection, we needed some mechanism to capture early requirements at the user story stage which would take the pressure off the small team and empower development teams to self-serve themselves more effectively. In essence less accessibility hand holding and more self-serving.

But let's trial it out with a hypothetical new feature to be developed, a dialog. The business analyst understand that dialogs need to built in the correct way, be navigable from the keyboard and have a visible focus. So, the AACs applied reflect this.

AAC1 keyboard access – ensuring the dialog is keyboard focusable, because the dialog needs to have the ability to be closed from the keyboard.

AAC4 visible focus – any keyboard focus effect within the dialog is visible

AAC7 screen reader – the dialog is announced by the screen reader and uses the correct aria authoring patterns

All these cover the basic behaviour this new feature requires.

Using the AAC’s means they don’t reduce the accessibility analysts support but they make the support targeted and is a way of identifying earlier enough where the developers' efforts with accessibility should be focused. Once a feature is built, there was still the expectation for teams to reach out and for us to perform spot audit checks of the feature prior to release to production. None of that goes away, it all continues.

But I like absolute outcomes, I personally like the familiar way of documenting requirements for new features in such a detailed way that when the story is handed over to a developer there is no ambiguity, they build from a complete blueprint. It gives me a sense of security knowing that I've done all I need to do.

But this approach doesn’t encourage teams to self-serve, and it doesn’t encourage teams to learn and understand accessibility, it encourages a copy and paste approach. If they’re copying and pasting technical requirements, the developers aren’t understanding the how or the nuances.

This approach ultimately becomes less effective. In large organisations with many teams all working simultaneously you can't realistically provide that level of support. You must accept levels of overlapping support are what's needed, combine these AAC's with developer training, checklists, resources, and the ongoing support of accessibility analysts. Sometimes the perfect accessibility outcome, is imperfect and that’s ok.

Accessibility teams tend to be small. But this small footprint allows for innovative and nimble practices and scale up support in ways which are pragmatic. And this is what accessibility acceptance criteria are, they’re pragmatic.

They bridge the gap with providing just enough guidance where user stories can be created without becoming bogged down in what perfect accessibility looks like.

But they're not for everyone. You may be in a small team, working well with BAs and Developers and in that case keep doing what you're doing. But if you begin finding the documenting of requirements is slowing down and impacting the delivery of features, then accessibility acceptance criteria may be another approach.

We found that overtime as teams became familiar with the AACs testers began having difficulty understanding what is actually being tested. There was a sense of inaccurate understanding developing with what each accessibility acceptance criteria meant.

So, we created a companion document 'testing with the AACs' as a guide to give testers a consistent approach to interpreting and understanding if the AAC’s have been applied correctly. Using language testers are familiar with.

And this in turn then led us to thinking about other companion documents, including developing with the AAC. Being BA centred meant us looking at things other than code, yet recognising there was still a need for testers and developers to have the own documentation.

But how did it turn out for us?

Overall, the accessibility acceptance criteria worked well, they enabled teams to self-serve their accessibility requirements on their own without our support. Which on the face of it sounds pretty good.

Over time however we noticed a few unusual trends between the teams. Some business analysts were very confident applying the AAC’s and would tag us in messages to confirm everything had been identified. And that showed they were thinking about the feature and how requirements could be applied to that.

Yet other teams adopted a cut and paste approach of pasting all criteria into each user story and asking us to confirm its correct, but really wanting us to trim the story down to include only those criteria relevant.

Looking at it pragmatically has it made a difference? that’s difficult to determine. Sure, with spot audits, the incidence of low hanging accessibility errors reduced, but was this due to the AACs?

Ultimately, it’s the developers producing the code that is either accessible or not. Being passed a user story with accessibility acceptance criteria called out is helpful, but if you’re using a design system with a regular suite of components over time the accessibility will become better.

Issues identified are fixed, pushed out and all teams then consume. Really this is helping with the approach of building awareness of accessibility. But it’s difficult to determine if shifting less and including more criteria at earlier stages in the build process is helping or just performative.

When you’re so focused on the correct code you only see code-based solutions and blueprinting accessibility requirements comprehensively and intimately becomes the go to for every occasion.

I’m not saying that isn’t needed and there certainly is a place for documenting that level of detail somewhere and that place is often in smaller more agile teams, but I also don’t believe the effort should rest on the shoulders of BA’s alone. Anything that significantly affects the delivery means accessibility becomes the blocker and is reduced in scope or ignored.

Accessibility acceptance criteria aren’t for everyone, but they may help you document core accessibility behaviour earlier enough that helps teams further up the production pipeline to be aware of outcomes which need to be demonstrated.

There is a GitHub repository which has the accessibility acceptance criteria along with a testing document. That's found at github.com/canaxess/accessibility hyphen acceptance hyphen criteria.

Thanks for listening, I'm Ross I'm director of CANAXESS a digital accessibility company based in Australia but working globally.

We work with lots of interesting teams around the globe and if you're interested in working together, reach out to us at hello@canaxess.com.au that's "C A N A X E S S".

The Accessibility Acceptance Criteria are kindly shared by Mel O'Brien publicly through her GitHub repository, the original IP belongs to Coles.

Canberra’s New Ticketing System MyWay+: A Step Forward, But Not for Everyone

2024-12-08T00:00:00Z

A government digital accessibility policy should mean all digital services built are accessible. Unfortunately for Canberra’s new ticketing system MyWay+ it means people with disabilities are once again forgotten, and the Australian Capital Territory (ACT) Government's own digital accessibility policy ignored.

MyWay+ is the new integrated ticketing system for Canberra. Covering the bus and light rail network spanning Gungahlin in the north to Tuggeranong in the south.

It provides journey planning, live service updates and more ways to pay. Everything we’ve come to expect from a modern digital ticketing system.

But in addition to a well-publicised poor roll out, digital accessibility is another component of the system that's been poorly implemented. Assessing the login page against the web content against the Web Content Accessibility Guidelines (WCAG) shows many bugs.

Very low text colour contrast

The accessibility problems begin with several colour contrast bugs. If you’re thinking the buttons Quick Top Up and Buy a QR ticket are difficult to see you’d be correct.

The colour contrast analyser tool showing the minimum contrast ratio of 1.5:1 of the white text set against the grey background.

The text colour of the buttons against the grey background have a contrast ratio of 1.5:1 far below the minimum requirement of 4.5:1 set in WCAG.

This is followed by equally poor colour contrast with the dark grey acknowledgement of country text against the colour ribbon.

The colour contrast analyser tool showing the 'Welcome to country' acknowledgement in dark grey against a coloured background. The ratio is 1.6:1 far below the WCAG minimmum.

Even at the most optimistic, the ratio is still only 1.6:1, again far below what's considered accessible. Smaller screens may reflow content onto the lighter background making it not as much of a problem, but it’s not a good start.

This design decision affects users with a colour vision impairment. When the contrast ratio is less than 4.5:1 people with reduced levels of vision have an increasingly difficult experience identifying content. This means fewer people can identify foreground text against the background.

Unlabelled form controls

The accessibility problems continue with poor labelling of the form control Username and the Remember Me checkbox.

The labelling for Username is from the placeholder attribute, and its use is widely discouraged by the accessibility community.

The accessibility tree of the Username input control showing the placeholder attribute complete with the words 'Enter Username'.

It’s a technique for labelling controls that's unlikely to work consistently across browsers.

Whilst the Remember Me checkbox has no programmatic label. The label - even though visible and placed next to the control - remains unannounced by a screen reader as it isn’t programmatically linked.

It’s missing a key link that screen reader software rely on to make controls understandable.

The accessibility tree of the 'Remember Me' checkbox showing an unlabelled control with no labelling or programmatic name applied.

The absence of a programmatic label for Remember Me and reliance on the placeholder attribute for Username reduces the ability for blind users to signup effectively.

Unreachable page links

This brings us to the showstopper of accessibility failings. The lack of keyboard navigation on prominent links.

People with hand tremors or mobility weakness can find mouse navigation difficult and may instead prefer keyboard navigation. Yet the links Sign up, Recover Account and Forgot Password are all unreachable when using the keyboard due to a missing href attribute.

The signup form showing the links 'Sign Up', 'Recover Account?' and 'Forgot Password?' all highlighted by a box indicating they are not keyboard accessible.

This means the core functionality of the signup process is unreachable. If you’re a keyboard user, you’re effectively shut out of the entire signup process.

These three bugs though are barely scratching the surface of the accessibility of the digital platform. In isolation, a Remember Me checkbox missing a label or poor colour contrast probably won’t have a huge impact.

But this is just one screen. It points to a likely pattern of accessibility not undertaken across the entire digital platform.

If a government-created digital ticketing platform is intended to be used by the entire community. Then it must be usable by the community on all platforms and devices. Be it mobile, or desktop with and without assistive technology.

A 20+ year “new thing”

Web accessibility isn’t a new thing. WCAG has existed since 1999. Within Australian government circles web accessibility is a standard requirement for any digital service built.

The Australian Capital Territory (ACT) government has a web accessibility policy requiring all digital services to be accessible for people with disabilities. And this is supported by the Disability Discrimination Act (currently being updated) which describes equal access as a right. Web accessibility isn’t an unknown concept.

It’s difficult to not criticise every design decision. The intention of making it easier for all Canberrans to use public transport is a great aim.

But the MyWay+ project has by some estimates cost the local Canberra community $70 million dollars. There is a digital accessibility policy guiding all digital development for the ACT government, it should have been followed.

Digital accessibility should have been a core part of the project.

What could help in a situation like this?

But it’s not all negative, improvements can be made. First audit the existing digital platform for conformance to WCAG. Understand where the existing accessibility bugs are and begin fixing them as part of the backlog.

Combine this audit with a regular iterative cycle of auditing to check what is delivered by business analysts, designers and developers throughout the entire delivery process is accessible.

This ticketing system is for all Canberrans, but the accessibility bugs identified on the login page show that once again disabled people weren’t considered in the design stage and what’s built is another poorly accessible government digital service.

If you want to learn more about our accessibility work and how our team can help your organisation avoid some of these challenges, please get in touch with us at hello@canaxess.com.au.

Why Accessibility Overlays Fall Short - and What to Do Instead

2024-12-15T00:00:00Z

A lot has been written about "disability dongles" a term coined by Liz Jackson to describe tools that claim to solve problems for disabled people but often fail to deliver.

One example is the stair-climbing wheelchair. It seems like a great solution but is too expensive, impractical, and, for many users, unsafe.

Many websites rely on the digital equivalent of such dongles - accessibility overlays. These widgets promise to make websites more accessible by allowing users to adjust text size, change colours, or provide basic image descriptions.

A generic accessibility overlay widget showing several options to toggle on accomodations for disability types and options to increase the contrast.

They also claim to protect website owners from legal risks by bringing sites into compliance with accessibility standards like WCAG. At first glance, it sounds like a win-win.

But here’s the problem. These widgets don’t work as advertised.

Why Overlays Fail to Deliver

Accessibility is complex. Real accessibility requires:

Custom descriptions for unique images that provide meaningful context.
Buttons and links designed for seamless keyboard navigation.
Forms that are fully understandable to screen readers.
And the list goes...

No widget can automate this work, not even AI-powered widgets. Overlays apply generic fixes without understanding your website’s specific needs.

That “picture of an ocean” on your homepage? A widget might label it as "ocean," but it won’t explain its relevance to your content.

Overlays promise compliance, but their claims are misleading. They don’t make your website accessible, they don’t lower your legal risk, and they may even increase it.

U.S. lawsuits have proven that relying on these tools is not a safeguard against litigation.

A Better Solution

Instead of relying on ineffective quick fixes, we offer a comprehensive service designed to:

Identify real accessibility barriers in your website’s code.
Provide actionable insights so you can begin addressing these barriers meaningfully.
Enhance the user experience for disabled people, ensuring your site is more accessible and reducing the risk of costly lawsuits.

Accessibility is not just about avoiding lawsuits - it’s about creating a better experience for all users. Let us help you do it the right way.

Ready to begin making your website more accessible and inclusive? Let us help you deliver a better experience for all users and begin meeting compliance standards.

Accessibility Lessons from the MyWay+ Rollout

2025-06-24T00:00:00Z

The outcome of the government inquiry into the MyWay+ digital ticketing system

In November 2024, The Australian Capital Territory (ACT) Government launched its long-awaited MyWay+ digital ticketing system, a $60 million public investment intended to modernise how the community access and pay for public transport across the territory.

But from the outset, the system was plagued with issues. None more concerning than its failure to meet accessibility standards.

A promised commitment to accessibility

Accessibility wasn’t a side note. The public contract made clear that the MyWay+ system must comply with WCAG 2.1 accessibility standards, ensuring equitable access for all users, including those with disabilities.

This was not a recommendation, it was a core contractual requirement.

Yet, our early assessment showed otherwise. Several screens exhibited significant accessibility barriers.

These were not edge cases or theoretical limitations. They were clear, preventable design and coding errors affecting real users.

We presented our findings [PDF] to the Legislative Assembly public inquiry, raising concerns that we believed many in the disability community had already begun experiencing firsthand.

What the inquiry revealed

During the public hearings, representatives from NEC (the contracted vendor) and Territory Transport Minister Chris Steel appeared at the inquiry to respond to questions submitted by the public.

What emerged was a disappointing picture of how accessibility was handled in this large, complex project.

Key findings included:

NEC was contractually obligated to deliver a fully WCAG 2.1 compliant system.
Transport Canberra confirmed that NEC gave no advance notice before launch that parts of the system would fail accessibility requirements.
A chance to engage accessibility experts early was declined internally by the project team, citing cost and perceived adequacy of existing processes.
The ACT Government allowed MyWay+ to go live without full compliance, relying on NEC’s post-launch assurance processes.
Only on 29 January 2025, several months after go-live, did NEC formally advise that the Customer Portal was only partially compliant.

In response to the growing concern, NEC has since engaged an external vendor to conduct a full accessibility assessment of the MyWay+ platform.

This work began in March 2025, and NEC is covering the cost of these remedial efforts.

Accessibility as an afterthought

It’s important to acknowledge that accessibility wasn’t ignored entirely. It was referenced in contracts. It was mentioned in planning documents.

But in practice, it was not embedded. It was something to manage and assess later, not a core value shaping decisions from the outset.

This is critical, because accessibility flaws are not abstract design debates. They’re defects.

And according to the US government's National Institute of Standards and Technology (NIST) "The Economic Impacts of Inadequate Infrastructure for Software Testing" report [PDF], fixing software defects after deployment can be up to 30 times more expensive than addressing them during design and development.

And that doesn’t speak to their brittleness with how supportive the fix is for people with disabilities.

Post-launch testing we've since conducted shows NEC is now actively fixing these defects, and that’s commendable. But these fixes are largely tactical.

They aim to meet minimum WCAG conformance, not to deliver best-in-class or innovative user experiences for disabled people.

A rare opportunity to radically improve digital inclusion in a public-facing, next-generation transport system has been missed.

6 Lessons for government and industry

There are however clear takeaways for any large-scale digital transformation project:

Treat accessibility like security or data integrity. It's foundational, not optional.
Implement third-party audits early and often.
Embed accessibility expertise from design to deployment.
Assign clear, accountable roles across vendors, government, and delivery partners.
Accessibility should be a go/no-go criterion not a deferred checkbox.
Accessibility is not just technical; it’s a human rights and public trust issue.

A final note

For the ACT Government and NEC, the words of Frank Sinatra’s hit song "My Way" feel particularly apt:

Yes, there were times, I guess you knew, when I bit off much more than I could chew…

MyWay+ had the incredible potential to set a new standard for inclusive digital infrastructure. Instead, it became a lesson in what happens when accessibility is treated as an afterthought.

Let this not be the end of the conversation, but the beginning of doing better.

A closer look at Apple’s Accessibility Nutrition Labels

2025-06-30T00:00:00Z

A clearer picture of accessibility in the App Store

Until now, users downloading apps were in the dark if the app supported accessibility features on an iOS device. That's now changed with Accessibility Nutrition Labels introduced at Apple Worldwide Developer conference (WWDC) 2025.

These labels help users understand if an app will be accessible prior to downloading it. The system is currently voluntary and allows teams to show which accessibility features on the device their app supports including VoiceOver, Voice Control, and Captions.

Whilst optional to begin with, Apple has announced teams will have to provide accessibility support details when submitting new apps and app updates to the App Store. It won’t be a "set-and-forget" process. Labels will need to be reviewed and supported regularly to keep this information accurate and up to date.

Nutrition label location

The labels appear on an app’s product page in all countries and regions where the app is available and displays the labels specific to the device type. If a feature isn't specified for a device, the label shows "not indicated."

Within the App Store, the Accessibility Nutrition Labels highlight accessibility features in use in the app.

Labelling can be provided for each target iOS device, but it won't be one label for all. So, expect to plan for different devices having differing levels of accessibility support. Which potentially introduces a greater level of post deployment app management overhead.

As part of the labelling the option exists to provide an accessibility URL that links to a website where users can learn more about the app’s accessibility features.

This URL should correspond uniquely to the app and can include information such as other accessibility features. Could this URL theoretically correspond with the website accessibility statement? No, a statement is specific to the website. A separate accessibility page just for the app will also need to be created.

Searchable by feature

Starting from September 2025, users will be able to include Accessibility Nutrition Label features as part of their search query to make their results more relevant.

For example, a user could search for "VoiceOver note taking apps" or "exercise apps with Larger Text".

Planning for your response

When planning to implement accessibility labelling, it's crucial to ensure your app accurately conveys its accessibility support. If there is intentionally misleading labels, App Review will contact you and ask you to update the Accessibility Nutrition Labels.

The App Store has preset evaluation criteria you should meet before showing support in the Accessibility Nutrition Labels. You should assess your app on each of the targeted devices your app supports.

To show support for an accessibility feature in the Accessibility Nutrition Labels, users must be able to complete all the common tasks of your app using that feature. If you decided to provide a nutrition label for VoiceOver, then all common tasks of your app must then work with VoiceOver.

Identifying your app common tasks

Which segues into the question "what are my apps common tasks?".

For this compile a list of the common tasks that a user can perform in your app. These consist of the primary functions that you expect users to perform, plus functions that are fundamental to using the app. These could be first launch experience, login, purchase, and settings.

Remember to show support for an accessibility feature, a user should be able to perceive, operate, and understand all the primary functionality specific to your app while using the feature.

Summary

There's plenty to unpack, but Apple’s Accessibility Nutrition Labels improve how accessibility is communicated to users. While still voluntary for now, they signal a move toward greater transparency and accountability in app development.

For teams, this means planning, testing, and supporting accurate accessibility claims across all iOS devices and features. For users, it means more informed choices and a more inclusive App Store experience.

Start preparing now because come September 2025, accessibility won’t just be a feature, it’ll be a search filter.

This is the first post in our series on Apple's Accessibility Nutrition Labels, where we continue to explore what they mean in practice and what teams need to consider

More than a checklist. We help you turn accessibility into real progress

2025-07-07T00:00:00Z

What kind of accessibility support do you need?

We regularly talk with teams who know they need to "do something" about accessibility but aren’t sure where to begin or what kind of assessment makes sense for their situation.

That’s normal. Accessibility needs can look very different depending on your goals. Maybe you’re navigating a procurement requirement, trying to improve the experience for a broader audience. Or maybe you just want to understand how accessible your product is when launching a redesign.

We don’t treat assessments as a one-size-fits-all service. We work with you to understand what you're aiming for. What constraints you’re working within, and how far you want to go so the accessibility assessment actually delivers useful and relevant advice.

Perhaps it's a quick accessibility pulse check of key user journeys or a deep dive into compliance and usability across your entire product. Whatever approach is right for you, we make sure it delivers meaningful, actionable insights that support your product’s next steps.

Accessibility assessments that drive real progress

An accessibility assessment should never be just a checkbox. It's the starting point of a broader journey that can help your organisation reduce risk, improve user experience, increase customer satisfaction, and build long-term loyalty through inclusive design.

Some teams simply need to demonstrate compliance or respond to a client, and we can support you with the request. But if your goal is to make meaningful improvements and embed accessibility into how you work, you'll want more than a standard report. You'll want a partner who understands the bigger picture and can support you at every step.

That is what we're good at.

We don't just hand over a list of accessibility problems. We work with you to understand the meaning behind the issues, prioritise what matters most, and provide clear, practical guidance enabling you to move forward with confidence. Whether it's technical fixes, process changes, or capability building, we tailor our approach to meet your needs, not just tick a box.

We've seen what happens when businesses go with cheaper options. Rushed audits, vague reports, and no real path forward. Many of our clients come to us after learning the hard way that an low-quality assessment can cost more time and money in the long run.

Why our assessments stand out

The truth is not all assessments deliver value. Ours are built to support your team in making lasting improvements. Every assessment includes:

Comprehensive issue coverage. We don't just report the first instance of a problem and move on. Every issue we find across your selected pages or views is documented, so you have the full picture without extra legwork.
Meaningful context. Each issue is explained in terms of who it impacts and why it matters. This gives your team a clear sense of purpose behind every fix.
Severity ratings that support smart prioritisation. Not all issues are equal. Our severity scale helps you focus on the areas that will deliver the greatest benefit to your users.
Actionable, tailored recommendations. Our advice is specific to your site and technology stack. We include code snippets and examples based on your actual implementation, not just generic WCAG references.
Best practice guidance that goes beyond WCAG. You've got to get the basics right, but accessibility is not only about compliance. We bring real-world experience understanding how people with disabilities navigate the web, and we use that to help inform your designs for equity and usability, not just standards.

The result? Your team spends far less time decoding the assessment report and more time fixing what matters.

Our testing methodology reduces effort, builds internal capability, and helps you create digital experiences that work better for everyone.

Why the right accessibility partner matters more than a big name

There are more and more companies in 2025 that could do your accessibility assessment. Some of these are established well-known brands, whilst others are up and coming. Choosing a well-known accessibility company can seem like the safe option, but it often comes with trade-offs.

These can include rigid processes that expect you to adapt to their way of working. That’s not how we operate. We take the time to understand your context, respect your priorities, and work with you to deliver assessments that are detailed, relevant, and genuinely useful to your team.

The thing is, accessibility isn’t just about ticking boxes. It’s about really understanding how the code works together, and that’s our comfort zone. We’re developers who dig into the code to figure out what’s actually going on.

We’re not a design studio experimenting with accessibility, or a digital agency offering audits as a side service. Our sole focus is accessibility, and we bring deep technical expertise to every engagement.

We don’t just point out what’s broken, we help you fix it. From untangling complex code issues to improving how accessibility is integrated into your design and development workflows, our goal is to set you up for long-term success.

We work with you to build real capability, so accessibility becomes something your team can own and sustain not just a once-off cost, but a lasting benefit.

If you are looking for a long-term partner in accessibility, not just a service provider, we would love to help please. Get in touch with us at hello@canaxess.com.au.

Key Accessibility Takeaways from Google I/O 2025

2025-07-14T00:00:00Z

Here's what caught our eye

The Google I/O 2025 conference took place over a month ago, and we've spent time digesting the main accessibility-related themes.

The one central theme is reducing the need for custom-built components like carousels and select boxes, shifting more of the heavy lifting to the browser itself.

Built-in browser carousel support. Carousels can now be created using just CSS, eliminating the need for JavaScript-heavy implementations. This helps avoid many of the accessibility pitfalls common in custom carousels. However, support is currently limited to Chrome and Edge, so it’s a promising foundation rather than a drop-in solution.
Stylable <select> element. A long-awaited improvement that allows full CSS styling without sacrificing keyboard support. This eliminates the need for brittle JavaScript replacements, but developer awareness will be key to widespread adoption.
Baseline project coverage. The Baseline initiative now reflects nearly 100% of web platform features and includes mobile support. It offers developers a reliable way to identify which features are safe to use across browsers. Though time will tell whether it becomes a core part of daily workflows or remains a helpful reference on the side.

Summary

While accessibility wasn’t a headline topic at Google I/O 2025, the underlying improvements to native HTML components are a step forward.

There's less reliance on JavaScript and better built-in behaviours for common controls.

These features support accessible development by default though cross-browser limitations mean they’re not quite ready for full-scale adoption.

Digital accessibility in Australian retail

2025-10-22T00:00:00Z

Point of sale (POS) terminals, smart checkouts, public facing smart displays and employee smart displays. There’s a lot to unpack with what accessibility requirements need to be met within the retail environment in Australia.

Australian federal law

The Disability Discrimination Act (DDA) is the federal law that makes disability discrimination unlawful in defined areas of public life. Section 24 of the DDA relates to the provision of goods and services.

“Any digital good or service created for people to consume, engage with and/or control including digital content, applications, systems, and services, including self-service kiosks and systems required to complete a task at work.”

Whilst the DDA is law, Australia has had few complaints of disability discrimination. The complaints it has had include:

The Coles Group settled out of court with an undertaking to make the digital experiences of their supermarket website accessible including mobile apps and point of sale terminals.
The Commonwealth bank had a complaint made against its 'Albert' Touch screen POS machine, and it too settled out of court with agreement to enhance the accessibility of the device and digital experiences.

ARA code of ethics

The Australian Retailers Association (ARA) code of ethics contains two applicable principles which we consider accessibility centric.

Professional behaviour complying with the relevant laws
Regulations and caring demonstrating genuine care and respect for human dignity.

Although there’s nothing specifically discussing accessibility requirements both principles are open to interpretation.

Following the professional behaviour complying with the relevant laws requirement can be viewed as adhering to the principles in the DDA by providing digital technology that is non-discriminatory.

Equally respecting customers individual diversity with disability is addressed with Regulations and caring demonstrating genuine care and respect for human dignity.

There is a clear argument to be made the ARA code of ethics supports an accessible digital experience for customers. Where it becomes uncertain is the scope of the digital technology covered, which ultimately may be decided on a case-by-case basis.

Self-checkout kiosk

It is our opinion self-checkout kiosks are in scope with the DDA requirement. A customer must directly interact with the kiosk.

Therefor a kiosk that does not provide accessibility support means a customer encountering difficulty completing their shopping task, and in some instances not completing it at all would be in contravention of the DDA.

Sales associate display

Considering all job roles now contain an element of digital use, all digital technology a sales associate uses is in scope. A sales associate’s task of interacting with digital technology that has no alternative accessible method would be in contravention of the DDA.

Public facing display

Public facing displays may be in scope depending on the context they are used and would hinge on the definition of “service” with the content displayed.

Is a service or information only provided through the display? Whilst this scenario may be true, the addition of customer service staff means a customer has an alternative means of identifying the information.

If the display is unattended and is the sole way of providing information this may be in contravention of the DDA.

Conclusion

With the update to the Australian Human Rights Commission advisory notes, digital accessibility requirements extend far beyond the traditional website or app. Any digital technology used by customers or staff is in scope.

Where there is uncertainty, such as in the case of public facing displays we suggest a pragmatic approach is taken and assume it is in scope.

Accessibility is less about managing risk, and more about improving reach with supporting customers with diverse needs.

The DDA is the requirement which has significant room for interpretation. However, there has been precedent with supermarkets and banks settling out of court and it’s these few cases where we encourage all retailers to provide accessible experiences through their entire digital platform.

Canberra’s wake-up call on accessible ticketing

2025-10-31T00:00:00Z

"It is astonishing that Transport Canberra and the ACT Government chose to go ahead with a system in which public transport users with vision impairments or mobility devices were negatively impacted and in some cases unable to use the service at all."

These were the words from the latest government report on the MyWay+ digital ticketing system [PDF] rollout, which confirms what we’ve raised for months, there were systemic accessibility gaps.

Some interesting observations in the report:

Accessibility compliance wasn't requested from the vendor until after release
There was no pre-launch accessibility assessment
If legislated requirements couldn’t be met, MyWay+ wasn’t ready to launch

Shipping while "accessibility is in delivery" is a go or no-go failure that excludes people with disabilities.

But the broader concern is if a major vendor struggled to deliver an accessible system at launch in a regulated, mature market, how many similar deployments elsewhere carry the same risks unseen where regulation and audit are weaker?

Accessibility must be a hard gate.

Any public-facing digital system needs three things funded accessibility from day one, independent testing, and a launch that only happens once it meets the standard. If you skip that, you’re shipping a broken product.

What we’ve said about MyWay+

How Australia's spy agency broke their website

2026-02-02T00:00:00Z

Video transcript

Now describing a range of physical characteristics of a coin to users of a screen reader isn't easy. ALT text could be used but then this becomes pretty complicated fast. Your having to include so much content describing the various embossed letters it would make listening to the audio description tiring.

Instead, they used semantic HTML, and more specifically, the <STRONG> element, to communicate the emphasis in a way CSS alone couldn't. The words "Side B" and letters "B", "TH", "A" and "S" were all contained in the <STRONG> element, all this because CSS styling isn't announced by screen readers.

But as of 2026, screen readers and assistive technology doesn't announce the <STRONG> element in any special way. But that doesn't mean it's not worth using. The strong element is still a smart choice for future-proofing content. If or maybe when screen readers get better at describing these nuances, users will automatically benefit.

But the clever part came undone. As brilliant as this technique was, the accessibility problem wasn't with the coin description. It's the accordion control used for the accessible text version.

At a glance the accordion looked correct. aria-expanded toggles from false to true when a panel opens, and back again when it closes. But the panel content also contains aria-hidden.

aria-hidden is a blunt instrument. When used well, content is removed entirely from the accessibility tree. It can be a perfectly valid technique to hide content you don't yet want screen readers to announce. But it's only valid if you keep it in sync with what's shown on screen.

So, whilst the accordion announced itself as opened and closed due to the aria-expanded attribute, aria-hidden on the panel containing the actual content doesn't change. The "accessible text" remained hidden to screen readers even when visible.

That single mismatch made the accessible text version … completely inaccessible to a screen reader. And as of February 2026 It isn't read out or announced in any way.

Now fortunately the fix is straightforward. When the panel is open, content must be visible to a screen reader so set aria-hidden to "false" (or remove it entirely). However when the panel is closed reverse this and set aria-hidden to "true".

What the Australian Signals Directorate did was genuinely clever. They used semantic HTML to add meaning and texture to describe a visual design detail. But one stale aria-hidden attribute undercut the whole experience.

Stale attributes mean when ARIA is used, it needs to be treated incredibly cautiously. Test the real output not just the markup and assume until tested with a screen reader the design is not yet complete.

Aria can significantly enhance experiences for screen reader users, but in the case of the Australian Signals Directorate and their commemorative coin it can also mask, hide and otherwise make accessible text, inaccessible.

And as always folks if you enjoyed this video and you want to get more from the best channel for digital accessibility make sure you've subscribed to CANAXESS.

Until next time, bye for now

Is Vibe coding the worst idea for accessibility?

2026-02-09T00:00:00Z

Video transcript

Unless you’ve been living under a rock, you’ve heard the term vibe coding.

It doesn’t just allow you to ship code faster.

It can also ship inaccessible code, faster, and at scale.

Vibe coding is an AI-first, prompt-driven way of building software. Gone is manually writing and debugging your code, instead you guide an AI tool to generate code, revise, fix errors and repeat.

The idea is you prototype faster. and ship minimum viable products faster, generating UI components and glueing it all together.

The term "vibe coding" comes from Andrej Karpathy. His idea is you give the AI a lot of freedom and your oversight gets lighter.

His description is unusual … "it’s not really coding in the traditional sense. It’s more like I see stuff, I say stuff, I run stuff, I copy-paste stuff, and it mostly works".

"Mostly it works" ……. This sounds like the worst idea for developing software, the "she’ll be right" attitude of not putting much thought into what you’re doing.

But putting cynicism to one side and thinking optimistically can this really be the accessibility nirvana we’ve been hoping for? Will AI handle all the hard parts of accessibility?

Of course not.

Web accessibility’s been around for over 20 years. It’s a core part of web development that needs rigour and technical understanding to get the best out of websites and assistive technology tools and make them work effectively. Most of the world has laws requiring digital platforms to be accessible. And yet, accessibility still hasn’t become a default part of delivering quality software.

The gap between digital systems and disabled people’s difficultly using them remains. The gap isn’t narrowing its remaining.

And one of the clearest signs of this continuing gap comes from WebAIM and their annual reports. The 2025 report scanning the top one million homepages identified, close to 95% of homepages had detectable WCAG failures. Things like low colour contrast, missing alt text, missing form labels, empty links, empty buttons, and missing document language.

And this is pretty basic stuff. If the web is full of these inaccessible patterns, what happens when we build systems which remix from these patterns at scale?

AI trained on huge amounts of web content reflects the world as it is, and the world is messy.

If most real-world websites contain common accessibility failures, then AI-generated code isn’t magically immune to those failures. AI will produce generic solutions with all kinds of accessibility defects, unless you tell it otherwise.

It’ll miss labels and skip keyboard behaviour. It’ll sprinkle ARIA because it looks right. And it’ll create something that seems fine visually but collapses under screen reader and keyboard testing.

At the same time, the pressure to move ever faster is real. Y Combinator has publicly claimed that in their 2025 winter cohort, 25% of founders had codebases where about 95% of the lines were AI-generated.

And this is concerning. Y Combinator is the global startup accelerator. We’re talking about the future tech leaders of Silicon Valley and the creators of tomorrow’s digital systems possibly contributing to hastily built digital products which increase the digital inclusion gap.

But whether you love it or hate it, AI-generated code is here, and it’s not going away.

Instead of actively pushing against it, the question should be how do we use AI generated code and vibe coding without ending up with vibe quality?

Quality design doesn’t happen by accident.

Even Microsoft’s guidance on reviewing AI-generated code leans on a familiar theme. AI often defaults to generic patterns unless you enforce standards, review deliberately, and iterate with intention.

So, the guidance is don’t let AI ship code unsupervised.

If you’re going to use vibe coding responsibly for accessibility, you need incredibly robust guardrails.

You need to set boundaries. Define your component patterns, semantic HTML expectations and the shortcuts you refuse to allow. Make accessibility requirements explicit in all of your prompts.

Require keyboard behaviour, focus management, labels, and error handling, language attributes, and contrast.

And crucially add the required accessibility expert review before anything lands. And test the output with keyboard testing, screen reader smoke tests, and automated checks as a baseline.

Because if most of the web is still getting the accessibility basics wrong, "trained on the web" doesn’t mean "accessible by default".

It means you must actively steer, cajole and shape it to make it build not just quicker, but better and correctly.

Why WebAIM's report only found 6 issues on a million pages

2026-02-16T00:00:00Z

Video transcript

The web isn't failing accessibility because it's hard; it's failing because it keeps repeating the same basic defects at a massive scale.

This is the story of WebAIM's 2025 report.

For the 7th year in a row, WebAIM evaluated the homepages of the top 1 million websites, and the findings are surprising.

94% of homepages had detectable WCAG 2 failures.

Over a million homepages on the web are failing basic accessibility checks in the same few ways, over and over again.

And WebAIM found that 96% of those detected errors fell into just six categories.

Six.

But it's not because accessibility is too hard.

It's because we keep mass-producing the six same defects year on year, in the 2025 report.

Low contrast text featured in 79% of pages, where text blends into the background.

It looks sleek, nice, minimal, and on brand, and yet it's unreadable for a huge number of people.

Missing alt text featured in 55% of pages.

If an image is communicating something, it needs a meaningful text description.

Without it, screen reader users can't understand the content.

Missing form labels featured in 48% of pages, which breaks basic usability.

Every input needs a programmatic label.

Without one, screen reader users can't tell what they're filling in.

Empty links featured in 45% of pages.

A link exists but has no accessible name.

In a screen reader, the blank link is announced as "link."

Empty buttons featured in 29% of pages.

Icon-only buttons or SVG-only controls, with styling so aggressive the label effectively disappears.

And lastly, missing document language featured in 15% of pages.

This is where the language at the top of the HTML is missing, which sounds minor, until you realise it can change how a screen reader pronounces the entire page.

Now, if you fixed only these basic accessibility defects, you'd eliminate the vast majority of the errors WebAIM detected.

So the real question is: why are these still everywhere?

Let's take a look at colour contrast. It occurs a lot, averaging 29 instances per page.

That's not someone forgot.

That's a design token or style guide problem.

Because if your secondary text colour fails, it fails everywhere.

If your hover state fails, it fails everywhere.

This isn't random.

These six defects are repeatable outcomes from flawed procedures.

They come from templates, standard components, shared components, design systems, CMS themes, and workflows.

Here's the thing: modern teams don't ship pages; they ship patterns.

These six errors are cheap to catch.

Automation is actually pretty good at finding them, and yet they persist at a massive scale.

So that implies one of a few things is happening.

Either checks aren't running in continuous integration tools, or they run but they're not enforced and are warnings only.

Or teams can't fix upstream issues, things like themes, vendor content, embedded scripts, and ads.

Or regressions keep coming back; they're fixed today and reintroduced in the next design, in the next few sprints.

And WebAIM's report is only what automation can detect reliably.

The true conformance rate is almost certainly worse.

The root cause isn't just people forget.

It's incentives.

Teams are rewarded for shipping features, conversions, brand polish, performance.

They're not rewarded for every form control being consistently labelled.

The high-friction work gets deferred.

Accessible names, robust labelling patterns, testing with assistive tech all get deferred until it becomes a legal risk, or a contractual risk, or a headline risk.

And by then it's systemic.

It's baked into the design system, baked into the component library, baked into the CMS workflow.

Accessibility breaks hardest at the handover points: designer to developer, developer to tester.

In fact, each of the top six errors maps neatly to a handoff point.

For contrast, a designer chooses tokens and a developer implements, but nobody hard gates it.

For alt text, authors upload images, except the CMS doesn't enforce the text descriptions and team training is missing.

A preference for a clean UI drops visible labels, placeholders pretend to be labels, and ARIA labelling is inconsistent.

Injected content from upstream creates empty links and buttons.

Template defaults aren't set for language; nobody owns it, so it slips through.

It's not one person being careless.

It's the pipeline not guaranteeing the outcome.

This is a pipeline problem. The fix isn't try harder.

The fix is to treat accessibility as a production constraint, like security, like build-breaking tests, like payments.

If this fails, we don't ship.

Until accessibility becomes a non-negotiable gate in design tokens, component libraries, CMS authoring tools, and continuous integration, the same six defects will keep reappearing in reports time and again.

Because the web is built by repetition, and repetition amplifies whatever your system allows.

The question isn't, how do we get people to care more?

The question is: build better gates so these failures can't reproduce.

Because when you fix the basics upstream, you don't just improve one page; you improve the entire system.

Improving the system and making accessibility work better is what we are good at.

If you want to improve your digital accessibility and stay on top of the fast-changing accessibility landscape, click the like button and make sure you've subscribed to CANAXESS.

Until next time, bye for now.

Why AI personalisation breaks accessibility

2026-02-23T00:00:00Z

Video transcript

There’s a peculiar pattern that happens when someone becomes a big name in a field. They reach thought leader status, and suddenly everything is broken—and they have the bold new fix.

Cast your mind back to 2024. Usability pioneer Jakob Nielsen published a deliberately provocative post claiming accessibility has failed, and that generative UI is the way forward.

If you’ve been anywhere near accessibility, you’ll know why that landed badly. But with more than a year of distance, the question isn’t whether the post was provocative.

It’s whether he was right about the underlying problem, even if the framing—and the solution—were off.

Nielsen’s core claim is deliberately provocative: after thirty years of accessibility work, disabled users still don’t have a usable experience.

Not merely a technically accessible one, but “usable” in the classic sense—easy to learn and productive.

He says that accessibility has failed as a method of making computers usable for disabled users by the same standards applied to any user.

His argument becomes even sharper when he focuses on blind users. He describes the screen reader experience as a forced linearisation of a two-dimensional interface: sighted users can scan the page visually, pick out elements of interest, and move directly to them; blind users, by contrast, must listen to a stream of audio in sequence.

It’s this indirection he says that guarantees an experience that will always be worse than visual interaction.

The problem is that it treats accessibility itself as the failure, rather than the way organisations consistently fail to implement accessibility well. Accessibility is not the thing that failed.

What fails, repeatedly, is adoption: building without accessibility in mind, bolting it on late, and treating it as a compliance scramble rather than a design and engineering discipline grounded in real usage.

This is precisely why the accessibility community keeps emphasising “shift left”—doing accessibility earlier in design and development, where structure, semantics and interaction patterns are still malleable. When teams build first and panic later, accessibility becomes an emergency patch.

Nielsen suggests that doing accessibility properly would require testing with every type of disability, which he says is effectively impossible. Again, critiquing screen readers as an inherently inferior mode of interaction. Coming from a UX pioneer, these claims are jarring—not because they acknowledge genuine usability problems, but because they imply those problems are inevitable and intrinsic to accessibility.

But beneath the inflammatory post there is a thread worth discussing: could interfaces be generated to better match individual requirements? That potential is what makes the conversation interesting.

Nielsen’s proposed solution is generative UI: instead of one interface for everyone, the system would generate interfaces tailored to each user and potentially regenerate them dynamically over time. For blind users in particular, he imagines an audio-first interface designed for the person, rather than a screen reader translating a visual UI.

The appeal is obvious. But the moment you say “tailored to your needs,” you run into a question that can’t be avoided: how does the system know what you need? It isn’t as simple as “detect assistive tech and adapt.” Assistive technologies are not consistently detectable.

Many disabled people do not use assistive technology, some use it only sometimes, and many use combinations. Needs also change with context: fatigue, stress, environment, device constraints, temporary injury, or the specific task at hand.

So a generative system faces a choice. It can ask users to disclose personal information about disability and access needs—something many people won’t want to share, and something they should not be forced to reveal.

Or it can guess from behavioural signals: keyboard usage, mouse movement, scrolling patterns, pauses, and other interaction traces.

That is where it gets dicey. Guessing introduces privacy risks, and it creates a practical failure mode that is easy to overlook: if the system guesses wrong, it doesn’t just miss; it actively makes the experience worse.

Consider a simple example. The system decides that heavy keyboard use indicates a preference—or need—for an audio-first interface.

But the user isn’t blind; they’re a power user, or they’re using a laptop with the trackpad disabled, or they have a temporary injury.

The system has now taken away an interface the person chose and replaced it with one they didn’t ask for. The core risk is that personalisation becomes something that happens to the user rather than something the user controls.

There is another risk in the promise of generative UI. Much of the hype assumes AI will generate better experiences for disabled users simply because an algorithm decided it was “more appropriate.”

But AI models learn patterns from the web as it exists today—and the web is messy. It’s full of repeated accessibility failures at massive scale: missing labels, broken focus order, inaccessible custom components, and interfaces built without semantic structure. If generative UI draws from the same ecosystem of patterns, it risks automating those failures faster and distributing them more widely.

This is why user choice is the missing ingredient in most discussions about AI and accessibility. AI can help accessibility, and it will get better at helping.

But letting AI decide what experience someone receives based on weak signals is the wrong direction. Some users will want customised interfaces; others won’t.

Many will want them in some contexts and not others. A one-size-fits-all personalisation engine simply replaces one accessibility problem with another.

A safer approach treats AI as optional enhancement rather than replacement. Changes should be reversible.

Users should be able to control preferences. Systems should be transparent about what changed and why.

And guardrails should ensure the basics never regress: semantic structure, keyboard support, predictable interaction patterns, and testing with real users.

The biggest risk is not that people explore AI. It’s the narrative “AI will solve accessibility” becomes a permission slip for leadership: accessibility is too hard, so we’ll wait for automation to fix it.

That thinking degrades real accessibility work, stalls momentum, and shifts the cost of experimentation onto disabled users yet again.

Accessibility is not a failed project. Accessibility is what happens when products are built with structure, predictability, testing, and real users in mind.

The uncomfortable truth is simpler we already know what to do. We just keep not doing it.

Understanding Australia’s Digital Inclusion Standard

2026-03-23T00:00:00Z

Video transcript

The Digital Inclusion Standard is one of the key requirements agencies need to follow when building and delivering digital services for the Australian Government.

It builds on the Digital Service Standard’s “Leave No One Behind” principle but takes inclusion and accessibility further. Instead of treating it as something owned only by an individual team, it creates a broader whole-of-government expectation for inclusive service design.

The aim is more consistent, more inclusive digital services across government.

So, what does the Digital Inclusion Standard actually cover?

It’s mandatory for new or replacement public-facing services, new staff-facing services, and all existing public-facing services. It applies to both informational and transactional services. So that means websites, publications, e-learning, portals, claims processes, business services, and really anything where people need to receive or provide information to the government.

The timeframes are important. It took effect from 1st January 2025 for new and replacement public-facing and staff-facing services, and from 1st January 2026 for all existing public-facing services.

To meet the standard, agencies need to meet five criteria across the full service lifecycle. And importantly, this is not just about the digital interface. It also means thinking about the wider non-digital experience, because inclusion is more than digital.

Criterion 1 Embrace diversity

This starts early, in Discovery. Teams need to understand diverse user needs from the beginning, not as an afterthought. That means looking at different identities, characteristics, and lived experiences so services are usable by the widest possible range of people.

In practice, this means doing strong user research with diverse groups, including people with disability, blind and low vision users, Deaf users, neurodivergent users, culturally and linguistically diverse communities, and people with lower digital confidence.

It also means using inclusive prototyping and co-designing both services and their supporting materials with users throughout design and delivery.

Criterion 2 Motivate digital use

This criterion is about reducing the barriers that stop people from confidently using digital services in the first place.

Teams should think carefully about whether the experience meets diverse user needs, and whether preventable barriers are pushing people into alternative service channels unnecessarily.

Good support content matters here. Step-by-step guidance, layered help content, and documentation that works for both beginners and more experienced users can make a big difference.

It’s also important to reduce unnecessary repetition, especially when users are being asked to enter the same information multiple times. That’s frustrating for everyone, but it can be especially difficult for people with cognitive disability.

Criterion 3 Protect users

This and accessibility are closely connected.

If users need to report a safety concern, those pathways must be clear, accessible, and easy to reach. They can’t be hidden behind confusing navigation, inaccessible forms, or difficult processes.

If those reporting channels are hard to find or hard to use, a person with a disability may be delayed or prevented from raising an urgent issue. At that point, an accessibility barrier can become a genuine safety risk.

Criterion 4 Make it accessible

This is the criterion most closely tied to accessibility in the traditional sense.

Digital services need to be accessible in order to comply with the Disability Discrimination Act 1992, the latest version of WCAG, and the Australian Government Style Manual.

One challenge, though, is the updated Digital Service Standard no longer specifies a WCAG conformance level. Our recommendation is that agencies should still aim for WCAG Level AA, because it remains the globally accepted standard and provides a much more reliable target and better support for users.

Criterion 4 also needs to be applied across the full digital lifecycle. Including content, technology, procurement, team capability, and documentation.

Services should work with assistive technologies, provide alternate formats and multiple ways to access information, be regularly tested and improved, include accessibility requirements in procurement and contract renewals, and keep support materials and documentation current and accessible.

Criterion 5 Provide flexibility and choice

This criterion is about giving people more control over how they use digital services, while also making the overall journey smoother across channels.

This comes through in Alpha and Beta as features are designed and integrated. It includes responsive design across devices and screen sizes, adaptable interfaces, options for written, audio, and visual content, and features like save, resume, and auto-save so people can complete tasks over time without having to hurry.

It also means designing processes that are manageable. Introduce information gradually, allow enough time, break complex tasks into smaller steps, and provide clear instructions throughout.

And beyond the interface itself, users should be able to move between digital and non-digital channels without friction, with a consistent and supportive experience across websites, mobile apps, and in-person services.

Overall, the Digital Inclusion Standard is a positive step because it moves government services beyond narrow compliance thinking and toward a more inclusive whole-of-service approach.

But the real test is not what the standard promises on paper. It is whether agencies can turn broad principles into clear requirements, stronger procurement decisions, better testing, and release processes that genuinely protect accessibility.

Why the ACT Government accessibility policy starts behind

2026-03-30T00:00:00Z

Video transcript

An accessibility policy is not just about intent. It’s also where the minimum bar is set. And when that bar is still WCAG 2.1 AA, originally released in 2018, that decision affects how seriously accessibility gets embedded into digital delivery.

The ACT Government Web Accessibility Policy applies to Government content delivered through a web browser.

That includes websites, intranets, extranets, social media, web forms, web applications, and PDFs.

Crucially, it also extends to government information delivered through third parties, partnerships, and funded programs.

At the centre of the policy is the requirement that in-scope web content must comply with the Disability Discrimination Act 1992 by following WCAG 2, specifically 2.1 at Level double A for new or redeveloped sites.

The problem is that WCAG 2.1 is now an older version. It was first released in 2018, and when organisations adopt an earlier version, the minimum bar usually falls below current accessibility practice.

This ultimately weakens procurement rules and design and delivery expectations. It also leaves out newer criteria introduced in WCAG 2.2, including stronger focus visibility, larger touch targets, and alternatives to drag-only interactions. In practice, introducing more usability barriers and slower accessibility uplift across government.

Now, to be fair, the policy does try to encourage agencies to aim higher, particularly toward WCAG 2.2 at level double A or even level triple A.

But that also reflects the broader position being taken by the DTA. So, the benchmark here feels shaped more by federal government inertia than adopting the best available accessibility standard of the day.

The policy says disability-focused or critical information should ideally conform to WCAG 2.2 level triple A. Which on the surface sounds strong and user-focused. But in practice, triple A is not usually used as a full site-wide target because triple A success criteria are often difficult to apply broadly.

So, this creates a mixed message.

A clearer approach would be something like “all new or redeveloped content must meet WCAG 2.2 double A. For high-impact content, agencies should also consider relevant triple A criteria where feasible.”

So that keeps the baseline clear while still encouraging stronger accessibility support where it makes sense.

The policy also says legacy sites and content must either be brought up to WCAG 2.1 double A or decommissioned. But it doesn’t explain how that’s meant to happen.

There’s no delivery mechanism, no timeframe and no migration strategy. Without that practical pathway, agencies can end up tolerating large volumes of inaccessible material and relying on risk acceptance instead of real remediation.

Non-conforming content is meant to be recorded on the agency’s risk register, along with mitigation strategies and action plans. That’s promising in one sense, because it builds accessibility into risk management rather than treating it as just a publishing issue.

But it can also become an administrative safety valve. Accessibility debt gets recorded and managed rather than fixed. From our point of view, risk registers are useful, but they shouldn’t become a substitute for remediation efforts and release controls.

The policy says agencies should prioritise making all new content, sites, and functionality accessible, with particular attention to high-priority areas like customer services, education, revenue collection, emergency information, health information, and content aimed at disability-related audiences.

Agencies are expected to make prioritisation decisions based on use, audience, legal publishing obligations, sensitivity of function, and risk, cost, and benefit.

In terms of ownership, responsibility for accessibility is shared across government.

Digital Canberra maintains the policy and provides advice and support.

Directors-General and agency heads are accountable for compliance.

System owners are expected to coordinate implementation, maintain registers and mitigation plans, arrange testing, ensure skills and training, procure accessible goods and services, and handle complaints or requests for accessible alternatives.

Staff involved in web systems are also expected to understand the requirements, undertake training, follow the policy, and support conformance checking and reporting.

So overall, the ACT Government has kept WCAG 2.1 double A, a version released in 2018, as the minimum enforceable release standard, while signalling that WCAG 2.2 is the direction of travel and current best practice.

It frames accessibility as a whole-of-agency responsibility tied to legal risk, publishing, procurement, testing, and governance, rather than something left to developers at the end.

So the policy points in the right direction. But if the minimum bar is still WCAG 2.1 double A, then the real question is whether this will genuinely lift the delivery of ACT Government digital services, or simply make an older standard easier to defend. Because in the end, what matters is not the wording of the policy. It is whether it changes what gets built, and what is allowed to go live.

The WebAIM report says accessibility is getting worse

2026-04-27T00:00:00Z

Video transcript

Our video on WebAIM's 2025 report showed the web kept repeating the same six accessibility failures.

WebAIM's 2026 is, and there's no good way to describe it, it's worse. The same six failures are still there, but the numbers are larger.

In this year's report WebAIM detected an average of 56.1 errors per page, and 95.9% of home pages had detectable WCAG 2 failures. That reverses the small improvement we'd seen in the previous few years.

If you're thinking this all sounds incredibly familiar, you'd be right. 96% of all detected errors came from just six issues. We're talking low contrast text, missing image alt text, missing form labels, empty links, empty buttons and missing document language. The same six defects as last year, and to make the matters worse, the numbers of errors have increased.

Only missing ALT text and missing language improved slightly, everything else didn't. Low colour contrast went from 79.1% to 83.9%, missing form labels went from 48.2 to 51%, empty links from 45.4% to 46.3% and empty buttons from 29.6% to 30.6%.

Web pages are getting more complex. This year's results showed ARIA usage rising sharply with 82.7% of pages using ARIA and pages with ARIA showing more detected errors.

This rising complexity, heavier ARIA use and maybe AI-assisted generation appear to not just be nudging but actively dragging digital accessibility backwards.

And could the worst trend in software development, vibe coding, be affecting things? WebAIM seem to think it's having an effect, and I agree.

Generative AI has made it easier for anyone to create digital content.

But that also means good accessibility support has decreased. Accessibility requirements need to be communicated clearly and tested effectively. If someone creating a website doesn't know accessibility then why expect AI to generate anything even close to being usable for people with disabilities?

The fact is accessibility is getting worse in 2026 and improving it at scale requires better practices and simpler systems.

But the challenge is not shortcuts or a “fix it later” mindset, but ongoing governance, testing, accountability, and attention to fundamentals. The boring stuff. Because making accessible digital experience isn't easy and needs skills, far beyond the current capabilities of generative AI.

The web is still failing accessibility at scale, because the same few basic errors keep being repeated across increasingly complex homepages.

We’re still losing on the basics, every day.

But it isn’t all doom and gloom, at CANAXESS we put time and effort into making accessibility a sustainable and tangible outcome for businesses.

If you're interested in learning more, drop us a message in the link below, and of course if you want to stay up to date with the latest accessibility trends and understand WCAG better make sure you've clicked like on this video and subscribed to the channel for more videos.

I've dropped several more links in the description below talking about the latest WebAIM report, it's interesting reading if not a little sobering reading. But until next time, thanks for watching and bye for now.