top of page
Search

The Story of Making Wix Accessible


One of Wix’s mottos is “The Way the Web was Meant to Be”. We believe that everyone should have a website, and of course, anyone should be able to access and use 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, due to different physical or cognitive impairments: they may have dyslexia, be blind, deaf, or have motor control impairments that make it difficult — or impossible — to use a mouse or trackpad.

A few months ago, we at Wix 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 we decided that the first phase of the project should focus on enabling users to build sites that are accessible, using the existing Wix tools.

Our team took on this project after we saw this video by Apple and this one by Microsoft. We wanted to take on this challenge and believed in its importance and ability to make an actual difference. We had 2 months and a team of 6 developers, split between Israel and Ukraine. In this limited time we knew we couldn’t cover all aspects of accessibility, but tried to make the most impact. The scope of the project was:

  • enable navigation by keyboard

  • provide Screen Reader compatibility

  • build infrastructure for accessibility development and testing.

Other assistive technologies and additional aspects of accessibility will be supported in future phases.

Enable Keyboard Navigation

Developers sometimes assume that all our users can interact with the sites using mouse, keyboard and touch. People with some disabilities might not be able to use all these interfaces and depend on the most basic one — the keyboard. Keyboard navigation is usually done with the TAB 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 (a common Wix element, that acts as a full-width container) need to have a logical behaviour that supports keyboard interaction, too.

With the help of our Product Manager and UX expert, and also an accessibility expert, we created a document that listed the desired behaviour of each Wix Component. There are over 150 such components, each with several display options. Our developers then went through all these and applied the desired behaviour.

The best method was to use the proper semantic HTML elements. For instance, if we have a button component, it should use a <button> HTML tag. A page’s navigation menu should use a <nav> tag. (This may sound obvious, but often developers choose to mimic a native element behaviour rather than simply use the most semantic element for the task.)

If, for any reason, we couldn’t change the HTML element in use, we had to resort to other, less semantic methods, such as using HTML’s tabindex attribute. This overrides the native behavior of an element when using the keyboard by telling the browser to skip an element, to focus on it (even if it’s not focusable by default) and can even control the order of the tabbing.

Once users can get to all the interactive elements, they need to 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 made 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” - we needed to make sure that elements that open as a modal window on top of the page (such as Lightbox) allow navigation inside, but doesn’t let the focus out until the Lightbox is closed.

Conversely, 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 - Focus should be retained within the modal (right) and not "leak" outside it (left)

DOM order

The last 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 before 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 Document Object Model (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 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)

Visual Focus

In addition to it being keyboard 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 inaccessible. 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 visual focus only when using the keyboard to navigate, hoping that it will make it less intrusive for mouse-using users.

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

People with impaired vision use assistive technology tools such as Magnifier Glass or a screen reader to interact with their computer. A screen reader synthesises a voice to read the site out loud to the user. Examples are VoiceOver, TalkBack, JAWS and NVDA.

Screen readers use an “Accessibility Tree” created by the operating system and browser, and enable various interactions with the site. Screen Readers read all elements, including non-actionable elements such as text paragraphs and descriptions of images using the DOM, which makes the DOM treatment discussed in the last section even more valuable.

Document Landmarks

We applied HTML document landmarks wherever we could, marking up the site header as <header>, the menu as <nav>, and more. These semantics tell the Screen reader what each section does, thus enabling it to create a more accurate Accessibility Tree with more relevant information about the site content. Many screen readers allow the user to jump past repeated content, such as header and site-wide navigation, and straight to the main content.

ARIA roles

Roles give information to assistive technologies about the behaviour of an element, its current state and and how to interact with it, in case the native HTML can’t be used or is not enough. One example is aria-hidden which makes a screen reader ignore 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 screen reader. 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 Screen reader that an element should be read and operated as a button, when a different HTML element is used to mimic a button. As far as possible, we tried to limit using roles as much as possible, favouring the built-in behaviours of native HTML semantics to minimize the chance of unwanted side effects.

Titles and Alt text

It’s simple, but crucial, to add titles, labels, headings and to all components. Wix has many graphic components that may only make sense when visible - for example, an icon shaped as a house. To a sighted person, it’s obvious that it’s a link to the homepage, but a person who doesn’t see won’t know that. Alt text is a well known best practice for images that convey meaning (photos, charts, etc. — not purely decorative ones), but descriptive text is needed for other graphic components as well, so we added the ability for the user to set it for any such kind of component.


Figure 4 - New Shape settings includes alt-text

The 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 screen reader user 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 accessibility development and testing

When working on the accessibility project, we always kept in mind that it’s not a one-time effort. Accessibility needs to become an inseparable aspect of product development from now on, just like we already consider performance, UX, mobile and localization. Therefore, we didn’t only work on the tasks we’ve already described, but also aspired to create tools for the future, and for easier development, testing and maintenance.

We build a collection of utility classes for handling keyboard interaction on components, getting “tab-able” (i.e. actionable) elements for easier navigation and creation of focus traps. We also introduced testing tools and methods to address accessibility validation. We used both third party libraries (aXe-core) and our own tools for easier component creation and validation.

All the knowledge we acquired during the process is continuously shared with other developers that work on different accessibility projects at Wix and is curated in different forms (readme files, presentations, this post) for future developers joining out team.

Technical Scope

While working on this project, we used the WCAG 2.0 guidelines. We found that there are no clear guidelines on how some elements (mainly complex ones), should behave, so we tried to rely the WCAG 2.0 as reference and guidance while creating the specifications that best fit our needs.

Different operating systems, browsers and screen readers treat accessibility aspects very differently. As a rule of thumb, we set our scope on the following support matrix:

  • Win 7/10 + Firefox + NVDA

  • MacOS + Safari + VoiceOver

To verify the outcome of our project we were helped by an organization that employs people with disabilities who tested our websites and gave us vital feedback.

Summary

In this 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, we also had a greater mission: to create a new culture of development that considers accessibility as one of the cornerstones of our product.

In the web world, as in the real world, there’s always more than one way to achieve a goal. We aspired to set a new mindset of always preferring the “native” solution over a proprietary one.

Another important outcome of this project is the introduction of accessibility, its language, conversations and its practices to Wix developers, by creating a small but dedicated community within Wix to advocate this cause.

This was our first major step. There will be more. To be continued...

Additional Resources


This post was written by Ohad Laufer

 
 
 

Comments

bottom of page