One of Wix’s known mottos is “The Way the Web was Meant to Be”. We at WIx truly believe that everyone should have a website, and of course, anyone should be able to access and use these websites, built using Wix tools.
Wix has many users, and these users are very diverse. Users have various devices, browsers, internet connections, and more. Users may also not be able to use all interfaces as we may think due to different impairments. Making sites accessible for these users is referred to as Accessibility.
Accessibility (AKA a11y, for short) has many forms:
Visual
Hearing
Motoric
Cognitive
These account for both permanent and temporary impairments. Anyone might injure their arms losing their ability to use a mouse and must resort to navigating websites using the keyboard. A simple visit to the eye doctor, when administering a pupil widening solution, can leave you unable to read, making Screen Reader capabilities extremely useful. Even if you want to watch a video on a noisy bus, but forgot your earphones at home, leaving you in a desperate need for captions. A few months ago, we at Wix Engineering decided to make sure our sites are accessible. When we say a site is accessible, it means that the site's content is available, and all of its functionality can be operated, by anyone.
The goal was to “Enable our users to create an Accessible site”. This is different than modifying existing sites to be accessible. Wix can’t prevent our users from using low-contrast colors or small fonts, so it was decided the first phase of the project will focus on enabling users to build sites that are accessible, using the existing Wix tools.
Our team took on this project after we were shown this video by Apple and this one by Microsoft. Much convincing wasn’t needed as we wanted to take on this challenge and believed in its importance and ability to make an actual difference. We had 2 months at our disposal and a team of 6 developers, split between Israel and Ukraine. The scope of the project was:
Enable navigation by keyboard
Provide Screen Reader compatibility
Build infrastructure for a11y development and testing
In the following Blog Post I will describe in detail what we did.
Enable Keyboard Navigation
Focusable Elements
Visual Focus
DOM order
We as developers sometimes assume that all our users can interact with the sites using mouse, keyboard and touch. People with some physical or cognitive disabilities might not be able to use all these interfaces and resolve to the most basic one - keyboard. Keyboard navigation is usually done using the TAB or Arrow key or the Arrow keys. The user can use TAB to move forward in the site to the next interactive element, and SHIFT+TAB to move back. Interaction with focused elements is usually done using ENTER or SPACE keys.
Focusable Elements We wanted to make sure that all of the site’s features are accessible via keyboard interactions - the user should be able to access and operate all interactive elements of the site. This means that all links, buttons, menus, etc. need to work well when using a keyboard. Not only do “simple” elements need to behave properly when used with a keyboard, but more complex elements, such as Galleries, Contact Forms and Strips need to have a logical behaviour that supports keyboard interaction, too.
With the help of our Product Manager and UX expert, in addition to consulting with an a11y expert, we created a document that listed the desired behaviour per Wix Component (Mind you, there are over 150 such component, each with several display options). We had to go through each and every of these Wix Components and apply the desired behaviour.
We had several options to achieve our goals: The best one was to use the proper semantic HTML elements. For instance, if we have a button component, it should use a <button> HTML tag. A menu should use a <nav> tag. This may sound obvious, but more often than not, developers choose to mimic a native element behaviour in order to achieve the desired outcome. If, for any reason, we couldn’t change the HTML element in use, we had to resolve to using tabindex=0 and role=button HTML attributes. These attributes change the native behavior of an element when using the keyboard. It can tell the browser to skip an element, to focus on it and even controls the order of the tabbing.
Now that users can get to all the interactive elements, we want to make sure they get there in a meaningful order. For example, when navigating through Matrix Gallery images, the first tab should land on the first image, then allowing the user to use their arrow keys to move through the collection. The next tab should move the focus to the “next page” button, and another tab key press should move the focus to the “previous page” button. All these adjustments had to be done very carefully and for each possible layout of the Component.
Figure 1 - Tab order in a Gallery
An additional aspect of Keyboard Navigation we had to handle is “Focus Traps” - on the one hand we needed to make sure that some elements, such as Lightbox, that open as a modal window on top of the page, allows navigation within, but doesn’t let the focus out until the Lightbox is closed. On the other hand, we needed to make sure that only components that we deliberately made “focus traps” act as such, to prevent other components (usually external Iframes) from getting the user’s focus and not releasing it as the user keeps on tabbing.
Figure 2 - Focus Trap behaviour Focus should be retained within the modal like seen on the (right) and not "leak" to the page as seen on the (left)
Visual Focus In addition to it being accessible, the element should display an indication when focused. This indication (“Visual Focus”) behaves as an alternative to the mouse cursor and lets the user know which element she’s interacting with.
At Wix, like many other websites, the visual focus was actively disabled up until now, rendering the sites highly non-accessible. The reason for that was a design one - the focus indication “doesn’t look good”. In this project we now enable users to toggle Visual Focus for their site on or off. We also try to use the new :focus-ring future standard that displays the indication only when using the keyboard to navigate, hoping that it will make it less intrusive for mouse-using users.
DOM order The last but not least aspect of Keyboard Navigation is the need for the navigation path to follow the way the site looks. This means that if Element X is directly above Element Y on the site - the user should pass from element X to element Y when tabbing. We want to make this flow as intuitive as possible to the user. When navigating, the browser uses only the HTML DOM order so we had to make sure the DOM order reflects the actual order of components on screen. Lucky for us, we used an existing algorithm that was developed at Wix, that analyzes the elements’ position on the site and generates the proper order. We now allow users to explicitly run this algorithm on the site. In the future, this will be done behind the scenes for all users.
Figure 3 - Wix site DOM order - The red line depicts the order in which tabbing occurs, before (left) and after (right)
Having completed all of the above, handling many components and lots of edge cases, we now finally have a site that is fully navigable and functional using keyboard only.
Make the site usable by Screen Readers
Page Semantics
ARIA attributes
Titles and Alt texts
People with impaired vision use a11y Assistive Technology tools such as Magnifier Glass or Screen Reader to interact with their computer. Screen Readers (SR, for short) use an “Accessibility Tree” created by the OS + Browser and “read” the site to the user, also enabling various interactions with the site. The main difference between keyboard navigation and Screen Reader is that SRs also read non-actionable elements such as text paragraphs or images. When “reading” websites, SR use the DOM, which makes the DOM treatment discussed in the last chapter ever more valuable.
Page Semantics We applied Page Semantics wherever we could. Marking the site header as <header>, the menu as <nav>, and more. These semantics “tell” the SR what each section does, thus enabling it to create a more accurate Accessibility Tree and giving the SR user more relevant information about the site content.
ARIA-roles Roles are used to “hint” the SR on the actual behaviour of an element and how to interact with it, using this hint to manipulate the Accessibility Tree in case the native HTML can’t be used or is not enough. The most basic use case is aria-hidden which makes SR skip an element. This is most commonly used when an element is heavily nested and we only want that element to be read, omitting all its predecessors. Another common use is aria-live which is used when something changes on the page and we want to notify the SR. We used it for such components such as Contact Form (for invalid field indications), Lightboxes and Image zoom mode. We also used roles such as button to tell SR that an element should be treated as a button - read and operated - while a different HTML is used. All in all, we tried to limit “cheating” using roles as much as possible and made an effort to use it as directed to minimize the chance of unwanted side effects.
Titles and Alt texts The last but not least type of changes we did involved the simple, but crucial, adding of titles and alt-text to all components. We have many graphic components that may only make sense when visible. For example, an icon shaped as a house. To a seeing person it may be obvious that it’s a link to the homepage, but a person who doesn’t see won’t know that. Alt-text is a common practice for images, but alt-text is needed for all graphic components as well and we added the ability for the user to set it for any such kind of component.
Figure 4 - New Shape settings includes alt-text
Same goes for types of buttons and Iframes who can be used for various purposes - adding a title or aria-label to these items tells the SR-using user what is the functionality of the specific element. As a very desirable side effect, these additions also make the site more SEO friendly - bots don’t “see” the graphics either, but only content - so in this case, it’s totally a win-win.
Build infrastructure for a11y development and testing
When working on the a11y project we always kept in mind that it’s not a one-time effort. A11y needs to become an inseparable aspect of product development from now on, just like we’re considering performance, UX, mobile and localization. For this sake we didn’t only handle the tasks described above but also aspired to create tools for future use, for easier development and easier testing and maintenance.
Such tools comprise of utility classes for handling keyboard interaction on components, getting “tab-able” (i.e. actionable) elements for easier navigation and creation of focus traps. Additionally, as part of the project we introduced testing tools and methods to address a11y validation. We used both third party libraries (aXe-core) and our own tools for easier component creation and validation.
All the knowledge we acquired along the process is continuously shared with other devs that work on different a11y project at Wix and is also curated in different forms (readme files, presentation, this post) for future devs to come.
Summary
In this Blog Post I told the story of the work we did over last 2 months, making Wix sites accessible. Apart from the main goal of this project, to give users the ability to create accessible sites using Wix, we also had a greater mission. This mission was to create a new culture of product and development that considers a11y as one of the cornerstones of our product.
In the web world, and not only there, there’s always more than one answer to how something should be done. We aspired to set a new mindset of always preferring the “native” solution over a proprietary one. The means to achieve that were, first and foremost, by setting an example, migrating over 150 components ourselves, but also with providing easy tools for developing and testing for accessible components.
Another important outcome of this project is the introduction of a11y, its lingo and its practices to Wix devs, as well as by creating a small but dedicated community within Wix to advocate this cause.
Giving credit where it’s due, here’s to the great team who is responsible for this project: Nir Horesh - A11y Product Manager Nathalie Aharon - A11y UX expert Tom Enden - FED TL Liran Kurtz - FED Jonathan Avinor - FED Bogdan Litvinov - FED Maksim Petruk - FED Ihor Khudik - FED Anna Bilyavskaya - QA Neil Osman - A11y expert (external) And many many more.
Additional Resources