Ordering Without Barriers: Engineering Our Websites For Accessibility

Digital accessibility is more important than ever, especially now that the European Accessibility Act (EAA) has come into effect as of June 28th. The EAA defines a list of accessibility standards for a wide range of public-facing products and services, aiming to remove the common barriers that prevent people with disabilities from fully engaging with digital platforms.

At Flipdish, we believe digital accessibility isn’t just about checking compliance boxes; it’s about building online ordering experiences that truly work for everyone. Whether someone is using a screen reader, navigating by keyboard, or facing cognitive challenges, our goal is to ensure that they can order with ease and confidence.

In this blog post, I’ll walk through what digital accessibility means, how we are auditing our online ordering products using tools like Cursor AI and the meaningful improvements we are making to build a more inclusive ordering journey.

What is digital accessibility?

Digital accessibility means making digital products and services usable by everyone, including people with disabilities. When people hear the word disability, they often first think of permanent conditions such as blindness or deafness. However, there are also temporary disabilities (e.g. broken arm, cataracts, ear infection) and situational disabilities (e.g. broken mouse, noisy surroundings, sunlight impacting screen visibility) that also affect how users interact with digital content.

In Ireland’s 2022 Census, 22% of the population reported having a long-lasting condition or disability, a number which grows when temporary and situational disabilities are also taken into account. With many people experiencing some form of disability, overlooking their needs when building an online ordering website can significantly reduce its reach. Everyone eats food, so online ordering solutions must be designed to meet the needs of all users, regardless of ability.

Making our online ordering products more accessible

Flipdish provides a suite of products to allow businesses to accept orders seamlessly. Among these are two solutions dedicated to online ordering experiences on the web:

• Web Order: An online ordering system that can be embedded on a restaurant’s website to allow users to browse menus and place orders.
• Flipdish Websites: White-label online ordering websites which can be customised to match a restaurant’s brand (e.g. change colours, content, images, etc).

As we work on improving accessibility in these products, we are actively referring to the Web Content Accessibility Guidelines (WCAG), which outline how web content can be made accessible for people with disabilities. These guidelines are based on the following principles:

• Perceivable: Users must be able to understand the information being presented, e.g. images should have suitable alt text.
• Operable: Users must be able to navigate the content and use the features, regardless of what technology they use. e.g. keyboard commands, voice control.
• Understandable: The web content and its functionality must be clear and logical.
• Robust: The content must reliably work across different browsers, devices, assistive technologies, etc.

After running initial accessibility audits of our Flipdish Websites and Web Order system, we found that while parts of our online ordering products are accessible, some parts of the code didn’t fully meet the WCAG standards. To understand these gaps more clearly and begin addressing them, we turned to a range of accessibility audit tools.

How to audit accessibility

There are many tools available to help identify accessibility pain points in web applications. Here are some that we’ve been using as part of our accessibility improvement process.

Screen readers

It’s highly recommended to test accessibility using a screen reader to experience first-hand how users relying on these tools navigate our websites. MacBooks come with their built-in screen reader called VoiceOver, which we’ve only used a couple of times as we still need to go through some tutorials on how to use it effectively. I’m looking forward to becoming more comfortable using a screen reader, as experiencing a website like actual screen reader users will help reveal any accessibility gaps we might miss.

Using these tools has helped us uncover the areas of the code that fall short of being fully accessible. Based on these findings, we have started making the appropriate changes to ensure that our online ordering products are easier to use for people of all abilities.

WAVE Chrome Extension

The WAVE Google Chrome extension allows for websites to be evaluated for accessibility compliance (WCAG 2.2) in the browser and overlays icons to show where there are any accessibility errors. This tool has been very effective at catching issues like colour contrast issues, redundant alt text, missing labels, etc. The page structure and element navigation order can also be viewed using this extension.

Chrome DevTools

Google Chrome’s DevTools come with an array of tools that can assist with accessibility testing. The Rendering tab within the DevTools can emulate various CSS media features, and it can even emulate vision discrepancies such as blurry vision and colour blindness. Chrome DevTools also provides accessibility scores as part of its Lighthouse audits. This score is a weighted average of all accessibility audits, based on AXE accessibility assessments. Along with providing a score, it will outline any issues it identified as part of the audit.

While this is a great way to identify common accessibility issues, it has its limitations. It can’t identify complex accessibility issues like keyboard navigation traps, non-meaningful alt text, and logical focus order (Lighthouse will list items that should be manually checked). Because of this, the lighthouse accessibility score can be misleading, as a high score doesn’t guarantee accessibility compliance. Therefore, it’s important to manually test accessibility updates along with utilising these audits.

Cursor AI

As part of our AI tooling exploration at Flipdish, we trialled Cursor AI to help accelerate the accessibility improvements. We used it to refactor components with prompts aligned with the WCAG guidelines, testing its ability to identify and implement meaningful accessibility changes.

Cursor AI proved very effective with simpler components, especially when given clear, targeted prompts. For example, when prompted to implement a ‘Skip to main content’ link for better keyboard navigation, it implemented the feature easily. In other scenarios, it was able to identify general accessibility updates even when the prompt lacked specific guidance. While improving the fullscreen image gallery, it suggested adding a live region to announce when the displayed changes, a suggestion that wasn’t explicitly requested in the prompt.

However, results became more mixed when prompts were too vague or when refactoring complex components. In those cases, Cursor AI would sometimes produce suboptimal code, such as redundant aria-labels or poorly structured HTML. When asked to justify the suggestions, it would sometimes reverse its own recommendations, indicating a lack of contextual understanding.

Cursor AI lets us define custom rules to guide the AI’s code generation according to our project-specific standards and best practices. We plan to explore the creation of accessibility-focused Cursor rules to see if it can help produce more consistent, inclusive code suggestions to make it even easier to build accessible features.

Despite occasional questionable code output, Cursor AI has been a big help in refactoring the code for accessibility. Once we get more experience in prompt writing, it will become an even greater asset, not just in this task but also in our work routines overall. As with any AI tool, its effectiveness greatly improves when we understand the topic we are applying it to. Having a solid understanding of accessibility standards is the key to getting the most out of this tool!

Accessibility improvements we are making

Semantic HTML

It’s best practice to use correct HTML tags to describe the purpose of the content they contain, e.g. using <section>, <header>, <footer> tags to define landmarks, using <a> tags for links, etc. Providing clear structure and meaning to web content not only improves the code's maintainability and SEO, but also enhances accessibility by helping assistive technologies better interpret the content. One key aspect of this is ensuring a logical heading hierarchy across the page. When we inspected the Web Order restaurant menu content structure using the WAVE plugin, we discovered that the prices in the menu items were defined as <h3> headings.

It didn’t make sense for the prices to be headings as they were simply part of the menu item information and not a standalone section. Using headings in this way could confuse screen reader users by misrepresenting the page structure. Replacing them with <span> elements results in a much cleaner structure.

When building web components, it's easy to get caught up in their presentation, using generic elements like <div> and styling them to get the desired result. However, if a semantic HTML element can deliver the desired behaviour, using it will ensure that users receive the appropriate context automatically. For example, on the whitelabel website homepage, the menu highlights section used to be wrapped in a parent <div> even though it represented a section of the main page. Making the simple swap from <div> to <section> provides a thematic grouping of the child elements and allows assistive technologies to identify it as a landmark region, assisting with page navigation. The menu highlights section also had been rendering its menu items as an array of <div> elements. The accessibility issue with this approach was that screen readers would read each item individually, without recognising them as part of a list. By updating this component to render the list using <ul> and <li> elements, screen readers can now convey more context, such as announcing the total number of items in the list.

<!-- HTML rendered output before -->
<div>
     <div>
         <!-- menu card contents -->
     </div>
     <div>
         <!-- separator content --->
      </div>
      <!-- other menu card items and separators -->
</div>

<!-- HTML rendered output after -->
<ul>
    <li>
        <!-- menu card contents -->
    </li>
     <!-- other menu card list items -->
</ul>

Alt text

It’s important to have informative alt text on images so that screen readers can explain their content and purpose to users with visual impairments. Our V2 Website Builder allows restaurant owners to add alt text for images they upload, a big accessibility upgrade from our V1 Website Builder, which didn’t provide this feature.

However, there are some situations where alt text for an image isn’t required. If an image is purely decorative and doesn’t provide any extra information, then it should be given empty alt text ( i.e. alt="") so that they are ignored by screen readers. An example of decorative images is the images on the menu item cards on Web Order. Previously, these images had alt text set to the menu item's name, which didn't provide any extra information to the user. This meant that screen readers would just repeat the menu item name, leading to noise and causing confusion for its users. Updating these images to use empty alt text signals to screen readers that they can be skipped, providing a more focused user experience.

Keyboard navigation

Some users either cannot use a mouse or prefer not to when using our websites. To address these needs, the online ordering flow needs to support full navigation and interaction using a keyboard. Keyboard navigation should flow in logical order (from top of page to bottom, from left to right) with all interactive elements focusable. It must also be visually clear when tabbing through the website which element currently has focus. Writing semantic HTML helps greatly with this, as many semantic elements automatically support keyboard interaction. When building custom components, it’s essential to test keyboard navigation to ensure a logical flow and prevent any keyboard traps (i.e. where users get stuck in part of the page and can’t navigate forward or back).

When testing keyboard navigation by tabbing through the Flipdish Websites, we discovered that some components don’t fully support keyboard navigation, either by not visually showing focus or by trapping the focus within elements. We are actively working to resolve these issues with some improvements already in place. For example, on the Flipdish Websites, the focus used to get lost while tabbing through the main header and then reappear once the user tabbed to the order button. We’ve since resolved this issue, along with adding a clear focus outline to help users visually identify which element is currently focused.

Introducing skip links is another optimisation for keyboard users. This is a link which allows for repetitive content, such as navigation menu items to be skipped over so that users can jump to the main page content. This link is visually hidden; it only becomes visible when the tab key is used to navigate. We’ve added this accessibility enhancement to the header of our webpages so users using keyboard navigation now have the option to bypass the navigation menu to jump straight to the main content.

ARIA props

In our web code, we can utilise ARIA (accessible rich internet applications) roles and attributes to make areas of the website more accessible. We have already been using ARIA props across the online ordering experience, but there are areas we have missed where these props can enhance accessibility. Here are a few examples of the ARIA attributes we are incorporating into our websites to create a more accessible experience:

aria-label provides descriptive text for elements that don’t contain any visible text so that assistive technologies like screen readers can give context to the user. A good example of where an aria-label can be helpful is on icon buttons. The purpose of an icon button may appear visually obvious (provided that the icon accurately represents the button’s function), but it’s not as obvious to a screen reader, as they can’t interpret the button’s purpose from the icon alone. Clear and descriptive aria-labels ensure that assistive technologies describe the button’s action to users who can’t see the icons.

// Example of an aria label for a button that manually scrolls a list left
<StyledScrollButton
        onClick={() => canScrollLeft && scroll('left')}
        aria-label={translate('Scroll_content_left')}
        aria-controls={scrollListId}
        aria-disabled={!canScrollLeft}
      >
        <StyledArrowLeft />
 </StyledScrollButton>

aria-hidden can be used to hide an element from assistive technologies if it provides no useful information while keeping it still visible on the webpage. For example, decorative icons that are accompanied by text or other elements that provide the relevant context do not need to be seen by screen readers. Therefore, we can set aria-hidden="true" in these situations.

// Icon is decorative, so it can be hidden from screen readers
<button>
  <AddIcon aria-hidden="true" />
  <span class="label"> Add Item</span>
</button>

aria-haspopup lets screen reader users know if interacting with a particular element will open a pop-up. This is useful for buttons that open dialogs as it better prepares the users for the UI change.

// clicking login button opens a dialog, so aria-haspopup indicates this to screen readers
<StyledMenuItemButton onClick={handleLoginClick} aria-haspopup="dialog">
    <StyledMenuText variant="body1xs">
         {translate('Log_in')}
     </StyledMenuText>
</StyledMenuItemButton>

Colour Contrast

Colours play a massive role in ensuring web content is legible. High contrast between text and its background improves readability for all users, especially for people with visual impairments. The recommended minimum contrast ratio for WCAG AA compliance is 4.5.1, with a higher minimum of 7:1 for WCAG AAA compliance (except for large texts, which have slightly lower thresholds).

With these recommendations in mind, we are updating some text colours on our website templates to improve readability and align with accessibility standards. As our website colours are configurable via our Website Builder, the automatically applied text colour must remain readable against the selected background colours. Along with text colour contrast, ensuring sufficient contrast between primary buttons and page backgrounds helps users easily distinguish interactive elements from plain text. To help reduce the risk of website owners unintentionally introducing readability issues, we’ve updated the Website Builder to display a warning when a selected colour may negatively impact the visibility of elements on the website. We are also planning to expand these accessibility checks to other Website Builder settings to guide restaurant owners on how to build a more accessible online ordering experience.

Conclusion

By working on these accessibility improvements, we have gained a deeper understanding of the importance of building an inclusive website. Not only does it enhance the user experience for people living with disabilities, but it also positively impacts the overall quality of our product for all users. We still have some work to do to make our online ordering websites fully accessible, but the effort will be worth it. If you’re working on similar accessibility challenges or have ideas, feedback, or tooling tips, we’d love to learn from you. Please reach out or connect with us!