Learn. Show. Repeat.

Blog

  • My approach to accessibility

    Accessibility is multifaceted – it’s about people and their needs; it’s about removing barriers; and it’s also about the role we all play in making the world a more accessible place.

    Recently, I watched a recording of Greg Alchin’s presentation Ubiquitous Accessibility, at A11y Camp 2024. Greg works for Service New South Wales (NSW), which is a State Government agency that serves as a one-stop shop for locating various government services. Early in his talk, he said a phrase that he wanted all the audience to learn – “Every customer can”

    That small phrase really resonated with me because as Greg said, it boils all the guidelines and legislation down into a simple statement that you can unpack (in Greg’s case) to make more accessible services.

    After watching, I had an idea for a statement that expresses the way I think about accessibility. A statement that is both a mindset and a call to action.

    Everyone can.

    As a mindset, it is about putting people first. From the beginning, how can I ensure that everyone can [insert action]?

    The guidelines, legislation, and checklists are tools I use to help improve accessibility. Conforming to criteria is not the end goal. Products, services and spaces that everyone can use is.

    Adopting this mindset means always considering the diverse needs and experiences of others. It’s about proactively seeking feedback from a wide range of people and adjusting as necessary. Accessibility is not a one-time task but an ongoing commitment to inclusion and continuous improvement.

    Everyone can.

    As a call to action, it is about the role that I and everyone can play when it comes to accessibility. You might not be a website developer or a software engineer or a product designer, but everyone can do something to remove accessibility barriers.

    Simple actions such as checking contrast, adding alternative text and captioning videos are things everyone can do. Start small and then build on that. If you come across something that is not accessible in the digital or physical world, fix it if you can or report it if you can’t. If we do nothing, then nothing will change.

    Everyone can learn more about disability (both visible and invisible) and accessibility. This helps to embed the mindset. By seeking out resources, attending workshops, or simply listening to people with lived experience, we can deepen our understanding and empathy. This ongoing learning not only broadens our perspective but also empowers us to make informed choices that enhance inclusion in everyday life.

    What is one action you could take today to make the world a more accessible place?

    A drop of water falling into a lake, creating a ripple effect. Image source: Unsplash

  • Shift-left accessibility

    The concept of “shift-left” in the context of accessibility refers to the practice of integrating accessibility considerations early and regularly in the product development lifecycle, rather than addressing them at the end of the process.

    This approach aims to identify and resolve accessibility issues as early as possible, which can lead to more inclusive and user-friendly products, as well as cost savings and improved efficiency.

    Examples of shift-left accessibility

    Planning phase

    • Define accessibility goals and requirements.
    • Include accessibility criteria in documentation.
    • Allow time in the development phase for accessibility requirements.

    Design phase

    • Consider how keyboard navigation will flow through your designs and how users will interact with the interactive elements.
    • Use accessible design principles and patterns.
    • Conduct usability testing with a diverse range of users.

    Coding/development phase

    • Implement semantic HTML and WAI-ARIA attributes.
    • Perform code reviews with a focus on accessibility.

    Testing phase

    • Use inspection tools to check for common accessibility issues.
    • Conduct manual testing with assistive technologies.
    • Test functionality with the keyboard.

    Release phase

    • Ensure all user-facing content is accessible.
    • Monitor and gather feedback from users to inform updates.

    By adopting a shift-left approach to accessibility, we can create more inclusive and user-friendly products and improve accessibility throughout the development lifecycle.

  • More than looks: Using proper headings

    Headings on webpages and in documents help to organise the content that follows. Using proper heading tags is necessary for both accessibility and the overall structure of your content.

    Why use proper headings?

    Here are some important reasons why proper headings are better than text that is styled to look like a heading:

    Provides a clear hierarchy for content

    Using heading levels establish a clear hierarchy of information, making it easier for all users to understand the structure of your content. For example:

    <h1> is typically used for the main title of the page.

    <h2> is for major sections.

    <h3> is for subsections, and so on.

    This hierarchy helps users skim and locate the information they need quickly.

    Improves accessibility for screen readers

    Screen readers rely on semantic HTML to navigate through content. Proper headings (<h1> to <h6>) create a logical structure that screen readers can interpret, allowing users to quickly jump between sections.

    If you only format text to look like a heading (e.g., making text bold or larger), screen readers won’t recognise it as a heading, which can make navigation difficult.

    Best practices for headings

    • Use a logical hierarchy: start with <h1> for the main title, followed by <h2> for major sections, <h3> for subsections and so on.
    • Avoid skipping heading levels: for example, jumping from <h1> to <h3>
    • Avoid using headings for their styling: don’t use heading tags just to style text, (for example, a <h3>for bold text that isn’t a subsection). Use CSS for styling instead.
    • Ensure headings are descriptive: headings should be descriptive and meaningful so users can quickly understand the content of each section. For example, instead of a vague heading like “Section 1,” use something specific like “Benefits of Accessible Design.”
    • Test with assistive technologies: use tools like screen readers to verify that headings are navigable and make sense in the context of the page.

    Headings in documents

    Applying proper headings in other types of digital content has the same benefits as described above.

    Word documents

    Word offers built-in heading styles that are easy to apply and create structured documents. Visit the Add a heading in a Word document page to learn more.

    How to apply headings in Word:

    1. Highlight the text you want to make a heading.
    2. Go to the ‘Home’ tab on the ribbon.
    3. In the ‘Styles’ section, choose a heading level (e.g., Heading 1, Heading 2, etc.).
    4. You can customise the appearance of the headings (if needed) by right-clicking the style and selecting ‘Modify’.

    Emails in Outlook

    Outlook also has heading styles available.

    How to apply headings in Outlook:

    1. Compose a new email or reply to an existing one.
    2. Highlight the text you want to format as a heading.
    3. Go to the ‘Format Text’ tab in the ribbon.
    4. Use the dropdown menu in the ‘Styles’ group to apply heading levels.

    PowerPoint presentations

    In PowerPoint, headings are typically used as slide titles and subtitles to organise content.

    How to apply headings in PowerPoint:

    1. Use the Title Slide layout for the main title of your presentation.
    2. For additional slides, use the Title and Content layouts or other templates with designated title areas.
    3. Avoid manually creating titles by adding text boxes – use the built-in title fields to maintain structure.

  • ‘Click here’ is not enough

    Within digital content, hyperlinks (links) are often used to guide users to additional information or resources. Links have two parts:

    • the text used for the link, and
    • the webpage or resource it leads to.

    The way the link text is written and displayed can cause barriers for some people. Examples such as ‘Click here’ or ‘Read more’ are not helpful especially when there are a lot of them on a page. To improve accessibility, it is important that link text is descriptive. Accessible link text benefits all users when well they are clear and well-written.

    Descriptive link text for accessibility

    Using descriptive hyperlink text is essential for making your content accessible, user-friendly, and inclusive. Here’s why:

    • Improves the experience for screen reader users: Screen readers often allow users to scan a list of links on a page. If links are labelled as ‘click here’ or ‘read more, they provide no context about their destination.
    • Enhances the usability for everyone: They save time by allowing users to quickly recognise where a link will take them without guessing or opening unnecessarily.
    • Aligns with accessibility guidelines: there several Web Content Accessibility Guidelines (WCAG) that apply to links. These have been added in the next section about tips.

    Tips for writing descriptive link text

    Here are some tips for writing link text with related guidelines:

    • Be specific: Clearly describe the content or purpose of the link. For example, instead of “Click here,” use “Download the 2025 Accessibility Report.”
    • Related guideline: The purpose of each link should be clear from the link text alone.

    • Make links stand out visually: Use a distinct color and underline to differentiate links from regular text. This helps users with visual impairments or color blindness identify links more easily. I like to bold the link text.
    • Related guidelines: Text (including link text) must have a sufficient contrast ratio against its background; Color should not be the sole means of conveying information; and Components with the same functionality should be identified consistently.

    • Ensure keyboard accessibility: Make sure that links can be navigated and activated using only a keyboard. Test your site to confirm that users can tab through links in a logical order. The enter key should open the link.
    • Related guidelines: All functionality must be operable via a keyboard; and Any interactive component, including links, must have a visible focus indicator when navigated to via keyboard.

    • Use proper HTML markup: Ensure that links are coded properly so assistive technologies (like screen readers) can recognise them as links and convey their purpose to users.
    • Related guideline: All user interface components, including links, have programmatically determinable names, roles, and states.

    • Integrate links naturally: Embed links within the flow of your sentence, so they feel natural and intuitive. For instance, This Links and Hypertext article from WebAIM provides more information.
    • Avoid using URLs as link text: Instead of displaying a raw URL (for example, https://webaim.org/techniques/hypertext/link_text. Raw URLs can be cumbersome for screen readers to interpret as each character is read out.
    • Keep it concise: While being descriptive, avoid overly long link text. Aim for a balance between clarity and brevity.

    Descriptive hyperlink text is a small but powerful way to make your website or content more inclusive. By taking a thoughtful approach to how you create links, you are creating a better, more intuitive experience for everyone.

  • Colour contrast matters

    Contrast is the difference in the perceived brightness between two colours. In the context of digital content, this is the difference between the text colour (also the colour of buttons, links, form fields) and the background colour.

    A contrast ratio is how the difference in brightness is measured. The ratios range from 1:1 (both colours are the same) to 21:1 (black text on a white background or vice versa). A higher ratio means there is more difference between the colours. If the ratio is too low, the colours are too similar and may blend together for some people.

    Here are some examples:

    Examples of different colour contrast ratios - yellow on white is 1.64 to 1, red on white is 3.99 to 1, light blue on white is 4.65 to 1, purple on white is 8.03 to 1 and dark blue on white is 15.26 to 1.

    People who benefit from higher contrast include:

    • those with low vision, colour blindness, or age-related vision decline
    • those in bright sunlight, low-light conditions, or using lower-quality screens

    Guidelines for contrast

    The Web Content Accessibility Guidelines (WCAG) specify the following when it comes to contrast:

    • Normal text (smaller than 18pt regular or 14pt bold) must have a contrast ratio of at least 4.5:1 against its background.
    • Large Text (18pt regular or 14pt bold or larger) must have a contrast ratio of at least 3:1.
    • Non-text elements (buttons, input fields) must have a contrast ratio of 3:1 against adjacent colours.
    • Logos or brand-name text has no contrast requirement.

    I may be oversimplifying it, but if the contrast ratios were on a spectrum, the above guidelines are on the low end:

    Contrast scale showing the lowest contrast 1 to 1 up to 21 to 1. The WCAG requirement of 4.5 to 1 is down the lower end.

    Surely then, at least meeting the above requirements should be easy as it is down the low end of the scale. However, since 2019, the number 1 issue on websites in the WebAIM million has been low contrast text.

    How to check contrast

    There are several tools for checking contrast:

    • I use the WebAIM Contrast Checker.
    • If you are using Microsoft products, contrast issues can be picked up by the built-in Accessibility checker in Outlook, PowerPoint, Word, and Excel.
    • Figma, Adobe XD, and Sketch have built-in or plugin-based contrast checkers.
    • Browser Extensions – WAVE (Web Accessibility Evaluation Tool), axe DevTools – A Chrome/Firefox extension that audits accessibility, including contrast.

    You can also try the built-in “Emulate vision deficiencies” feature within Chrome DevTools:

    1. Right-click on any webpage and select “Inspect”.
    2. Select the three-dot menu (More tools) and then select “Rendering”.
    3. Locate the “Emulate vision deficiencies” option and use the dropdown menu to select the desired colour vision deficiency.
    4. The webpage will now be displayed as it would appear to someone with the selected colour vision deficiency.