Nowadays, the Inter­net has become a medi­um for our daily affairs, such as con­tact­ing a gov­ern­ment agency or using pub­lic ser­vice, set­tling taxes or order­ing new iden­tity cards. The qual­ity and quant­ity of ser­vices delivered have been con­stantly grow­ing. The pres­ence on the Inter­net has become a must for mod­ern com­pan­ies. The Web gives them access to a broad audi­ence and the pos­sib­il­ity of com­pet­ing in dif­fer­ent markets.

While intro­du­cing new products, we must solve a lot of func­tion­al and non-func­tion­al issues. One of them is to cre­ate UI/UX which will guide and sup­port users in effect­ive web­site nav­ig­a­tion. This might be par­tic­u­larly dif­fi­cult if you want to make your web­site access­ible for people with dis­ab­il­it­ies. If the web­sites are designed and coded cor­rectly, they are access­ible for vari­ous types of users, includ­ing those with sight impair­ment or com­plete blind­ness. In such cases, access­ib­il­ity guidelines and rules might come in handy. 

Access­ib­il­ity is the prac­tice of build­ing products or web ser­vices for as many users as pos­sible, regard­less of their lim­it­a­tions. This concept refers not only to com­puter inter­faces but to any devices which inter­acts with humans. The main ena­bler mak­ing web­sites access­ible is the W3C Web Access­ib­il­ity Ini­ti­at­ive (WAI), an ini­ti­at­ive which devel­ops tech­nic­al spe­cific­a­tions and guidelines for pro­gram­mers and design­ers. The mul­ti­tude of dis­ab­il­it­ies are covered by three lead­ing doc­u­ments. The most import­ant of them is the WCAG, cre­ated by the World Wide Web Con­sor­ti­um. The oth­er two are Sec­tion 508 and ADA, which are essen­tial only in the US. In the United States, Sec­tion 508 is a fed­er­al law and the ADA is a civil rights law that pro­hib­it dis­crim­in­a­tion of people with dis­ab­il­it­ies. Almost every EU mem­ber state has adop­ted leg­al web sys­tem require­ments which define accessibility

WCAG 2.0

WCAG 2.0 is a com­pil­a­tion of access­ib­il­ity guidelines for web­sites developed by the W3C and a lead­ing stand­ard accep­ted inter­na­tion­ally for web access­ib­il­ity. These set of recom­mend­a­tions for the user inter­face to make it more access­ible for people with dis­ab­il­it­ies. Com­pli­ance is voluntary.

Since  June 5th,  2018, WCAG 2.1 has been val­id as an exten­sion of 2.0. WCAG 2.1 mainly focuses on improv­ing access­ib­il­ity for three major groups: “users with cog­nit­ive or learn­ing dis­ab­il­it­ies, users with low vis­ion, and users with dis­ab­il­it­ies on mobile devices.”

Level A is eas­ily adapt­able to any page without impact on its design or struc­ture. Level AA and AAA require a bit more work to ful­fill. AAA is hard to achieve, e.g. one of the rules requires to use only very dark col­ors mixed with very light col­ors to achieve at least a 7:1 con­trast ratio. The most com­mon solu­tion to accom­plish it when our col­or palette has lim­ited pos­sib­il­ity is to add a but­ton to change from “nor­mal” to high con­trast palette only. For­tu­nately, we don’t have to meet the require­ment most of the time. It is inten­ded for very spe­cial web­sites. How­ever, AA level is prefer­able and leg­ally required for some pub­lic ser­vices. Usu­ally, we adopt a sub­set from Level AAA to improve the tar­get group efficiency.

Busi­ness advant­ages of access­ib­il­ity service

Fol­low­ing access­ib­il­ity guidelines bring sev­er­al advant­ages for people and busi­ness alike.

From the busi­ness per­spect­ive, when applied, access­ib­il­ity prin­ciples affect not only people with chal­lenges but also increase all users exper­i­ence in unfa­vor­able con­di­tions like:

  • bright sun­light
  • small screens on mobile phones, tab­lets, etc.
  • slow inter­net con­nec­tion or limited/expensive bandwidth

Enhanced access­ib­il­ity makes web­sites more inclusive.

Access­ib­il­ity over­laps with oth­er best prac­tices, such as mobile web design, device inde­pend­ence, multi-mod­al inter­ac­tion, usab­il­ity, design for older users, and search engine optim­iz­a­tion (SEO). Case stud­ies show that access­ible web­sites have bet­ter search res­ults, reduced main­ten­ance costs, and increased audi­ence reach, among oth­er bene­fits. Devel­op­ing a Web Access­ib­il­ity Busi­ness Case for your organ­iz­a­tion high­lights bene­fits of web accessibility.

  1. Increas­ing the web­site sales range by provid­ing real access for people with disabilities.
  2. Build­ing intern­al sys­tems of enter­prises to cre­ate jobs for people with disabilities.
  3. Fight­ing against social exclu­sion (e.g., as part of organ­iz­a­tions CSR).
  4. Open­ing up for cooper­a­tion with the pub­lic sec­tor cooper­a­tion offers.

When it comes to points 1 and 3, ask your­self how often you can find web­sites out­side the pub­lic domain, which inten­tion­ally integ­rate high access­ib­il­ity solu­tions. Anoth­er ques­tion worth con­sid­er­ing is how often you try to imple­ment or take these issues into account dur­ing product devel­op­ment or design­ing. Although people with dis­ab­il­it­ies are present on the Web, we often skip the tar­get group when we ana­lyze our solu­tions. Why should you con­trib­ute to the deep­en­ing of social exclu­sion for this group? Good prac­tices and rules may attract new users to our ser­vices and open new mar­kets, e.g. pub­lic domains. This is a broad mar­ket with grow­ing needs for digit­al­iz­a­tion and shift more pro­cesses to the Web.

You should not be too much con­cerned about the cost. In many coun­tries, pub­lic sub­sidies are offered to cre­ate jobs for people with dis­ab­il­it­ies. Expendit­ure neces­sary for build and cer­ti­fy a solu­tion can be coun­ter­bal­anced by obtain­ing job-related sub­sidies. In Poland, for instance, PFRON, or the Dis­ab­il­ity Fund, par­tially sub­sid­izes salar­ies for people with disabilities.

Risks in the devel­op­ment process

Our com­pany already has a few suc­cess­fully imple­men­ted enter­prise-level solu­tions that sup­port employ­ment of people who are blind or with vis­ion impair­ment. Our pro­jects have focused on mak­ing web ser­vices avail­able for this par­tic­u­lar group, espe­cially the com­plete integ­ra­tion of the JAWS assist­ive soft­ware. The User Inter­face (UI) design itself has been developed to sup­port  readability.

Col­ors used also respond to a wide range of col­or vis­ion dys­func­tions. Thus, people with such an impair­ment can handle web­sites cre­ated without bar­ri­ers and dif­fi­culties. We have iden­ti­fied a few chal­lenges to plan­ning and imple­ment­a­tion dur­ing web­site devel­op­ment. Now, we can share a few tips to help you to avoid the same pitfalls:

  • Con­trast and col­ors related issues should be iden­ti­fied at the design stage. These are often obvi­ous for every­one but may be a real drag for people with dys­func­tions. For example, errors are most often marked by a shade of red, and we’ve had a few prob­lems with the rich con­trast specification.
  • The sig­nal­ing of asyn­chron­ous errors by the applic­a­tion shall be designed in the way that can be prop­erly recog­nized by assist­ive systems.
  • The third party com­pon­ents shall be veri­fied before intro­duced to the pro­ject. Their veri­fic­a­tion should cov­er access­ib­il­ity com­pli­ance, com­pon­ents exten­sion, and license require­ments. Although many free com­pon­ents offer basic access­ib­il­ity, adapt­ing them to the required level may often be time-con­sum­ing or even impossible due to license limitations.
  • One of the prob­lem­at­ic com­pon­ents happened to be a table. Most assist­ive sys­tems help users effi­ciently deal with data tables. How­ever, while some of pop­u­lar table com­pon­ents are recog­nized as a list, select­ing the right one in the early phase of the pro­ject can save much effort.
  • When decid­ing on the tech­no­logy, we choose those that offer a pos­sib­il­ity to modi­fy the web­site struc­ture. Let’s assume we use a frame­work with an HTML gen­er­at­or with a fix set of com­pon­ents. In that case, we may come across a prob­lem where assist­ive sys­tems do not recog­nize ele­ments in the way we would like them to do. It can be a chal­lenge to solve the issue because the gen­er­at­or itself is not part of our code­base but it belongs to the library/framework code­base. We can only go as far as the API lets us.
  • Access­ib­il­ity require­ments should be intro­duced to the sys­tem as early as pos­sible and con­sidered at every stage of design and devel­op­ment. This approach makes the adapt­a­tion of ele­ments easi­er and faster. A team famil­i­ar with basic tech­niques may even not exper­i­ence a drop in per­form­ance. How­ever, the intro­duc­tion of access­ib­il­ity rules at a later phase of a pro­ject may require us to replace already pre­pared com­pon­ents. This might delay the pro­ject and increase its over­all cost.

How to provide access­ib­il­ity rules to your website ?

Most people with dis­ab­il­it­ies use assist­ive sys­tems to inter­act with the com­puter and the ser­vice itself. To help them using the applic­a­tion involves two main steps:

  1. Using of WAI-ARIA HTML tags to inform assist­ive sys­tems how to nav­ig­ate through the web­site and identi­fy used components 
  2. Prop­er design­ing of the col­or palette used on the web­site to main­tain a good bal­ance between the client’s design guide and require­ments cor­res­pond­ing to dif­fer­ent vis­ion impairments.


WAI-ARIA is a frame­work for adding attrib­utes to the HTML code that helps assist­ive sys­tems to prop­erly inter­pret, dis­play the web­site and make inter­ac­tion access­ible for people with dis­ab­il­it­ies. Most of assist­ive sys­tems don’t have any prob­lem with inter­pret­ing semantics. Nowadays, we often cre­ate our own com­pon­ents and change beha­vi­or using JavaS­cript, as well as alter it by the CSS. It might turn to be a hindrance, since we can­not be sure that the assist­ive sys­tem has cor­rectly iden­ti­fied com­pon­ents and inter­act with them. In this case, the WAI-ARIA spe­cific­a­tion and frame­work come in handy. This gives us the pos­sib­il­ity to add spe­cial tags to HTML to describe our com­pon­ents. HTML tags like ‘<head­er>‘, ‘<foot­er>‘, ‘<menu>‘, ‘<but­ton>‘ etc.

The main fea­tures of WAI-ARIA tags include:

* Wid­get roles: helps to identi­fy the type of a com­pon­ent, e.g. menu, dia­log, list, list-item

* Struc­ture roles: helps to identi­fy parts of web­sites, such as head­ings, regions, and tables.

* Prop­er­ties:

to describe state of cer­tain com­pon­ents, e.g. checked, hid­den, inval­id, disabled

to mark parts of web­sites which need to be fre­quently refreshed, e.g. live charts or crit­ic­al mes­sages, like alert dialogs.

* Key­board nav­ig­a­tion: to define how press­ing a key inter­acts with your applic­a­tion and which fea­tures a key is able to call

A short example of using WAI-ARIA prop­erty is shown below:

<div role="button" aria-pressed="false">

While using WAI-ARIA tags, we should remem­ber that assist­ive sys­tems have basic mech­an­isms to detect site com­pon­ents and make them access­ible for users. When we intro­duce our own tags, we dis­turb default detec­tion mech­an­isms, so instead, we should care­fully use them accord­ing W3C guidelines. We should always make sure that web­sites are well under­stood by assist­ive sys­tems and pre­vent any dis­rup­tion to already work­ing non-visu­al experiences.

Col­or wheel tools

While design­ing a con­veni­ent user inter­face to be used by people with vari­ous dys­func­tions, we should care­fully select col­ors. Tak­ing into con­sid­er­a­tion that sight impair­ments change the per­cep­tion of col­ors, we need to make sure that we prop­erly take it into consideration.

We can recom­mend two quite effi­cient tools which can do the job. Both tools gen­er­ate a pre­view of how people with dis­ab­il­it­ies see a giv­en col­or or a mix­ture of text and back­ground. This provides an invalu­able feed­back for the UX/UI designer.

How can you test the com­pli­ance  with access­ib­il­ity rules at your website?

WCAG 2.0 auto­mat­ic test pages

There are a few sys­tems on the mar­ket which help to val­id­ate the web­site com­pli­ance with WCAG rules. One of the easi­est and com­pre­hens­ive solu­tions is WAVE.

WAVE is a suite of eval­u­ation tools that help to identi­fy errors in the web­site design and devel­op­ment. It shows WCAG errors and non-visu­al parts of the web­site tested.

While writ­ing this art­icle, we have decided to test, against access­ib­il­ity rules, our Codelab busi­ness page which was not con­sidered to be pre­pared for access­ib­il­ity. Using manu­al and auto­mat­ic tests (WAVE),  we have iden­ti­fied sev­er­al issues which impede web nav­ig­a­tion for people with dis­ab­il­it­ies. Some of the main issues iden­ti­fied are as fol­lows: miss­ing or incor­rect key­board nav­ig­a­tion, altern­at­ive text image, many incor­rect aria tags, as well as a couple of empty ele­ments that were delivered from an extern­al third party. All these issues have been fixed at the time when the art­icle was pub­lished. Besides, we have added descrip­tions for web­site regions so that it can be well inter­preted by screen read­ers like JAWS® and make nav­ig­a­tion on the web­site easi­er for people with visu­al impairments.

Such tools provide users with a clear list of detec­ted issues and detailed inform­a­tion of each prob­lem, its import­ance, and improve­ments recommended.

Con­trast Access­ib­il­ity Validator

An import­ant tool in the WAVE suite is the Con­trast Access­ib­il­ity Val­id­at­or. It checks if the con­trast was suf­fi­cient to make the ser­vice con­veni­ent for people with such dis­orders as deu­ter­an­op­ia, protan­op­ia, and trit­an­op­ia. The in-built con­trast check­er helps WAVE to indic­ate vari­ous issues and shows prob­lem­at­ic areas of our website:

We also have exper­i­ence with Enter­prise applic­a­tions used by people with dis­ab­il­it­ies. These products have been developed with much atten­tion to bar­ri­er-free oper­a­tion, and they always pass extern­al access­ib­il­ity audits without any sig­ni­fic­ant prob­lems. Our cli­ent port­fo­lio includes a couple of pro­jects for one of the largest tele­com pro­viders in Europe. We have already delivered a few applic­a­tions for their agents in con­tact cen­ters which are used to con­tact cli­ents through dif­fer­ent com­mu­nic­a­tion medi­ums, like SMS, chat, email, etc. Fur­ther­more, we suc­cess­fully con­tin­ue work­ing on new top­ics and we’d love to dis­cuss it. And since we want to know about chal­lenges you face with your applic­a­tion or avail­ab­il­ity issues in your pro­jects, feel free to con­tact us.