Skip to content Skip to footer

Alt Tags- Flashcard

October 5th, 2023

No one likes Empty Labels. Use Alt Tags written next to image of a jam jar.

Keyboard Navigation- Flashcard

September 12th, 2023

Respect the tab key check your tab order.

Accessible Links- Flashcard

September 12th, 2023

Links, visited, hover, focus and active.

Legible Font- Flashcard

September 12th, 2023

Choose a legible font to be clear to your users.

Color Contrast Flashcard

September 12th, 2023

Make your text stand out remember color contrast.

Semantic Code Flashcard

September 8th, 2023

Don't confuse screen readers use semantic code.

Tools and software

July 31st, 2023

Validators and Accessibility Checkers

Firefox’s Developer/ Accessibility Tools

Built right into the the firefox browser they allow you to check issues with tab order, colour contrast, and a number of other accessibility issues. They also have a great feature which allows you to simulate how your website looks for people with different visual impairments. (Read more about Firefox’s accessibility tools here)

W3C’s Code Validator

Checks your code meets the good standards and practice of the W3C. It will check for accessibility issues such as lack of alt tags etc, and will pick up any errors in your code or where you should be using a HTML semantic element and the appropriate one to use. ( Access W3C’s code validator here)

Web Aims Wave

Checks your code for accessibility issues. One of the most widely used accessibility checkers, it labels across the page, in a visual way with extensive use of icons (useful if your a visual learner) Access Web Aims Wave tool here.

Lighthouse

Googles accessibility checker works within the Chrome browser. It runs on the same technology as Axe Dev Tools. (Find out more about Lighthouse here)

Axe Dev Tools

Built by Deque, this works across Firefox, Chrome and Edge. Its free option is more than enough for a beginner. Its ability to work in the browser is useful for running quick tests as you develop.

Its explanations for errors can be quite technical, this can be useful for editing specific offending parts of code. However, if you prefer a simpler approach you might find the Wave tool, a better starting point (I would recommend using both alongside each other). Access Axe Dev tools here.

Linter

This works alongside Github, commenting on any code that you send to Github from your code editor. This one is for when you start to feel comfortable using services like Github and it is very useful tool. (Access Linter here)

Screen Readers

These are very useful for testing aria labels and alt tags. (read more about using screen readers for testing in this article on aria)

The main ones to use are, NVDA for Windows. (NVDA is Available here), Voice Over for Apple (Read more about Voice Over here) and Orca for Linux. (You can download Orca here)

Colour Contrast Checkers

Web Aims Contrast Checker

A very useful tool. Easy to use allowing you to easily copy and post colour hexcodes and lighten and darker colours to improve accessibility. (Access Web Aims Contrast Checker here)

Contrast Ratio (by Lea Verou)

This is a useful tool for showing very clearly how legibility of text changes with different coloured backgrounds. I personally don’t tend to use this as much as I find it a little visually overwhelming. (however I know other developers who swear by it). (Access Contrast Ratio here)

Fire Fox Web Development Tools

Our old friend again. You can easily use this to hover over certain colours and see there colour contrast rating and change it. It is the tool I use most often for checking colour contrast. You can read more about this in this article on accessible colour schemes.

People

This is any easy one to forget amongst the range of tools that are available. Other people, friends family, people on the train (bet they wish they had booked the quiet carriage), anyone who shows an interest. This will be a very useful means of getting an idea of how accessible your website design is straight from the mouth of a potential user (they may spot issues that you didn’t)

The people you should follow

July 31st, 2023

The Wise Owls of Accessibility

Ashley Firth

Ashley Firth is head of front-end development and accessibility at Octopus Energy. He is also the author of the excellent Practical Web Inclusion and Accessibility: A Comprehensive Guide to Access Needs. (You can read a summary of Practical Web Inclusion here) This book was a great resource when writing the articles on this website and I would highly recommend it. You can visit Ashley’s Website here and follow Ashley on Twitter here.

Bruce Lawson

Bruce Lawson is a passionate advocate for making the web more accessible and is a member of the Web Standards Project accessibility task force. Follow him for his accessibility expertise, and his contributions to debates on accessible web development. You can visit Bruces website here and follow Bruce on Mastodon here.

Sara Soueidan

Sara is one of the leading experts in accessibility. She has also just started a new accessibility course. Sara’s website is available here and you can follow Sara on Mastodon here.

Heydon Pickering

Hayden offers great advice and practical examples of how to improve accessibility. His work has been a valuable resource when building this website. He is the author of Excellent Inclusive Design Patterns: coding accessibility into web design. ( Read a summary of Heydons book here). You can follow Heydon on mastodon here. You can also visit Heydon’s website for more of his work.

Joshue O Connor

Joshue O Connor has extensive experience on web accessibility including working with W3C, on accessibility guidelines and UK government digital servies team. He currently runs his own accessibility-focused user experience consultancy. His style of writing on accessibility with a sense of humour has been a strong influence on this website. He is the author of pro-HTML 5 accessibility: building an inclusive web. (You can read a summary of Joshue’s book here). (you can visit his Joshue’s agency website here).

Regine M Gilbert

Regine is a user experience designer and professor at New York University with expertise in accessibility. She is the author of the Inclusive Design for a Digital World designing with accessibility in mind. (Read a Summary Regines book here). She is a great explainer of the philosophies behind designing with accessibility in mind and is well worth following. You can visit Regines website here.

Rian Rietvald

Rian is an expert in accessibility who runs the accessibility courses for the A11y Project. I would highly recommend her accessible code course (which I have completed myself) it offers a thorough detailed explanation of accessible web development, as well as lots of practical examples. You can visit Rian’s personal website here and attend the A11y project accessible code course here.

Leonie Watson

Leonie Watson is an influential figure within the accessibility community. She has wide ranging expertise on accessibility, and it’s worth reading her thoughts on everything from alt tags and semantic code to aria. As a regular screen reader user, she also offers unique insight into how you can build websites to offer a better user experience to those using this tool. You can visit Leonie’s website here.

Books you should read

July 31st, 2023

Practical web inclusion and accessibility: A Practical Guide to Web Accessibility

Author: Ashley Firth

This excellent resource explores accessibility, through its effect on different disabilities, with each disability receiving their own chapter e.g. cognitive, sight, and motor issues. Whilst it segments content through type of disability, it also highlights the crossover between them, and maintains the ethos that considering, all users, should be starting point for building websites and not a checkbox exercise. It contains lots of practical examples, and uses language which is beginner friendly and relatable to both developers and designers.

Buy Ashley’s book here

Inclusive Design Patterns: Coding Accessibility into Web Design.

Author: Heydon Pickering

A useful book full of practical code samples, on creating skip content links, magifiying text on the hover, and making accessible buttons amongst many more. You may find some of the code samples a little complex as a beginner, but there are plenty which are achievable even if you are new to html and css. Written in light-hearted, yet informative style it explains the key philsophies behind accessible web design in a relatable way.

Buy Heydon’s book here

Inclusive Design for A digital world: Designing with Accessability in Mind

Author: Regine M Gilbert

This book gives detailed descriptions for how you should design and build accessible websites. It takes a more design led approach and so has less coding samples than some of the other books on this page. However, it is still full of practical and useful advice and includes several insightful case studies, such as how the BBC team made the Iplayer more accessible through research. It has very detailed and useful explanation of different types of colour blindness.

Buy Regine’s book here

Pro HTML 5 accessibility: Building an inclusive web

Author: Joshue O Connor

This book offers a detailed description of all of accessibility features within HTML 5. It is particularly useful for its descriptions of the accessibility benefits of semantic code, as well as aria labels. It also has a detailed process of how you can approach writing alt tags taking you through the thought processes involved step-by-step. Whilst  it was published back in 2012, its content is still highly relevant and a valuable resource to anyone learning accessibility. It also been written with a great sense of humour, is an engaging and enjoyable read throughout.

Buy Joshue O’Connors book here

The role of the focus and how to style it.

July 13th, 2023

Article Content
  • What the focus is and how it appears visually in the browser.
  • How to style the focus and best practices to ensure this styling is accessible.
  • How to give HTML elements different focus styling and why you might need to.
  • The value of spending time mastering the basics of focus styling.

When you use the tab key to cycle through elements on the page, you will find a small box that appears around each link outlining it. This box is the focus. It may also change the colour of the link text. All the links in your HTML document will have this box appear over them. It visually demonstrates to the user when they have successfully interacted with a link.

If you were to do nothing, most browsers would display a default styling for this. However, you will find that you want to customise the styling for this to match the overall design of your website. This is both in terms of the colour size of the outline box and the colour the link changes to when you are over it with the tab key.

What a pseudo class means

To do this, you need to use the pseudo-class ‘focus’. Think of this name in a semantic sense. It refers to the ‘focus’ of the keyboard on a particular link when you are navigating a website. It forms part of a specific list of pseudo-class used to style and control how interactions with links look to the user. Each of these pseudo-classes has rules on the order and how you style them (For a detailed explanation of this styling order read our article on how to make links accessible).

How to style them accessibly

The number one rule with the focus element is if you remove the outline on links (the box) with ‘display none’, always replace it. If you don’t then there will be no visual indication for keyboard users navigating the website as they have successfully tabbed to a link.

The other key factor to consider is legibility. This is both in terms of appropriate colour contrast, the colour of the outline and the colour of the link (Read more about this in are article on making links accessible here). You also need to be careful when doing any styling that affects the size and width of the outline box, as well as the thickness of the line. For example, don’t make them so thin that they can’t be seen, or the box so large that it interferes with the interaction with other links. As with all accessibility (and design in general), you need to make sure that you consider usability alongside the aesthetics that you want to achieve with your design. Your styling should allow users to predict behaviour and feel more comfortable and confident in using a website.

Useful Tip

The UK government website has a great example of accessible focus styling, which makes links clear and obvious to users when they tab over to them. Visit the UK GOV site here. However, Don’t feel you necessarily have to do focus styling as complex as this, when starting out, you could simply start by just increasing the thickness of the outline lines for the focus box to make it clearer. (Visit the Firefox MDN web docs on outline here and Read a Firefox article on Focus here).

Giving different elements their own specific styling

You will find that you may want different elements of the page, and different pages have their own focus link styling. For example, if different sections of your page were in different colours, you would need different colours for the focus styling. This is done by putting the name of the HTML element before the colon. So, if it were an article element you were styling, it would look like this:

article focus styling code sample.
Written article and a colon before the focus, two curly brackets at the start and the end, color followed by colon and blue and semi-colon.

whilst the nav would like this;

navigation focus styling sample code.
Written nav and a colon before the focus, two curly brackets at the start and the end, color followed by colon and blue and semi-colon.

Another example would be when you start to create forms and you want the focus to appear on specific inputs (read this useful CSS tricks article on focus and forms). You may also want to add specific extra enhancements to the focus element, such as the text being magnified when tabbed over.

Why at first you should keep things simple.

You can see how things can quickly become complicated. When starting out, my advice would be to keep things simple. Choose your colour carefully, double-check that the focus element is appearing properly and that you can clearly see the outline. Over time you can add more complexity but make sure that you get the basics right first.

When a button shouldn’t be a button.

June 30th, 2023

Article Content
  • Why purpose of a link dicatates its formatting (even if it looks like a button)
  • How buttons are associated with particular actions (messages, modals)
  • Why you should be careful of deviating too far from a links default styling.
  • Why styling links is all about considering user’s expectations.

Buttons are something of a thorny subject within the world of accessibility, particularly when it comes to the relationship between buttons and links.  Buttons look modern and are used extensively across the interface of mobile apps. Therefore, it makes a lot of sense to a web designer, who wants to make their design mobile-friendly to use buttons equally extensively and why not use them as containers for links? Buttons are interactive, and links are interactive it makes sense for them to be together, right? When it comes to buttons and links, looks can be deceptive. Really like with all semantic code it boils down to the meaning purpose, and function of the code.

The purpose of a button and a link

Put simply, even if a link is designed to look in a particular way (in this case look like a button) it is still primarily a link. (There is an argument that even just styling links to look like buttons is bad practice, read more on this issue of button styling in this article from Axe here) What a screen reader wants to know is what particular action any part of your code is going to perform. The function of a link is to link the user to another piece of content, such as a web address or an internal page on your website. Mixing links together with buttons can be confusing to screen readers.  Buttons are associated with certain actions. As Adrian Roselli has described (the best explanation I have found) “If when activated, the user is not moved from the page (or to an anchor within the page) but is instead presented with a new view (messages, boxes changes in layout etc)…” then a button should be used. These popup messages are sometimes called modal dialogues. (Read Roselli’s blog on button and links here)

If your head is starting to hurt, I sympathise. It is one of the areas of accessibility that can easily become quite confusing. In terms of the semantics, I would format it as a link even if you were styling it to look like a button. (There are methods on how to do that in this CSS Tricks article you can read here). Bear in mind that there are strong arguments against doing this, namely that it can lead to confusion over function. You are effectively styling something to look like something semantically it is not, which could be considered problematic for accessibility and general user experience. (I think there is some middle ground here based on the context of where the link is but I can see the argument, especially for links that are in the main body text.)

The value of considering user’s expectations

My general advice would be to always start from the point of the default styling of links and make small changes in each development of the design.  Users like to predict the behaviour of a website, one of the key reasons people become frustrated is that we have certain expectations of what a link should look like.  Everyone can immediately recognise a link if it is blue and underlined. (A styling from the early days of the web). Once you start to deviate too far from this, you lose that immediate recognition from the user over what to do next, and they may be unsure of what will happen when they click on the link.

This advice may seem odd if you are from a generation well used to mobile apps and tapping or clicking on anything that looks remotely interactive. However, not all users will have the same level of confidence when interacting with the website. In the context of accessibility, you also need to consider that many users will not be navigating a website visually, so how a website is coded is vitally important for ease of navigation. (Read more about semantic code in this article here).

Accessibility is all about empathising with users from all backgrounds, and the design decisions you make when styling and formatting links and buttons should be reflective of this.

Creating accessible forms

June 30th, 2023

Article Content
  • Why making forms accessible is important for users with (ADHD, Dyslexia, and memory conditions)
  • How to create a label for forms.
  • How to add a placeholder for forms.
  • How to add a further context to a form with aria describedby.

As you start to build more complex websites, you will find for multiple reasons, you need to start including forms. Forms need to be used for a variety of different purposes, ranging from search forms to enable people to search for your website, contact forms so people can get in touch with you, to payment and address forms in which users need to import personal information.

The importance of making forms accessible

When used, forms can play an important role in the functionality of the website. If for example, your website’s purpose is to sell a product, its usefulness is diminished if users cannot comfortably use the form required to import their address details and personal information needed to make a payment. The accessibility of forms is therefore crucial; if the user becomes frustrated when using the form, they may give up on the process entirely and visit another site. Most importantly, it is not fair to disadvantage certain users over others. You therefore need to make sure that your form works just as efficiently for users using a screen reader, or the users with cognitive disabilities such as ADHD or memory conditions such as dementia, who may find using forms challenging because of the attention and focus required.

Creating a Label for forms.

The first step in ensuring that a form is accessible is to make sure that it is labelled correctly. Labelling is a crucial component of accessibility design and development, as it provides a means of signposting without having to rely on visual cues. (You will have discovered this if you read our article on alt tags available here) . To create a visual label, you can use the tags as shown below,

code of form with Just a label
Form opening and closing tags, with label opening and closing tags inside.

However whilst this visual label is useful it unfortunately means that screen reader users are missing out. In order to make labels available to screen reader users, you need to use the ‘label for’ tag and tie it together with the ID of the form. Like in the example below,

Inside form tags, is two label tags. Inside of those label tags, is label for equals name. This is followed by input type equals text and id equals name.

How to add a placeholder

To provide the user with more information as to the type of data they need to import on a form you can use what’s called the placeholder tag. This will show the user visually and be available to screen reader users, guiding them to what is expected in terms of input on form. See the example below on how to code a placeholder tag,

Code for place holder and ID
Two form tags, label for equals name inside, and enter your name. This is followed by input type equals text, id equals name, name equals name and placeholders equals start typing your name here.

(Examples adapted from Ashley Firth read a summary of Ashleys book here, FireFox MDN Web Docs, with help also from the A11y Collective Course)

This is what a place holder looks like in action.

Search with Placeholder

Add even more context with a description.

You may want to add even more contextual information to a form, particularly if its a complex and there is a risk that the user could become frustrated without it. You can do this with a paragraph and an aria “describedby” label. Both the the paragraph and aria “describedby” need to be linked by the same ID, in order for the screen reader to be able to tell these two pieces of information are directly related to each other. The usual formatting for the rest of the form still applies. You can see example, below for how this would be coded. (example from the A11y Project course) Read this article on the basics of aria, for more on how aria “describedby” works.

Screenshot of Code for Form description.
Label Tags with the id new password-id. An aria descirby withinin the input tags has the same ID. The same ID is used again for paragraph tag, which has information about password characters inside.

The example above imagines a situation where a user may be filling out a password form, and may need to know the mininum number of characters the form requires, to avoid frustration when filling it out. This is exactly the sort of situation where you would need to use this method as this extra information would be hard to express with a label, and placeholder alone. In situations like this more context improves accessibility and the user experience for everyone.

Further developing your knowledge

The form techniques described in this article will help increase the usability and accessibility of your website. I would advise you to start with these techniques, to not immediately overwhelm yourself. However, if you want to go further, you may want to explore fieldsets and legends (You can read more about fieldsets here), as well as autocomplete (You can read more about auto-complete here) and if you are feeling really confident you can even look at aria-atomic. (Read about aria-atomic here) If you want to immerse yourself in form creation I would highly recommend both Ashley Firth’s book and attending the Ally Project accessible code course. (You can read about both Ashley’s book, and the accessible code course here)