DEV Community: Oliwia Połeć

Build an App and Enjoy a 0% Commission Fee

Oliwia Połeć — Mon, 27 Nov 2023 14:04:28 +0000

After your application goes live, the initial weeks are crucial for building momentum and capturing the attention of your prospective customers. It's a time when your app is fresh and exciting, allowing users to test it and see how they like it.

This period presents a unique opportunity. You earn customer trust and loyalty, and show your commitment to their satisfaction by acting on feedback and providing assistance.

To support your efforts, dedication, and hard work, we’re delighted to offer you an exceptional opportunity. Publish your Text Platform app before January 31, 2024, and enjoy a completely waived commission fee for 60 days from publication. This means you can focus on what matters most and enjoy 100% of the revenue earned from your installations.

But that’s not all! There are various other benefits — and they’re just as attractive. Take a look at what we have in store for you:

🎫 Free promotional space

Take advantage of the opportunity to get your app featured on the Marketplace homepage or in the LiveChat App, improving your visibility and increasing prospects for installations.

🧑‍💻 Premium support through Discord

Experience the benefits of priority support through our dedicated Discord server. Our team of product experts is ready to provide you with top-notch assistance and guidance on any development questions.

💲 Discounts on future fees

As you reach pre-set milestones, you can unlock discounts on commission fees beyond the initial 60 days. Check out the benefits of the following milestones:

First 10 sales: An additional 14 days of zero commission fees upon reaching the first 10 sales of your app.
Three 5-star reviews: An additional one month of zero commission fees if the application receives at least three 5-star reviews before the end of your app’s zero commission fee period.
First 25 sales: An additional one month of zero commission fees.
Publishing a second application: If you publish a second application before the end of the initial zero commission fee period for the first application, the second application will be eligible for 30 days of zero commission fees.

📚 Training and webinars

First time developing in the Developer Program? Access our video and text materials on application development to kickstart your journey and gain expert insight.

🧑‍🎓 Mentorship

Receive personalized answers and mentorship from Text’s developers and gain first-hand insights on app development.

Don't have an idea for your app? 🤷

Grab our three app ideas suitable for beginners that would make great additions to the Text Marketplace:

[LiveChat] Please hold on 🕐
Send an automatic customizable message to a chatting customer if the chat is idle for a certain period of time.

💻 Development Kit:
Agent Chat API
Accounts SDK

[HelpDesk] Integration with Messenger 💬
Create HelpDesk tickets directly from Messenger messages, providing a new channel for communication with coworkers and external recipients.

💻 Development Kit:
HelpDesk API
HelpDesk SDK

[LiveChat] Simplified tag editing 🗂️
Automatically replace existing chat tags with new tags in all the chats they were already added to.

💻 Development Kit:
Configuration API
Accounts SDK

And if these don't hit the spot, have a look at the entire list of available app ideas.

If you find the idea intriguing and would like to participate, visit the campaign’s landing page to find additional details.

And... Happy coding!

Exciting New Development Options in the Developer Console

Oliwia Połeć — Mon, 05 Jun 2023 11:02:35 +0000

The world is going the way of Artificial Intelligence and automation. With hectic schedules and more and more tasks to complete, people are looking for ways to make their work more accessible and efficient in the shortest amount of time possible.

To address these needs, the Developer Console has taken the lead by introducing exciting new development possibilities. You now have the option to effortlessly connect your GitHub repository to your Developer Console app, seamlessly integrating it with deployment services like Netlify or Vercel — all to simplify and smooth out your deployment workflow.

So what’s the fuss all about?

Until now, you had to go through the steps of setting up your own repository in GitHub and working on your app using the code editor on your local machine to create your application in the Console. You also needed to manually set up a deployment on your end, or even rely on your own servers.

Right now you can both create repositories and complete the deployment straight from the Developer Console, staying in the same context and streamlining your workflow. You can also manage your application’s code through Visual Studio, and — you guessed it — you can access it directly from the Console.

Now you know that the Developer Console can optimize and automate a great deal of your work. In fact, you can manage almost your entire development process from the Developer Console’s application view. If you’d like to know more technical details on this process, have a look at our docs.

And what if you’re not a Developer Console user? What can I say — stop wasting time and sign up! It’s a superb place with multiple opportunities to create a passive income stream by building applications. Check out our Developer Program >>

Automated Accessibility Testing

Oliwia Połeć — Tue, 21 Sep 2021 13:24:48 +0000

As described in our recent series of blog posts, our team has been working on improving the accessibility of the Chat Widget. While making the improvements, we wanted to maintain top-notch quality and ensure that while introducing new changes, there was no drop in standards. We use Cypress for all our automated testing, and so we decided to extend the existing testing suite by adding automated accessibility tests. In this article, I’d like to share with you what we’ve learned and how you can do this yourself!

Example app overview

In order to make it easier for you to follow, I’ve created a simple app that allows the user to submit a dummy form. You can find the repository here. Don’t worry, the data you submit in the app is not sent anywhere, so you can play around with it as much as you want.

It’s created using the Create React App scripts and using yarn as a dependency manager (installation instructions). After cloning the repository, all you need to do is install the dependencies by simply typing yarn (or npm install if you'll choose to do it without yarn) in the console. Then, with yarn start (or npm start), you can run the app, and it will be available at http://localhost:3000. Each step described in the article is reflected on the corresponding git branch.

The repository also contains a simple integration test created with Cypress, located in the functional.spec.js file.

`cypress-axe`

In the previous article describing our journey with accessibility testing, I mentioned the axe DevTools browser extension. It allows the user to perform audits on the website, so that any accessibility issues can be discovered. This extension is based on the axe-core engine — a testing tool, validating against different types of rules and best practices.

The same engine can be used with Cypress, thanks to the cypress-axe package. It adds several custom commands to the Cypress API, which utilizes “axe-core” under the hood. It makes it possible to perform a11y audits directly while testing.

Let’s, then, add the required dependencies to the project — we need the cypress-axe and axe-core (with the --dev flag, so that these are added as developer dependencies):

yarn add cypress-axe axe-core --dev
# or
npm install cypress-axe axe-core --save-dev

Now, we need to let Cypress know that we have extended the list of commands. Therefore, we should add the following import statement in cypress/support/index.js:

import 'cypress-axe'

Great, with that in place, we can start using the library.

Running audits

The first command we’re going to use is injectAxe. Basically, it inserts the axe-core code into the application under test. Therefore, it needs to be run after the visit call (and after each reload) to make sure the runtime is available on the website.

Let’s create a separate accessibility.spec.js test suite and utilize it in there:

it('should not report any errors during the accessibility audit', () => {
    cy.injectAxe()
})

We can run the tests now. To get more feedback while developing, we’ll run it in Cypress Test Runner with a full GUI. This can be done via the open command (keep in mind to start the app earlier with yarn start):

yarn run cypress open
# or
npx cypress open

And in the runner, we select accessibility.spec.js to run it:

So far, so good — the test runs without any errors. After opening the developer tools and switching the console context to our app, we should have access to the axe object, which indicates that it was indeed correctly injected:

It’s worth noting that the library also adds a configureAxe command. This corresponds to axe.configure from axe-core, described here. Using it is not needed in most cases but might be useful.

We can now run the audit. This is done with the checkA11y command. It can be run with the following parameters, all optional:

context — a selector to a DOM element that should be analyzed.
options — overrides for the global axe configuration whenever you want to set custom rules or checks for just that particular audit.
violationCallback — custom handler for reported errors.
skipFailures — allows you to prevent the test from failing on error and instead only log the error to the console.

Let’s add it to the test and run it (on branch: step-1):

it('should not report any errors during the accessibility audit', () => {
    cy.injectAxe()
    cy.checkA11y()
})

The app fails a test, informing the user about the violations. Upon clicking on each of the violations, the console logs more details, and the element causing the violation in each case is highlighted:

The log for each violation contains the following set of information:

command — informing us whether a violation is an error, warning, etc.
id — identifier of the violated rule, for example, button-name or color-contrast.
impact — defining the severity of the violation.
tags — making it easier to identify which rulesets were violated (e.g., wcag2a).
description — brief details about the rule.
help — information on how to fix the issue.
helpurl — link to more details about the issue.
nodes — affected elements.

Fixing the bugs

In the example, we had three bugs reported. The first one was about the “clear the form” button missing “discernible text.” As you can see, it’s an “icon button.” This means that screen reader users won’t be able to identify what it does! One way of fixing that is by adding an aria-label attribute to the button.

The second issue reported is informing us that the color contrast on the submit button is incorrect. Using “inspect” from the browser’s dev tools, indeed we can see that the contrast is 1.41, while the rule requires at least 4.5 for smaller texts:

It can be easily fixed, for example by changing the text colors on the buttons to “black” instead of “white”:

The last error is caused by the form input missing a label, and each one of them should have it so that screen reader users can easily navigate around. This can be fixed by either setting a for attribute to the id of the given input for the label, or if a label is not present, by adding a corresponding aria- attribute.

Let’s apply all of the fixes (branch: step-2) and re-run the tests:

Nice! The app has passed the test, meaning that there were no accessibility violations found during the audit. With that test included in the pipeline, we can make sure we have not introduced any regressions in that area.

Audits are not all there is

Audits are a powerful way of verifying accessibility violations; however, these are not always enough. The application might pass all of the automated audits, yet still not be accessible.

One of the additional layers you can add to make sure you are building a good, accessible app, is to use “accessible queries” for elements you interact with in the tests. In other words, you find elements by text, labels, roles, aria-attributes, etc., rather than using the IDs or data-test attributes. This applies to all layers of testing. There is a very useful project called Testing Library, which provides you with UI-centric queries out of the box. It has a separate package for many different testing methods and libraries, including the Cypress one: Cypress Testing Library.

Let’s take a look at the test we initially had in the repository (file: functional.spec.js):

it('should allow submitting data', () => {
    cy.get('[id=name]').type('Dummy')
    cy.get('[id=last-name]').type('Tester')
    cy.get('[id=books]').click()
    cy.get('[type=submit]').click()
    cy.contains('Thanks for submitting the form!').should('be.visible')
})

It heavily relies on the IDs — these don’t matter much for the end-user since they rarely browse the web with the developer tools opened. They care much more about the labels we mentioned before, so let’s try to rewrite that test with that in mind.

First, we need to install the dependency:

yarn add @testing-library/cypress --dev
# or
npm install @testing-library/cypress --save-dev

Now, we add an appropriate import statement in cypress/support/index.js:

import “@testing-library/cypress/add-commands”

That’s it — we can make use of all the queries! Let’s apply that to the test (branch: step-3):

it('should allow submitting data', () => {
    cy.findByLabelText('Name:').type('Dummy')
    cy.findByLabelText('Last Name:').type('Tester')
    cy.findByLabelText('Books').click()
    cy.findByText('Submit').click()
    cy.findByText('Thanks for submitting the form!').should('be.visible')
})

After running the test, it still passes:

Using the findByLabelText command, we would have found the bug reported by the audit much sooner. Even if you were to decide not to use that package, referring to the priority of the queries description in the Testing Library docs would be beneficial for your users, and the quality of your tests.

Keyboard navigation

Additionally, you can test the flow of your app for just keyboard navigation. A lot of users use just the keyboard to browse the web, and it’s important that the whole application flow can be completed without using the mouse. You can read more about its importance in the “Keyboard navigation” article.

The way Cypress is built does not allow simulating “real” user actions out of the box. All of the actions there are triggered via JavaScript. Usually, this is not a problem; however, in terms of keyboard navigation, it is — we won’t be able to use a “Tab” key, which is necessary to simulate how the user would navigate around. Luckily, the Cypress Real Events package comes in handy (or its alternatives, e.g. Cypress Plugin Tab). It uses the Chrome DevTools Protocol (so it only works in Chrome) in order to fire actual system events. Still, it has its downsides, though — you won’t be able to interact with certain system elements like default selects. If you were to determine that this is an important part of your app, other testing frameworks might be necessary.

Creating a simple test for keyboard navigation

Let’s create a simple test for the keyboard flow. Let’s add the package to our project:

yarn add cypress-real-events --dev
# or
npm install cypress-real-events --save-dev

And, as previously, import it in the cypress/support/index.js to let Cypress know about the new goodies:

import "cypress-real-events/support"

Now, we should have access to all of the additional API commands. What interests us most are realPress (for single key presses) and realType (for typing).

Let’s add another simple test case, then, in the accesibility.spec.js suite. We must use only the keyboard to navigate around and fill in all of the inputs in the form.

Based on the application overview, after visiting the page, the first Tab stroke should focus us on the "Name" field within the form. Let’s check that, then, using both the realPress command from cypress-real-events and the focused one (from Cypress). The latter is from the Cypress API and gets the currently focused DOM element. However, since Cypress wraps the Application Under Test (AUT) in its own, separate iframe, and the events are fired using the CDP, we would need an extra click somewhere in the AUT. This would make sure the events are correctly fired for the AUT and not the Cypress runner.

it('should allow submitting with just keyboard', () => {
    cy.findByText('Dummy form').should('be.visible').realClick()
    cy.realPress('Tab')
})

So far so good. We would need an assertion to make sure that the focused element indeed has the “Name:” label. Let’s add a custom assertion for that:

const assertFocusedInputLabel = (expectedLabel) => {
  return cy.focused().then(($el) => {
    cy.get(`label[for="${$el.attr("id")}"]`).should(
      "have.text",
      expectedLabel
    );
  });
};

Now, let’s add that to the test, along with the typing action:

it('should allow submitting with just keyboard', () => {
    cy.findByText('Dummy form').should('be.visible').realClick()
    cy.realPress('Tab')
    assertFocusedInputLabel("Name:").realType("Dummy");
})

And now, let’s run it!

The test passes, hooray! We can now do the same for other form elements, and finally, submit a form using the Enter key (branch: step-4):

it("should allow submitting with just keyboard", () => {
    cy.findByText("Dummy form").should("be.visible").realClick();
    cy.realPress("Tab");
    assertFocusedInputLabel("Name:").realType("Dummy");
    cy.realPress("Tab");
    assertFocusedInputLabel("Last Name:").realType("User");
    cy.realPress("Tab");
    assertFocusedInputLabel("Books").realPress("Space");
    cy.realPress("Enter");
    cy.findByText("Thanks for submitting the form!").should("be.visible");
});

Let’s run the test and see how it does:

Oh no, a failure! Upon investigation, it seems that someone has added a tabindex=-1 attribute to the “Last name” field. That attribute will make the element “not tabbable” and as a result hide it from keyboard users. Let’s remove it (branch: step-5) and re-run the tests:

Perfect, we can see that it would find a bug in such a case. As you can see, the audit has passed, as this attribute is not disallowed. This is why having an additional layer for that would be highly beneficial in the long run.

Static analysis

The other things — apart from automated tests — you can add to prevent accessibility mistakes, are accessible plugins for the linters. In the same way they let you know about missing semicolons, they can warn you whenever necessary attributes are missing, or any other violations are made.

A good example of such a tool is the axe Accessibility Linter VS code plugin. With the same axe-core rules engine, the plugin will inform you whenever an accessibility bug appears.

The other example is an accessibility eslint plugin for JSX elements: eslint-plugin-jsx-a11y. Although it would not inform you about all of the errors, it would for sure prevent you from making the most basic mistakes. The eslint plugin has a big advantage over any editor plugins — it can be run as a pre-commit hook or on the CI before the build process. Thanks to that, the verification can be forced within the project configuration.

Wrap-up

Making our Chat Widget accessible has been really enlightening for us, in many areas. It was also hard work, requiring a lot of learning. We believe in the value automated tests bring, and since accessibility is one of our biggest priorities, we want to make sure that it’s being thoroughly tested. We hope that with this description of our test setup, you’ll try it yourself.

Be sure to let us know if you have any questions!

Screen readers: hearing the unseen

Oliwia Połeć — Wed, 30 Jun 2021 12:20:14 +0000

A screen reader is software which forms part of a group of Assistive Technologies and renders graphical user interface content in the form of speech or braille output. This kind of software is essential for people that are blind or have any visual impairments as it allows them to interact with a computer or mobile devices in much the same way as the screen allows it for sighted people. In order to properly describe the particular parts of the user interface, the software needs the context and/or additional metadata provided by the application developer in order to properly present the content using a text description.

There is a variety of screen reader software to choose from, and there are multiple ways of feeding them with data used for content descriptions. In this article, we will dive into this topic and show how this remarkable software makes it possible to use a computer or mobile devices without the need for visual references.

Examples of available screen readers

There are quite a lot of different screen reader applications to choose from. They can be implemented in the form of native operating system support, like VoiceOver by Apple Inc. They can also be implemented as downloadable third-party software, like JAWS, which requires a paid license, or NVDA, which is built as an open-source solution and is free to use. Screen readers can even be found in the form of add-ons to software already being used by the user. For example, ChromeVox, which is available as a web browser add-on for Google Chrome. Despite their abundance, they all share the same purpose and basic functionality, but there are many differences in the way they handle their features. Some of them are more obvious, like ones in the customization interface or available options.

There are also differences in the keyboard shortcuts, which adds a barrier for the user if he/she ever wants to change their screen reader of choice. It is also good to keep in mind that screen readers can differ in the way they recognize application content, so it is also good to verify your application on more than one of them, just as you would when testing on different devices or web browsers. Analyzing all available solutions on the market would definitely require a separate article, but we can briefly check the most commonly used options, which according to the screen reader survey, are NVDA (72.4%), JAWS (61.7%), and VoiceOver (47.1%).

NVDA, which stands for NonVisual Desktop Access, is free, open-source screen reader software which works on the Microsoft Windows operating system. It was released in 2006 and is available in 48 languages. It also supports braille displays.

JAWS, which stands for Job Access With Speech, is paid screen reader software which works on the Microsoft Windows operating system. It was released in 1995 and was originally created for the MS-DOS operating system, and a fun fact is that this version is still available as JDOS and is free to use. It supports 10 languages. Its unique feature is the JAWS Scripting Language, which allows the user to add an accessibility layer for programs that were not designed with accessibility in mind.

VoiceOver is free-to-use screen reader software built into the operating systems created by Apple Inc. As it is available both on the desktop and mobile operating systems, it supports touch and keyboard navigation. It was released in 2005 together with Mac OS X 10.4. Its main strong point is its native support for the operating systems as they were both built by the same company. A unique feature is its support for multitouch gestures, not only on mobile devices but also on desktop trackpads utilizing the rich trackpad support in Mac OS.

Screen reader customization

Most screen readers allow the user to customize their experience of using this software. The precise set of available options differs among the various types of screen readers, but there are a couple of features that are most commonly used and supported.

First of all, the user can specify the language in which the content should be read. Most screen readers support more than one language depending on the support of a particular program.

Another common setting is the level of verbosity. This allows the user to specify how much speech feedback is needed. It depends mainly on the level of visual impairment and so, for example, users who have partial vision can use less verbose speech and focus mainly on the content itself and not the metadata. On the other hand, blind users could need the full verbosity level, including all additional descriptions of content and placement of, for example, current interactive elements in the scope of the application. This is one of the reasons why the developer must provide all available content metadata as it is the user who should decide which of them is needed for uninterrupted usage of the application.

One more popular setting for screen readers is the reading speed. This is pretty self-explanatory — it specifies how fast the lector should read the text. It is usually specified in a words-per-minute unit. In English, the typical read speed ranges between 120 to 150 words per minute, where advanced and fast screen reader users can understand content being read at a speed of even 450 words per minute. Even if most screen reader users don't require such high speed, it is still common for them to use higher rates than that of typical spoken language. It is important to keep in mind that the first impression that long-to-read content slows down the user can be deceptive as when set at high reading speed rates, it is being read blazingly fast. Remember, don't worry too much about long descriptions.

Screen reader usage and the Web

Each HTML document begins with an <html> tag, and this is the first place for an appropriate accessibility setting. Using the lang attribute, it is possible to specify the language for the whole document, which the screen reader will use in order to determine which language to use for speech. The second element close to the beginning of the HTML document is the <title> tag, which contains the title of the current document. It is read by the screen reader when first loading the webpage.

Web document content is always presented in a linear way when using a screen reader. This is a totally different approach for content layout than typical graphical user interfaces, which are commonly multidimensional. One of the best representations of these differences in perception of the layout is the automated telephone menu system. The webpage content is being unveiled to the screen reader user one step at a time. This implies that the structure of user interfaces needs to take into account the complexity and also the order of the interactive elements and main page content. One common issue associated with this perception difference is the top navigation menu. In most cases, it is the first set of interactive elements in the navigation order. The screen reader needs to go through all of them in order to access the main page content, which is not the case for graphical interface users. As a solution to this problem there is the common technique of implementing a “skip to main content” button, being the first interactive element on the page, and it allows for quick access to the main page content.

Navigation through webpages using screen readers is possible in various ways. Some of them provide users with an option to navigate content quickly, despite the linear nature of audio interfaces. The most basic navigation consists of moving one step forward by pressing the [Tab] key or one step backward by pressing the [Shift+Tab] key combination. Each step made like this will focus on the next or previous interactive element, like links, buttons, form controls, etc. The screen reader will then announce the currently focused element using its node type and additional metadata.

The second type of navigation available in screen readers is heading navigation. The screen reader, via a dedicated shortcut, allows the user to present a webpage map of available headings (in the form of a list), which he/she can then use to navigate directly between. This is a very commonly used technique as it allows quick access to the interesting parts of the document and makes it easy to skip those parts that are not of interest to the user. Because of this technique, it is very important to maintain a logical order in heading structure. For example, nesting an H2 element inside an H5 element should be avoided.

The third common type of navigation using screen readers is ARIA landmark navigation. It is similar to headings navigation, but instead of presenting a map of the heading elements, it allows navigation through the meta structure of the webpage using HTML5 semantic elements like <main>, <nav>, <header>. And also, as with heading navigation, this technique allows quicker access to the desired parts of the page while also allowing quick skipping of unwanted content. With this type of navigation, it is important to utilize the available native HTML5 elements with their semantic meaning while structuring the document instead of using <div> elements everywhere.

Regarding the chosen navigation technique, the screen reader user will rely on the information being provided by the content of the webpage to understand and use this content. Apart from the previously mentioned possibilities to provide understandable document structure, there are other smaller things that can be done to increase the accessibility of the content. For example, because screen reader users will go through each paragraph one after another and can skip one, it is good to place distinguished information of a paragraph in the first sentence. Additionally, screen reader users can also navigate by tables, lists, forms, etc.

Last but not least, the webpage developer can (and should) use ARIA attributes to attach additional metadata for various elements on the page. There are quite a lot of them, and they serve different purposes. The most common is aria-label, which directly attaches the text content to the element that should be used for this element description. For example, when you have an icon button (hamburger menu) it will not have natural text content available.

The second most often used attributes are combinations of id and aria-describedby, which together creates a relation where one element's content describes the other element. Another commonly used attribute, role, makes it possible to specify for the screen reader the functional purpose of that element. There is also one common but yet special attribute, aria-hidden, which instead of adding information to the screen reader, removes it and all its children in the HTML tree. This serves the purpose of hiding elements that do not provide valuable information.

Testing accessibility support using a screen reader

There is a lot of knowledge to be learned when it comes to building accessible applications and webpages. There is also a ton of experience to be gained just trying to do everything right. To help yourself with making sure that your webpage or application is properly accessible, it is really useful to utilize the screen reader in the workflow. The same way as we test our code locally on different devices and web browsers in order to verify if the content is laid out properly and if it works functionally, we could and should verify if it is accessible.

Of course, screen readers are not automated tools for detecting accessibility issues, but by learning how to use them, especially with the application you’re working on, it is an insightful experience. This experience allows us to interact with created applications or documents in different, but very important ways, by listening to the content being read. And because we’re listening to the content, it is easier to catch potential issues with navigation order, meaningful descriptions of images, verbosity level of the interface, and more. Thanks to free-to-use solutions like open-sourced NVDA for Microsoft Windows and the natively supported VoiceOver for macOS, it is possible to just start using it without the need for any investments.

An interesting outcome of testing applications with screen readers is that they can provide feedback as to the overall application design, which can improve the accessibility of the page for all kinds of visual disabilities or even increase the ease of use for sighted users.

Wrap-up

One part of making applications accessible is allowing the users to interact with them easily through screen reader software. This software is a fundamental player when it comes to possible user inputs and should be treated on a par with pointer or touch interactions. We, as responsible developers, need to treat the accessibility of our applications the same way we treat the visual attractiveness and usefulness of the graphical user interfaces we build. The amount of possibilities in terms of different navigation techniques in screen readers can be intimidating, but it is only a matter of practice to feel more comfortable using it. If you ever feel lost you can easily check the guidelines, like the ones for NVDA or VoiceOver.

Keyboard navigation

Oliwia Połeć — Mon, 28 Jun 2021 12:20:51 +0000

It should be possible to control any desktop application using just a keyboard. There are certain keys and key combinations that are de facto standard for most applications, and users should be able to expect them to work.

This is a vastly important topic from the accessibility point of view. For a large group of people, a keyboard might be one of the primary ways of interacting with a computer. Pointer devices, while being commonly used by most, just don't work at all for people with visual disabilities, for example.

It's a humane thing to design and put work into implementing an application with these concerns in mind. For example, all interactive elements should be reachable using the keyboard alone, and the navigation should happen in a logical sequence. In addition to that, a visual affordance such as a focus ring should always be available for sighted (or partially sighted) users.

In fact, this is a very important thing, and not only for people with disabilities. It's often crucial when it comes to supporting power users of your application. Using a keyboard can be much more effective than a mouse in some cases. However, it usually requires some manual skills and muscle memory to become really effective at this.

Even if you are not a power user, you probably do some simple tasks using just a keyboard. There are things that we have all internalized and take for granted, but probably we don't appreciate them very much. They already feel natural to us, and it would feel weird if we were to ever find ourselves in a situation where they didn’t work. Can you imagine a chat application which doesn't send a message when hitting the Enter key? Or which wouldn't allow you to change the cursor position using the arrow keys? I can't either. This is just something so simple that we all take for granted. I can't even imagine how it would be to rely on the keyboard heavily, for everything, and having to deal with a plethora of applications with varying support for proper keyboard navigation.

If those things don't work, the application in question doesn't work properly. It's not a matter of choice, priorities, or anything else. Luckily, people are becoming more and more aware of the subject of accessibility, and we can see a great uplift in concern about this.

Focus management

When using the keyboard to navigate an application, it's important to always display a focus indicator, most commonly known as a focus ring, on the currently active element. The browser’s built-in styles, which historically have not been compatible with many website designs, were a reason for developers to disable them altogether. This is a serious accessibility concern; such actions should never be taken unconditionally. To accommodate the design of a site, a custom focus ring can be implemented that will be a better fit for the site.

It's OK to hide these visual cues when the user is using a pointer device to navigate the site, but they should be visible as soon as the user switches to keyboard navigation. Usually, this behavior can be implemented by using :focus-visible selector, but keep in mind that it’s not yet supported by all the browsers.

The topic of focus management is broader than just displaying a focus ring correctly, and for most patterns required for robust and correct keyboard navigation/focus management, a JavaScript-based solution is required.

tabindex

Let’s recap what a tabindex is and what its different values mean for the browser.

A value of 0 means that the element is focusable and participates in the tab sequence, whereas a value of -1 means that the element can be focused programmatically, but it doesn’t participate in the tab sequence.

Other numeric values can, technically, be used as well. Positive ones actually change the order of the tab sequence; so it’s possible to move an element to the front of that sequence by providing a value higher than all others. This is, however, discouraged by all experts, and a consensus has been reached in the community that this should never be used as it creates a mismatch between the tab sequence and the visual order.

Basis patterns

Tabbing

This is something that usually comes for free if we use proper HTML structure. When pressing the Tab key, the focus should be switched to the very next interactive element. When pressing Shift+Tab we should be switched to the previous element. When going forwards and backwards using those key combinations, we should cycle between the same elements. If we leave an element, we should be able to easily get back to it unless there is a strong reason why this shouldn't be possible (for example when the previous element was associated with some expirable content when the expiration would be properly announced to the user).

An important thing to remember is that all interactive elements should be reachable using a keyboard. So for example, if we have an element that appears when hovering over another element with a pointer device, then we should also display it when navigating using a keyboard.

Arrow navigation in menus

When it comes to navigation through menus, there are two options — one based on the aria-activedescendant attribute, and the other one based on tabindex manipulations. It's a matter of choice which one gets used. However, from the user experience perspective, both are equivalent — the up and down arrows can be used to go through the menu items, and Enter/Space keys can be used to select the currently active item (and thus also close the menu).

The first option is to leave the focus on the menu button (the element which triggers the menu to be opened) and only highlight visually the "active" list element by juggling the values of the aria-activedescendant attribute in such a way that it points to the highlighted menu item using the global ID value of that active menu item.

The alternative to that is to exclude all menu items (apart from the active one) and the menu button itself from the tab sequence by setting tabindex="-1" on them. The currently active menu item should have its tabindex set to 0. When navigating through menu items using arrows, the previous menu item should be excluded from the tab sequence and the next item should be included in it by properly manipulating the tabindex attribute. To actually move the focus to the next menu item, it is also required that its focus method be called.

Note that, usually, pressing Tab or Shift+Tab while navigating through a menu should bring the user to the next (or previous) element outside of the menu (and its menu button). When using the second way of implementing arrow navigation, it might be required to bring back tabindex="0" on the menu button so it can be navigated back to.

Closing with Escape

When any element pops out to the user — be it a menu, tooltip, modal, or an emoji picker — then it should be closeable by pressing Escape. There are cases when it is permitted to not implement this pattern — for example, when an opened modal can't be reopened again, but not implementing this interaction should be a conscious design decision.

To implement this it is often required to add a global keydown listener on the document element. The listener should check if the Escape key has been pressed, and if yes, then it should close the open element in response to that.

If you are dealing with nested modals (or a tooltip within a modal, or any other cases that introduce this kind of nesting), then you should ensure that only the element that is open on the very top should be closed with a single Escape key. It would provide a bad user experience if, for example, both modals were to be closed at the same time.

Item activation

This is an easy one — most activatable elements should be activated by pressing Enter or Space. It's easy to forget one or the other when implementing custom buttons (which is sometimes the only way to satisfy the design/layout constraints) or when implementing custom input controls like checkboxes.

Advanced patterns

Focus trapping

In a variety of scenarios, it is desirable to lock user navigation to a certain element. When pressing Tab on the very last interactive element within it, focus should be moved to the very first element in the enclosed group. This most commonly happens when a modal gets displayed to the user. In such a situation the background usually gets dimmed in one way or another; so it doesn't make sense to allow the user to navigate to any element outside the modal. They wouldn't see the active element then, or the modal would have to be closed.

There is no HTML way to achieve this behavior, and a JavaScript-based solution is required to implement it. The idea behind popular solutions is to render additional sentinel elements (for example, empty spans) before and after the locked element. They can either be made focusable so, whenever they receive focus, the focus can be moved programmatically to the appropriate element within the trapped element, or the default action of pressing the Tab can be prevented, and the focus can be moved programmatically to the appropriate element.

Auto focus & focus restoration

This pattern is important for most situations in which a new element that contains navigable elements gets opened in response to the user interaction or when an automatically opened element (like a modal) is meant to interrupt the user.

Whenever we deal with such a situation, we need to move focus to the element that just got opened. Very often, the new element gets actually rendered to the body; so it isn't near the current navigation sequence anyway. If the element got opened in response to a user interaction, then it is a signal from the user that they want to interact with that element; so focus should not stay on the triggering element. By querying the DOM of the opened element, the focus should be placed on the first tabbable element in it, unless there is no such element, then the opened element itself should be focused.

In a similar vein, it's desired that the focus should return to the triggering element when the opened element gets closed. It just makes the most sense as that's the last thing the user remembers. It brings the user to the same context that they previously left.

Grid pattern

While the pattern is very useful for handling tabular content (like spreadsheets), it's not limited to those kinds of use cases. Actually, it can be used purely to create a sort of navigation depth.

The idea is that the particular container should only make a single element within it focusable, so only that single element acts as a stopgap when tabbing through an application. To navigate to other elements (cells within a grid), arrow keys can be used. This requires the application to have strict layout constraints since the direction of the pressed arrow key should always move focus to the other cell in that direction, and this should always match the visual layout. It would be confusing for the user if pressing a down arrow were to move focus to the element displayed on the right, or things like that.

This pattern is great for very long lists of repetitive elements, like, for example, a list of messages in a chat application. Without using it, the user would have to tab through the whole content of the chat (which grows with time) to get to the elements above or below that chat feed.

In addition to that, certain cells can have interactive elements within them — a rich message card with interactive buttons can be a grid cell. One can enter such a grid cell by activating it using standard Enter/Space keys. While in the grid cell, the focus should be trapped within it; so pressing Tab repeatedly would not navigate the user to any element outside of this card, and to get back to the main grid navigation, one would press Escape. As you can see in this example, this combines many of the previously mentioned patterns to provide a very rich user experience.

It’s worth noting that the last active element in the grid stays focusable when one tabs away from the grid. This makes coming back to the grid a better experience since the user is brought back to a familiar context.

Summary

As we can see, implementing some of these patterns is quite involved. To do it right, we need to both understand the accessibility requirements and implement several JavaScript-based solutions that often require beyond-novice knowledge of the browser APIs. Doing that in a generic fashion for reusable components that can be rendered in a variety of scenarios is very hard.

Luckily, there are packages that can help you with that, and we highly encourage using them. However, when combining several patterns like this for a single element, you might encounter some interoperability issues between packages. Our widget is implemented using React, and we have discovered that React Aria is a great project, focused on providing developers with a proper base for these and many more accessibility-oriented patterns while allowing developers to provide their own UI and styling solutions.

How we made the chat widget accessible for people with visual impairments

Oliwia Połeć — Thu, 24 Jun 2021 12:48:58 +0000

Matching colors to achieve the minimum WCAG contrast score might be perceived as a simple task. After all, there are plenty of free tools available — from websites like colourcontrast to design tool plugins for Figma or Sketch — that can help you calculate the proper color contrast for your designs. In our case the challenge was to solve contrast problems when colors can be customized by the users. In this article we want to share what we have learned and how we build accessible color palettes.

Where to start?

Start by doing an audit using Google Lighthouse, or you can find a tool that will fit your needs in this article. Gathering together issues related to low color contrast and grouping them into those which can be fixed quickly and those which will require special solutions was very helpful and speeded up the whole process. The low-hanging fruit was fixing the contrast between elements that don't inherit a primary color and also fixing the contrast between surfaces.

They were easy to resolve because we decided that some components will always have a set of fixed color values, and thanks to that we can easily predict the contrast in relation to the different surfaces. By doing an audit and refining each element individually, we recreated our new grayscale palette.

Do an audit using specialized tools, and group issues based on their level of difficulty.

Performance over Preference

Take a look at these two buttons:

Which one is more appealing to you?

I assume that the button on the left might look more appealing to most respondents; however, working with accessibility in mind is not a matter of preferences — it’s simply down to performance. If I want to measure the button's performance, my question should be: Do you have a problem reading any of those buttons? Then filter out everyone who can read both and focus only on people who have a hard time reading any of the buttons. There is a thin line in matching colors for the button such that they fulfill WCAG guidelines and the button still looks the way most people expect to see it. Those expectations of specific color combinations might exist because people just get used to them, but changing the combinations to have a contrast score of at least 4:5:1 won't bother anyone that much, and it might help others to better perceive the interface. Our eyes and vision change over time, just like the rest of our bodies. Some people experience age-related vision changes that interfere with their ability to see clearly for reading and other close vision tasks. We don't know what the exact demographic of chat widget end-users is. However, the chats' scale is approximately 1.5 million per day; so there was a risk that a significant number of users might have problems when interacting with the LiveChat Widget.

It's important not to rely solely on the WCAG math for calculating contrast. You can strive for the best score and readability by tweaking colors, but at the end of the day, testing it with real users or doing the accredited accessibility audit is a must.

Eliminate your personal bias on preferred color combinations and remember that you are designing it for ALL users.

Framer + polished.js to the rescue

Nowadays, design tools offer several ways to solve inaccessible color problems. You can install a plugin to your favorite design tool and test many color combinations one by one. However, it might be a time-consuming task, especially if you provide color customization in your app, so why not automate this process? Framer, a tool that combines both code and design, was a lifesaver when designing elements that inherit primary colors. The tool allows you to use mechanisms that function in the actual code environment. We've used one of those available mechanisms, from the polished.js package. Thanks to this package, we could test for accessible colors on many components simultaneously.

You can see how the components and the contrast score changes when tweaking the primary color. It speeds up the whole process dramatically. The cool thing is that we have also implemented this package inside the Chat Widget code, so the design and production are based on the same environment. The important thing is that when the user customizes the primary color of the widget, the system relies on the polished.js mechanism. This matches whichever text or icon color (black or white) scores the highest. Because of this, users might even get black text on a blue button if white text would only achieve a minimum 4:5:1 contrast ratio for that particular blue background. The way we measure combination contrast is not perfect, because the WCAG guidelines, as the name suggests, are just recommendations, and I believe that the proper math for color calculation that mirrors human perception is yet to be invented. Still, we think it’s better to have this automation than always having white be the foreground to a primary color.

Do accessible colors have to be ugly?

Statements about ugly accessible colors might be a consequence of the high contrast modes you may have seen over time on various websites.

It's easy to make a false assumption about accessible colors if you're just starting with the topic and you've seen too many of those websites. Another thing is that perceiving color is a subjective matter. When we think about the color being beautiful, it only exists in our heads as a pleasant feeling. However, a fairly useful method would be to observe the most popular colors on the web. I think that for the sake of argument, we can call popular colors appealing. After all, they are popular for a reason. Gather and refine those colors by increasing or decreasing their lightness so they will have a minimum 4:5:1 foreground to background contrast ratio. For example, if you want to fix an inaccessible color, decide whether you want to darken the background and lighten the foreground or do the opposite — lighten the background and darken the foreground. Both ways are good; use whatever works for your design to achieve a good contrast score.

We have decided to make the theme colors slightly darker so that all our predefined theme colors work well as a background to a white foreground. We didn't want to include colors with high luminance, like yellow or orange, in a predefined set of colors because combining them with white surfaces results in low contrast. Users still have a choice if none of those five colors meet their expectations. They can pick whatever color they want as a primary color, and we will adjust the text color on the messages and buttons. Achieving the proper text color is done automatically by the polished.js library. In short, whatever color you pick, polished will match the text color, white or black, depending on which combination contrast score is the highest.

Two problems at once

Working on accessible colors in LiveChat Widget was an excellent opportunity to tidy up the code and create a single source of truth for design tokens. The term “design tokens” refers to properties like colors, font sizes, spacings, and even transitions. The main premise of having organized design tokens, especially colors, is to maintain consistency within the application. Synchronizing colors between design and code will also help you keep the product palette accessible (automated checks) and predictable; so if you have the opportunity to do that, go for it!

Pay attention to :focus

You are probably familiar with that blue border that appears from time to time when you scroll through websites. Those elements are called focus indicators. Some people don't like that browsers add them by default to components like inputs or buttons because it interferes with their website/app design, so they remove them in the CSS. If you want to build an inclusive product, you should not use { outline: none; } on focusable elements globally for the whole website or app. Instead of deleting the outline completely, you can show a focus indicator that originates from keyboard interaction but that is not present with pointer device interaction. Also, make sure that the color you use for the focus indicator properly contrasts with the backgrounds. It is also good to add a small gap between the focused element and the component using the { outline-offset } property for better visibility.

Wrap-up

You may be overwhelmed by the number of color issues the audit can reveal; but don’t worry, very often the same color relations are repeated across the app. Like in any other case, planning is very important. Break down all issues into groups and categorize them based on similarity and difficulty. Choose your tools when it comes to design, development, and testing. There are plenty of tools and libraries which can speed up the whole process.

Key takeaways:

Start with an audit
Eliminate personal bias toward preferred colors
Don’t rely solely on the WCAG math for contrast calculations. Test the combinations with real users
Accessible color palettes can be appealing
Working on accessible colors is an opportunity to tidy up your design system
Create a proper focus indicator and show it when needed

Introducing and testing accessibility in the LiveChat Chat Widget

Oliwia Połeć — Tue, 22 Jun 2021 12:51:14 +0000

For the last few months, we’ve been working on making our LiveChat Chat Widget accessible and ensuring it meets the WCAG requirements. We had to get acquainted with success criteria, translate them into specific technical tasks, then validate our solutions and introduce corrections.

The whole project was very challenging, especially choosing between conflicting interpretations of the requirements and match. We repeatedly had to clarify a specification to match specific parts of the application that did not match the available examples. We want to share the knowledge gained during the project and explore how we adapted the LiveChat Chat Widget application to WCAG 2.1 level AA requirements. We decided to create a series of posts about the most complex technical aspects of making web applications accessible.

Web Content Accessibility Guidelines

As mentioned before, the LiveChat Chat Widget meets WCAG 2.1 requirements. What does this mean exactly? Web Content Accessibility Guidelines (WCAG) is a standard for web content accessibility provided by the World Wide Web Consortium (W3C). WCAG defines testable success criteria grouped into three conformance levels: A, AA, and AAA (the best). However, level AAA is usually not required for the entire content of a webpage because it is impossible to meet its success criteria for some parts of the content.

Sample success criterion: text contrast. Level AA requires that the text must have at least a 4.5:1 contrast ratio in most cases, but level AAA requires a 7:1 contrast ratio.

WCAG comes with an easy-to-navigate, detailed reference guide, along with techniques documented with examples, code, and descriptions of test procedures.

Another important document is Aria Practices, which provides developers with practical examples of how to implement specific solutions so that they are accessible to people with limitations.

Why we should care about accessibility

We understand accessibility as enabling people with limited abilities to use a website or web application. Taking care of accessibility should be done from the very beginning of every project — there are several reasons for this.

According to the WHO’s "World report on disability" from 2011, 15% of the global population live with some form of disability. That translates to a massive number of visitors that benefit from improvements in this area. 2.2 billion people have a near or distance vision impairment. The issue of accessibility is often seen as a problem that affects only a negligible minority. We pay very little attention to these problems, and actions to improve the situation have been disproportionate to the actual scale of the problem.
Taking care of website accessibility brings profit to every user. Meeting color requirements is essential for people with severe vision impairments, but it's also helpful for those with impairments classified as "moderate" or "mild." Valid document semantic structure is useful for every tool that needs to better understand the content of your website. It can improve multiple other aspects, like SEO. Alternative image descriptions can be applicable in the case of bad network conditions or failure.
Many countries require a particular category of institutions to ensure website accessibility. In the USA, such requirements for public institutions and those cooperating with them are imposed by the American Disability Act (ADA). In the case of the European Union, similar requirements are imposed by the Web Accessibility Directive. The requirements of these documents are often specified at the level of state law in the United States or the countries of the European Union.
Taking care of accessibility should be part of caring for a responsible brand image.

In the case of LiveChat, in the document "The LiveChat Software Living Constitution" we have a clearly defined vision: "Customer communication without barriers." Such a vision means that we have to treat accessibility as the most important topic we should be dealing with.

Work areas

When thinking about people with limitations, we should take into account the needs of people with visual, hearing, mobility, and cognitive impairments. In the case of our application, the most demanding tasks can be grouped into three areas:

Keyboard navigation

Making sure that the app interface can be fully used without the need for additional input devices like a mouse or trackpad. The user should know which item is currently focused; keyboard navigation should be logical and comfortable.

Screen readers

Content should have correct semantic structure; interactive elements should have proper aria tags, and all state changes should be announced to the user. Meaningful non-text content should have an alternative text description. This enables screen readers to work correctly with your website, together with other accessibility tools, for example, Voice Control on devices with iOS systems.

Visuals

Colors should meet minimum contrast requirements and shouldn't be used as the only way to indicate app status.

Summary

We'll cover each of these areas in detail in the following posts. Behind each of these points, there are many additional needs. In our posts, we will focus on the problems and requirements of the Chat Widget application; it is not a complete guide for any type of application.

Besides this, we will describe how to start the process of customizing already running projects: how to test the compliance level of an application and how to use test automation to avoid regression in this area.

We hope these articles will help developers and designers look closely at the topic of accessible web applications and provide practical tips. Unfortunately, despite the dynamic development of browsers, standards, and technologies, a lot of work in the area of accessibility still requires manual implementation. Commonly used interface elements, such as modal pop-ups, have well-defined requirements for keyboard navigation. Unfortunately, browsers do not provide built-in mechanisms for them. Had the native focus-visible pseudo-selector support been released earlier, we might have prevented the practice of disabling outline from being popularized for active elements. On the other hand, developers have more and more tools to test the accessibility of their websites, like the Emulate vision deficiencies in Chrome DevTools, the Accessibility tab in the Firefox devtools and the Axe browser extension.

Our journey with accessibility testing

The past few months have been quite busy for our team. In LiveChat, we’re responsible for building the Chat Widget, one of the core components of our system that is used by end-users to communicate with support agents. As described here and in our constitution, one of our core values is to make "customer communication without barriers." For us, communication without barriers meant that we needed to put more focus on accessibility, so we made adjustments to the Chat Widget in order to meet WCAG requirements.

What does that even mean?

“Being accessible” means providing a person with disabilities a way to use a product. It applies to different areas of everyday life. For example, consider stairs People using wheelchairs cannot use stairs, so an owner of the building has to provide an elevator. The same is for the web - different people use our Chat Widget, some of whom might be blind, deaf, or have different kinds of vision impairments. Just as the owner of the aforementioned building had to make accommodations, we should provide our customers with alternative ways of using our product. If that’s not convincing enough, maybe you should keep in mind that building an inaccessible website might even end with a lawsuit!

So, what are those alternatives? Well, it depends on the disability being accommodated. Sometimes we need to avoid some patterns. For example, we shouldn’t make elements of our UI reachable only with a mouse, as some users might explicitly depend on keyboard navigation. On some occasions, it is about not using colors that might be indistinguishable for people with color blindness. Fortunately, we don’t have to spend a lifetime researching the topic before jumping into action. Web Content Accessibility Guidelines (WCAG) is the saviour here. It is a document published by the Web Accessibility Initiative that establishes a set of recommendations to follow to make websites more accessible.

Low-hanging fruit

When we first started working on accessibility, it was a bit overwhelming. We had an already working application with thousands of customers, and accessibility was a completely new thing for us. Our initial question was not “how,” but actually “what” to start with? Before making any plans, our first task was to research how to test the web applications with accessibility in mind, and then to fix any flaws in our Chat Widget.

We began with static analysis tools. These tools analyze the semantic structure of the HTML DOM tree in order to be able to find some downsides. A great example of such a tool is “axe DevTools” browser extension or a similar WAVE one. You use it to scan either all of your webpage, or it’s particular elements, after which you will get the report listing all found issues.

These checks are based on the WCAG requirements mentioned above, and include the severity of each issue.

Other tools which you can use for such an analysis, if you are using Chrome or Firefox, are built in your browsers. In Chrome, you are able to run a similar automatic report using Lighthouse. Although it is certainly less specific, it is a good start.

The same is true for Firefox - when you open the developer tools, all you need to do is go to the “Accessibility” tab and select “Check for issues" with the option you favor. This will provide yet another report with all the information you need in order to start making the world a better place.

Both of these browsers also provide additional information about the color contrasts, missing attributes, element semantics, and other important things.

With all that sorted, use your imagination!

From the reported issues we created tasks to improve particular components, and we have gained a lot of insight into what to look for. Though it was a quick round of running the audits around different application states, we knew it was just the beginning. We have found that we can keep track of issues using different automated solutions during early phases, such as eslint rules (e.g. “eslint-plugin-jsx-a11y”) or cypress plugin (“cypress-axe”). That is a topic for another blogpost, though!

The second, much more important thing we knew we had to do was to make use of our empathy. We already learned which things we should pay attention to, soit was now time to check the user experience. When manually testing user experience of the accommodations, it’s probably preferable to categorize and test different disabilities independently instead of trying to test everything at once.

For example, we had to learn how the blind use the web. The answer is pretty simple - they use screen-readers and navigate around using just the keyboard. There are a variety of screen readers to use, some of which might be already in your system, such as VoiceOver, which is on MacOS. If that’s not the case, you can consider free browser extensions like ChromeVox.

In Warsaw, there is an exhibition called “Invisible Exhibition.” It’s an interactive tour “into the world of darkness,” and is meant to show visitors how the blind or visually impaired navigate around the world. For web browsing we basically did the same, and we were able to recreate the experience of using our widget as a blind or visually impaired person would in order to check it.

Imagine you are using the web without being able to “see;” you can only “hear.” Imagination can be tricky here, so you can try it blindfolded or with your eyes closed. We are used to certain patterns which are not at all accessible, and blindfolding yourself helps you to understand how wed we are to those patterns. For us, it was a game-changer. For starters, we made a run for critical and basic paths of our application, like:

Find the Chat Widget on the page.
Open it, fill in the pre-chat, and start a chat.
Chat with the Agent - are you able to “read” (hear?) their message? Are you able to answer or ask any questions?
Close the chat.

It seems pretty easy now, but it turned out that it was almost impossible at the very beginning of our journey with accessibility. We weren’t even able to find our widget on the page, so new messages from the Agent were not being read, and the user was unable to navigate through them. We had to learn how to use the keyboard, how content is being read, and which bits and pieces are viable.

This gave us more insights than any static analysis would to and made us actually realize how important it is to improve that situation. The same is for other disabilities, like color blindness. You can use various tools to simulate such a condition, learn, and then make your app better with all that knowledge.

Design with a11y in mind

The experience of using our Chat Widget in the way a disabled person might made us realize how important it is to consider accessibility at a very early stage. We believe in the “test early, test often” approach, and as mentioned earlier, we have included automatic tools in our pipeline to ensure there is no regression around particular areas. But, before development, there is a design.

As part of the changes we adopted, we had to completely rebuild some of our components, such as the file upload. Now it provides a way to add an “aria-label” to the uploaded images, explicitly informs users about the status of the upload, and makes all content easily reachable with the keyboard. The earlier version was not accessible at all with a keyboard, not to mention that it gave only the visual representation of upload status.

We have read a lot of blogs and specifications, learnt from our experiences, as well as from books like “Inclusive Components.” All of these made us realize what we needed, and now every new feature we design and plan to implement is done with accessibility in mind.

Learn from the professionals

Last but not least, there are companies like Deque which can help you with assessment and testing. They built the “axe DevTools”! They run training sessions, provide access to different testing tools, and perform audits and accessibility assessments. Their audits are based on their extensive knowledge in the area and will help you to determine which issues to address. The specifications and requirements can sometimes be confusing, and it might be quite hard to apply them or test them with your application. This is the part when even a simple chat with a professional in that area might be helpful.

You can also use the solutions already made by professionals, such as adobe/react-spectrum. There is a lot of useful knowledge there, as well as tips on what to look for while testing.

Remember accessibility!

Although often overlooked, the accessibility of your product is of the highest importance. There are a variety of tools to help you determine where you can improve, and it’s impossible to find an excuse why you shouldn’t. I hope that our journey will encourage you to care about all of your visitors and unleash the full potential of your product.

After the live coding about web app authorization

Oliwia Połeć — Thu, 01 Apr 2021 06:30:14 +0000

As you may know, we recently organized a live coding event together with the LiveChat Developer Program team, where we taught web app authorization with our API. During the session, we also covered sending rich messages in the chat, as well as Accounts SDK. To get more details, here's a link where you can find the event announcement.

If you missed the live coding by any chance, we got you covered. Maybe you even enjoyed the session so much you wish to rewatch it? You can find a video recording of the whole event right below 👇

If you like this video and want to participate in the future sessions we organize, join our Discord server and be up to date with LiveChat Platform news. You can also let us know if there are any LiveChat API topics you’d want us to cover in the future! We are reachable via email at developers@livechat.com or on the Discord server.