Nowadays, the Internet has become a medium for our daily affairs, such as contacting a government agency or using public service, settling taxes or ordering new identity cards. The quality and quantity of services delivered have been constantly growing. The presence on the Internet has become a must for modern companies. The Web gives them access to a broad audience and the possibility of competing in different markets.
While introducing new products, we must solve a lot of functional and non-functional issues. One of them is to create UI/UX which will guide and support users in effective website navigation. This might be particularly difficult if you want to make your website accessible for people with disabilities. If the websites are designed and coded correctly, they are accessible for various types of users, including those with sight impairment or complete blindness. In such cases, accessibility guidelines and rules might come in handy.
Accessibility is the practice of building products or web services for as many users as possible, regardless of their limitations. This concept refers not only to computer interfaces but to any devices which interacts with humans. The main enabler making websites accessible is the W3C Web Accessibility Initiative (WAI), an initiative which develops technical specifications and guidelines for programmers and designers. The multitude of disabilities are covered by three leading documents. The most important of them is the WCAG, created by the World Wide Web Consortium. The other two are Section 508 and ADA, which are essential only in the US. In the United States, Section 508 is a federal law and the ADA is a civil rights law that prohibit discrimination of people with disabilities. Almost every EU member state has adopted legal web system requirements which define accessibility
WCAG 2.0
WCAG 2.0 is a compilation of accessibility guidelines for websites developed by the W3C and a leading standard accepted internationally for web accessibility. These set of recommendations for the user interface to make it more accessible for people with disabilities. Compliance is voluntary.
Since June 5th, 2018, WCAG 2.1 has been valid as an extension of 2.0. WCAG 2.1 mainly focuses on improving accessibility for three major groups: “users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices.”
Level A is easily adaptable to any page without impact on its design or structure. Level AA and AAA require a bit more work to fulfill. AAA is hard to achieve, e.g. one of the rules requires to use only very dark colors mixed with very light colors to achieve at least a 7:1 contrast ratio. The most common solution to accomplish it when our color palette has limited possibility is to add a button to change from “normal” to high contrast palette only. Fortunately, we don’t have to meet the requirement most of the time. It is intended for very special websites. However, AA level is preferable and legally required for some public services. Usually, we adopt a subset from Level AAA to improve the target group efficiency.
Business advantages of accessibility service
Following accessibility guidelines bring several advantages for people and business alike.
From the business perspective, when applied, accessibility principles affect not only people with challenges but also increase all users experience in unfavorable conditions like:
- bright sunlight
- small screens on mobile phones, tablets, etc.
- slow internet connection or limited/expensive bandwidth
Enhanced accessibility makes websites more inclusive.
Accessibility overlaps with other best practices, such as mobile web design, device independence, multi-modal interaction, usability, design for older users, and search engine optimization (SEO). Case studies show that accessible websites have better search results, reduced maintenance costs, and increased audience reach, among other benefits. Developing a Web Accessibility Business Case for your organization highlights benefits of web accessibility.
- Increasing the website sales range by providing real access for people with disabilities.
- Building internal systems of enterprises to create jobs for people with disabilities.
- Fighting against social exclusion (e.g., as part of organizations CSR).
- Opening up for cooperation with the public sector cooperation offers.
When it comes to points 1 and 3, ask yourself how often you can find websites outside the public domain, which intentionally integrate high accessibility solutions. Another question worth considering is how often you try to implement or take these issues into account during product development or designing. Although people with disabilities are present on the Web, we often skip the target group when we analyze our solutions. Why should you contribute to the deepening of social exclusion for this group? Good practices and rules may attract new users to our services and open new markets, e.g. public domains. This is a broad market with growing needs for digitalization and shift more processes to the Web.
You should not be too much concerned about the cost. In many countries, public subsidies are offered to create jobs for people with disabilities. Expenditure necessary for build and certify a solution can be counterbalanced by obtaining job-related subsidies. In Poland, for instance, PFRON, or the Disability Fund, partially subsidizes salaries for people with disabilities.
Risks in the development process
Our company already has a few successfully implemented enterprise-level solutions that support employment of people who are blind or with vision impairment. Our projects have focused on making web services available for this particular group, especially the complete integration of the JAWS assistive software. The User Interface (UI) design itself has been developed to support readability.
Colors used also respond to a wide range of color vision dysfunctions. Thus, people with such an impairment can handle websites created without barriers and difficulties. We have identified a few challenges to planning and implementation during website development. Now, we can share a few tips to help you to avoid the same pitfalls:
- Contrast and colors related issues should be identified at the design stage. These are often obvious for everyone but may be a real drag for people with dysfunctions. For example, errors are most often marked by a shade of red, and we’ve had a few problems with the rich contrast specification.
- The signaling of asynchronous errors by the application shall be designed in the way that can be properly recognized by assistive systems.
- The third party components shall be verified before introduced to the project. Their verification should cover accessibility compliance, components extension, and license requirements. Although many free components offer basic accessibility, adapting them to the required level may often be time-consuming or even impossible due to license limitations.
- One of the problematic components happened to be a table. Most assistive systems help users efficiently deal with data tables. However, while some of popular table components are recognized as a list, selecting the right one in the early phase of the project can save much effort.
- When deciding on the technology, we choose those that offer a possibility to modify the website structure. Let’s assume we use a framework with an HTML generator with a fix set of components. In that case, we may come across a problem where assistive systems do not recognize elements in the way we would like them to do. It can be a challenge to solve the issue because the generator itself is not part of our codebase but it belongs to the library/framework codebase. We can only go as far as the API lets us.
- Accessibility requirements should be introduced to the system as early as possible and considered at every stage of design and development. This approach makes the adaptation of elements easier and faster. A team familiar with basic techniques may even not experience a drop in performance. However, the introduction of accessibility rules at a later phase of a project may require us to replace already prepared components. This might delay the project and increase its overall cost.
How to provide accessibility rules to your website ?
Most people with disabilities use assistive systems to interact with the computer and the service itself. To help them using the application involves two main steps:
- Using of WAI-ARIA HTML tags to inform assistive systems how to navigate through the website and identify used components
- Proper designing of the color palette used on the website to maintain a good balance between the client’s design guide and requirements corresponding to different vision impairments.
WAI-ARIA – HTML tags
WAI-ARIA is a framework for adding attributes to the HTML code that helps assistive systems to properly interpret, display the website and make interaction accessible for people with disabilities. Most of assistive systems don’t have any problem with interpreting semantics. Nowadays, we often create our own components and change behavior using JavaScript, as well as alter it by the CSS. It might turn to be a hindrance, since we cannot be sure that the assistive system has correctly identified components and interact with them. In this case, the WAI-ARIA specification and framework come in handy. This gives us the possibility to add special tags to HTML to describe our components. HTML tags like ‘<header>‘, ‘<footer>‘, ‘<menu>‘, ‘<button>‘ etc.
The main features of WAI-ARIA tags include:
* Widget roles: helps to identify the type of a component, e.g. menu, dialog, list, list-item
* Structure roles: helps to identify parts of websites, such as headings, regions, and tables.
* Properties:
to describe state of certain components, e.g. checked, hidden, invalid, disabled
to mark parts of websites which need to be frequently refreshed, e.g. live charts or critical messages, like alert dialogs.
* Keyboard navigation: to define how pressing a key interacts with your application and which features a key is able to call
A short example of using WAI-ARIA property is shown below:
<div role="button" aria-pressed="false">
Button
</div>
While using WAI-ARIA tags, we should remember that assistive systems have basic mechanisms to detect site components and make them accessible for users. When we introduce our own tags, we disturb default detection mechanisms, so instead, we should carefully use them according W3C guidelines. We should always make sure that websites are well understood by assistive systems and prevent any disruption to already working non-visual experiences.
Color wheel tools
While designing a convenient user interface to be used by people with various dysfunctions, we should carefully select colors. Taking into consideration that sight impairments change the perception of colors, we need to make sure that we properly take it into consideration.
We can recommend two quite efficient tools which can do the job. Both tools generate a preview of how people with disabilities see a given color or a mixture of text and background. This provides an invaluable feedback for the UX/UI designer.
https://www.giacomo.page/en/colorwheel/wheel.php
https://color.adobe.com/create/color-accessibility
How can you test the compliance with accessibility rules at your website?
WCAG 2.0 automatic test pages
There are a few systems on the market which help to validate the website compliance with WCAG rules. One of the easiest and comprehensive solutions is WAVE.
WAVE is a suite of evaluation tools that help to identify errors in the website design and development. It shows WCAG errors and non-visual parts of the website tested.
While writing this article, we have decided to test, against accessibility rules, our Codelab business page which was not considered to be prepared for accessibility. Using manual and automatic tests (WAVE), we have identified several issues which impede web navigation for people with disabilities. Some of the main issues identified are as follows: missing or incorrect keyboard navigation, alternative text image, many incorrect aria tags, as well as a couple of empty elements that were delivered from an external third party. All these issues have been fixed at the time when the article was published. Besides, we have added descriptions for website regions so that it can be well interpreted by screen readers like JAWS® and make navigation on the website easier for people with visual impairments.
Such tools provide users with a clear list of detected issues and detailed information of each problem, its importance, and improvements recommended.
Contrast Accessibility Validator
An important tool in the WAVE suite is the Contrast Accessibility Validator. It checks if the contrast was sufficient to make the service convenient for people with such disorders as deuteranopia, protanopia, and tritanopia. The in-built contrast checker helps WAVE to indicate various issues and shows problematic areas of our website:
We also have experience with Enterprise applications used by people with disabilities. These products have been developed with much attention to barrier-free operation, and they always pass external accessibility audits without any significant problems. Our client portfolio includes a couple of projects for one of the largest telecom providers in Europe. We have already delivered a few applications for their agents in contact centers which are used to contact clients through different communication mediums, like SMS, chat, email, etc. Furthermore, we successfully continue working on new topics and we’d love to discuss it. And since we want to know about challenges you face with your application or availability issues in your projects, feel free to contact us.
