Apps on the user’s live site must be accessible, so that all site visitors can use your app – including those with disabilities.
It’s easy to make your app accessible – you can check off a few accessibility guidelines just by following common best practices for web development.
For now, just focus on making your site component accessible to site visitors. You’re not required to make your App Settings panel or dashboard component accessible.
Accessibility is one of our app requirements, but it’s also important for your users.
Here are just some of the benefits to making your app accessible:
- It’s a quick win. Accessibility is easy to implement, and along the way you’ll end up fixing issues that will improve the experience for all site visitors (not just keyboard/screen reader users).
- You’ll retain existing users. Now that some countries require all websites to be accessible, users might start removing apps that aren’t accessible.
- You’ll help users reach out to all their site visitors. By contributing to their website’s overall accessibility, you’ll help make sure users don’t lose traffic from site visitors using a keyboard or screen reader.
- You’ll be part of a larger effort to make the web accessible to everyone. We’re kicking this off in Wix by helping our users make their websites accessible.
Always use HTML elements when possible. This will make it much easier for you to implement accessibility, because HTML elements are already accessible.
Color contrast is also important for accessibility, but all you need to do is make sure you follow our color reference guide for your app’s colors. We created this guide to make sure that the colors look good together and that there’s enough contrast in your app.
Build your app to be fully operational with the keyboard (not just mouse clicks). HTML elements already work well with the keyboard, so use HTML elements when possible.
Got any custom elements in <div> or <span> tags? Use the tabindex attribute to allow keyboard users to get to the interactive element, and listen for keyboard events so that users can interact with the element.
When defining the keyboard behavior, make sure that:
- Site visitors can get to all interactive elements using the tab key – dropdowns, submenus, scroll, buttons, etc.
- The tab key goes through your app in a logical order.
- A focus indicator shows site visitors where they are in the app.
Important: Your app’s visual focus indicators must be consistent with the rest of the user’s site.
Use SDK version 1.84.0 or later – we’ll inject the visual focus properties into your app. (To see visual focus when testing your app, enable visual indicators for your Wix site.)
- Have any popups?
- Site visitors can get to all popups.
- The focus indicator moves to the popup when it opens, and stays there until the visitor closes the popup.
- Site visitors can close popups using the esc key or a close button.
- App responds to the right keyboard events (arrows, enter, tab, etc.).
Here’s an example to show you these guidelines in action:
Build your app in such a way that screen readers understand it. If you’re already following common development practices, like using HTML elements correctly and using the right headings – then you’re almost there!
Here’s what you should do:
1. Create the right hierarchy for your app, starting with <h2>. Headings help screen readers and other accessibility tools understand the relationship between different areas in your app.
- Use <h2>, <h3>, and so on, according to your app’s hierarchy.
- Don’t use <h1>, because it can cause issues for pages that already have an <h1>.
2. When possible, use native HTML elements. These elements are already accessible, so there’s very little work to do here:
- Use HTML elements the way they were meant to be used (i.e, when you need a button, use a button – not a shape with a link inside).
- If your app displays an icon or hard-coded image that the user can’t change, add an alt-text attribute to describe what the image is.
3. Got any custom elements in <div> or <span> tags? Add the right attributes and labels so that screen readers can understand how these elements work. For example, the role attribute tells the screen reader the purpose of this element (like a checkbox or list).
Follow this ARIA guide, which explains how to comply with accessibility standards for common UI elements like alerts.
Here’s an example of a search box from the ARIA guide:
<input type="search" aria-label="search text" size="20">
<input type="submit" value="Search"">
4. Notify site visitors about any updates or errors. For example: an error message that appears if input validation fails, a confirmation message that appears when a site visitor submits a form, a new image being displayed as the site visitor clicks through a slideshow, etc.
Here’s how to notify screen-reader users about the update:
- Use the aria-live attribute, as explained in this guide.
- Show the alert visually, and don’t rely on sound or color alone to signal a change. (Someone who is color blind may not notice the color change.)
5. Allow users to add more details for people with visual/auditory impairments. This is only relevant for you if users upload images, video, or audio files to your app.
Offer settings in your App Settings panel or Dashboard component that allow users to add information about their content, for example:
- An alt-text attribute for images
- A transcript for audio files
- Captions for videos
Check our list of common elements, below. If your app has any of these elements, follow the behavior we’ve outlined for similar Wix elements.
This gives site visitors a smooth experience across the Wix site – for example, all popups get focus with the Tab key, and close when the site visitor clicks Enter.
Here are the most common elements your app might have:
- Boxes, Shapes, and Strips
- Buttons and Upload Buttons
- Checkboxes and Radio Buttons
- Contact Form
- Date Picker
- Dropdown Menus and Expandable lists
- eCommerce Cart Widget and Quantity Selector
- Images, Galleries, and Slideshows
- Menus, Breadcrumbs, and Page Navigation (anchors)
- Social Icons
- Tabs and Tables
- Text, Text Input, and Text Boxes
- Tooltips and Hover States
- Video and Audio Players, External Video
We’ll show you how one of our third-party developers got started with making his app accessible (the Comments app).
1. The developer used a screen reader to check the app on a live site.
Here are just a few examples of accessibility issues he found:
- Screen reader users can’t log out because this button isn’t interactive.
- Screen reader users don’t understand that each comment has a rating.
- Screen reader users can’t share comments because the share buttons aren’t interactive.
Check it out (listen with your sound on):
Let’s focus on the issue with the logout button.
Take a look at the code to spot the problem:
<a onClick="logout()">Log out</a>
2. The developer fixed these issues by defining the right ARIA roles and keyboard behavior.
Now, screen reader users can logout, add a rating, and share the comment to social media.
Check it out (listen with your sound on):
Here’s the new code for the logout button:
<a onClick="logout()" role="button" tabindex="0">Log out</a>
Want to see more code examples from this app? Uri, the app developer, wrote a blog post about how he made his app accessible. Check it out!
We’re working on adding more examples and case studies to show you how our developers made their apps accessible. Want to share your story? Reach out to us!
As part of testing your app, you’ll need to make sure that each component is accessible on the user’s live site.
Download and follow the right testing plan(s) for your app. Each testing plan includes specific tasks for testing accessibility.