Nowa­days, the Inter­net has beco­me a medi­um for our dai­ly affairs, such as con­ta­c­ting a government agen­cy or using public ser­vice, sett­ling taxes or orde­ring new iden­ti­ty cards. The qua­li­ty and quan­ti­ty of ser­vices deli­ve­r­ed have been con­stant­ly gro­wing. The pre­sence on the Inter­net has beco­me a must for modern com­pa­nies. The Web gives them access to a broad audi­ence and the pos­si­bi­li­ty of com­pe­ting in dif­fe­rent markets.

While intro­du­cing new pro­ducts, we must sol­ve a lot of func­tio­n­al and non-func­tio­n­al issu­es. One of them is to crea­te UI/UX which will gui­de and sup­port users in effec­ti­ve web­site navi­ga­ti­on. This might be par­ti­cu­lar­ly dif­fi­cult if you want to make your web­site acces­si­ble for peop­le with disa­bi­li­ties. If the web­sites are desi­gned and coded cor­rect­ly, they are acces­si­ble for various types of users, inclu­ding tho­se with sight impairment or com­ple­te blind­ness. In such cases, acces­si­bi­li­ty gui­de­li­nes and rules might come in handy. 

Acces­si­bi­li­ty is the prac­ti­ce of buil­ding pro­ducts or web ser­vices for as many users as pos­si­ble, regard­less of their limi­ta­ti­ons. This con­cept refers not only to com­pu­ter inter­faces but to any devices which inter­acts with humans. The main enab­ler making web­sites acces­si­ble is the W3C Web Acces­si­bi­li­ty Initia­ti­ve (WAI), an initia­ti­ve which deve­lo­ps tech­ni­cal spe­ci­fi­ca­ti­ons and gui­de­li­nes for pro­gramm­ers and desi­gners. The mul­ti­tu­de of disa­bi­li­ties are cove­r­ed by three lea­ding docu­ments. The most important of them is the WCAG, crea­ted by the World Wide Web Con­sor­ti­um. The other two are Sec­tion 508 and ADA, which are essen­ti­al only in the US. In the United Sta­tes, Sec­tion 508 is a federal law and the ADA is a civil rights law that pro­hi­bit discri­mi­na­ti­on of peop­le with disa­bi­li­ties. Almost every EU mem­ber sta­te has adop­ted legal web sys­tem requi­re­ments which defi­ne accessibility

WCAG 2.0

WCAG 2.0 is a com­pi­la­ti­on of acces­si­bi­li­ty gui­de­li­nes for web­sites deve­lo­ped by the W3C and a lea­ding stan­dard accep­ted inter­na­tio­nal­ly for web acces­si­bi­li­ty. The­se set of recom­men­da­ti­ons for the user inter­face to make it more acces­si­ble for peop­le with disa­bi­li­ties. Com­pli­an­ce is voluntary.

Sin­ce  June 5th,  2018, WCAG 2.1 has been valid as an exten­si­on of 2.0. WCAG 2.1 main­ly focu­ses on impro­ving acces­si­bi­li­ty for three major groups: “users with cogni­ti­ve or lear­ning disa­bi­li­ties, users with low visi­on, and users with disa­bi­li­ties on mobi­le devices.”

Level A is easi­ly adap­ta­ble to any page without impact on its design or struc­tu­re. Level AA and AAA requi­re a bit more work to ful­fill. AAA is hard to achie­ve, e.g. one of the rules requi­res to use only very dark colors mixed with very light colors to achie­ve at least a 7:1 con­trast ratio. The most com­mon solu­ti­on to accom­plish it when our color palet­te has limi­ted pos­si­bi­li­ty is to add a but­ton to chan­ge from “nor­mal” to high con­trast palet­te only. For­tu­n­a­te­ly, we don’t have to meet the requi­re­ment most of the time. It is inten­ded for very spe­cial web­sites. Howe­ver, AA level is pre­fera­ble and legal­ly requi­red for some public ser­vices. Usual­ly, we adopt a sub­set from Level AAA to impro­ve the tar­get group efficiency.

Busi­ness advan­ta­ges of acces­si­bi­li­ty service

Fol­lowing acces­si­bi­li­ty gui­de­li­nes bring several advan­ta­ges for peop­le and busi­ness alike.

From the busi­ness per­spec­ti­ve, when app­lied, acces­si­bi­li­ty princi­ples affect not only peop­le with chal­len­ges but also incre­a­se all users expe­ri­ence in unfa­vor­able con­di­ti­ons like:

  • bright sun­light
  • small screens on mobi­le pho­nes, tablets, etc.
  • slow inter­net con­nec­tion or limited/expensive bandwidth

Enhan­ced acces­si­bi­li­ty makes web­sites more inclusive.

Acces­si­bi­li­ty over­laps with other best prac­ti­ces, such as mobi­le web design, device inde­pen­dence, mul­ti-modal inter­ac­tion, usa­bi­li­ty, design for older users, and search engi­ne opti­miz­a­ti­on (SEO). Case stu­dies show that acces­si­ble web­sites have bet­ter search results, redu­ced main­ten­an­ce cos­ts, and incre­a­sed audi­ence reach, among other bene­fits. Deve­lo­ping a Web Acces­si­bi­li­ty Busi­ness Case for your orga­niz­a­ti­on high­lights bene­fits of web accessibility.

  1. Incre­a­sing the web­site sales ran­ge by pro­vi­ding real access for peop­le with disabilities.
  2. Buil­ding inter­nal sys­tems of enter­pri­ses to crea­te jobs for peop­le with disabilities.
  3. Figh­t­ing against social exclu­si­on (e.g., as part of orga­niz­a­ti­ons CSR).
  4. Ope­ning up for coope­ra­ti­on with the public sec­tor coope­ra­ti­on offers.

When it comes to points 1 and 3, ask yourself how often you can find web­sites out­side the public domain, which inten­tio­nal­ly inte­gra­te high acces­si­bi­li­ty solu­ti­ons. Ano­t­her ques­ti­on worth con­si­de­ring is how often you try to imple­ment or take the­se issu­es into account during pro­duct deve­lo­p­ment or designing. Alt­hough peop­le with disa­bi­li­ties are pre­sent on the Web, we often skip the tar­get group when we ana­ly­ze our solu­ti­ons. Why should you con­tri­bu­te to the deepe­ning of social exclu­si­on for this group? Good prac­ti­ces and rules may attract new users to our ser­vices and open new mar­kets, e.g. public domains. This is a broad mar­ket with gro­wing needs for digi­ta­liz­a­ti­on and shift more pro­ces­ses to the Web.

You should not be too much con­cer­ned about the cost. In many coun­tries, public sub­si­dies are offe­red to crea­te jobs for peop­le with disa­bi­li­ties. Expen­dit­u­re necessa­ry for build and cer­ti­fy a solu­ti­on can be coun­ter­ba­lan­ced by obtai­ning job-rela­ted sub­si­dies. In Poland, for instance, PFRON, or the Disa­bi­li­ty Fund, par­ti­al­ly sub­si­di­zes sala­ries for peop­le with disabilities.

Risks in the deve­lo­p­ment process

Our com­pa­ny alrea­dy has a few suc­cess­ful­ly imple­men­ted enter­pri­se-level solu­ti­ons that sup­port employ­ment of peop­le who are blind or with visi­on impairment. Our pro­jects have focu­sed on making web ser­vices avail­ab­le for this par­ti­cu­lar group, espe­cial­ly the com­ple­te inte­gra­ti­on of the JAWS assis­ti­ve soft­ware. The User Inter­face (UI) design its­elf has been deve­lo­ped to sup­port  readability.

Colors used also respond to a wide ran­ge of color visi­on dys­func­tions. Thus, peop­le with such an impairment can hand­le web­sites crea­ted without bar­ri­ers and dif­fi­cul­ties. We have iden­ti­fied a few chal­len­ges to plan­ning and imple­men­ta­ti­on during web­site deve­lo­p­ment. Now, we can share a few tips to help you to avoid the same pitfalls:

  • Con­trast and colors rela­ted issu­es should be iden­ti­fied at the design sta­ge. The­se are often obvious for ever­yo­ne but may be a real drag for peop­le with dys­func­tions. For examp­le, errors are most often mar­ked by a shade of red, and we’ve had a few pro­blems with the rich con­trast specification.
  • The signa­ling of asyn­chro­nous errors by the app­li­ca­ti­on shall be desi­gned in the way that can be pro­per­ly reco­gni­zed by assis­ti­ve systems.
  • The third par­ty com­pon­ents shall be veri­fied befo­re intro­du­ced to the pro­ject. Their veri­fi­ca­ti­on should cover acces­si­bi­li­ty com­pli­an­ce, com­pon­ents exten­si­on, and licen­se requi­re­ments. Alt­hough many free com­pon­ents offer basic acces­si­bi­li­ty, adap­ting them to the requi­red level may often be time-con­suming or even impos­si­ble due to licen­se limitations.
  • One of the pro­ble­ma­tic com­pon­ents hap­pen­ed to be a table. Most assis­ti­ve sys­tems help users effi­ci­ent­ly deal with data tables. Howe­ver, while some of popu­lar table com­pon­ents are reco­gni­zed as a list, selec­ting the right one in the ear­ly pha­se of the pro­ject can save much effort.
  • When deci­ding on the tech­no­lo­gy, we choo­se tho­se that offer a pos­si­bi­li­ty to modi­fy the web­site struc­tu­re. Let’s assu­me we use a frame­work with an HTML gene­ra­tor with a fix set of com­pon­ents. In that case, we may come across a pro­blem whe­re assis­ti­ve sys­tems do not reco­gni­ze ele­ments in the way we would like them to do. It can be a chal­len­ge to sol­ve the issue becau­se the gene­ra­tor its­elf is not part of our code­ba­se but it belongs to the library/framework code­ba­se. We can only go as far as the API lets us.
  • Acces­si­bi­li­ty requi­re­ments should be intro­du­ced to the sys­tem as ear­ly as pos­si­ble and con­si­de­red at every sta­ge of design and deve­lo­p­ment. This approach makes the adap­t­ati­on of ele­ments easier and fas­ter. A team fami­li­ar with basic tech­ni­ques may even not expe­ri­ence a drop in per­for­mance. Howe­ver, the intro­duc­tion of acces­si­bi­li­ty rules at a later pha­se of a pro­ject may requi­re us to replace alrea­dy pre­pa­red com­pon­ents. This might delay the pro­ject and incre­a­se its over­all cost.

How to pro­vi­de acces­si­bi­li­ty rules to your website ?

Most peop­le with disa­bi­li­ties use assis­ti­ve sys­tems to inter­act with the com­pu­ter and the ser­vice its­elf. To help them using the app­li­ca­ti­on invol­ves two main steps:

  1. Using of WAI-ARIA HTML tags to inform assis­ti­ve sys­tems how to navi­ga­te through the web­site and iden­ti­fy used components 
  2. Pro­per designing of the color palet­te used on the web­site to main­tain a good balan­ce bet­ween the client’s design gui­de and requi­re­ments cor­re­spon­ding to dif­fe­rent visi­on impairments.


WAI-ARIA is a frame­work for adding attri­bu­tes to the HTML code that hel­ps assis­ti­ve sys­tems to pro­per­ly inter­pret, dis­play the web­site and make inter­ac­tion acces­si­ble for peop­le with disa­bi­li­ties. Most of assis­ti­ve sys­tems don’t have any pro­blem with inter­pre­ting seman­ti­cs. Nowa­days, we often crea­te our own com­pon­ents and chan­ge beha­vi­or using Java­Script, as well as alter it by the CSS. It might turn to be a hin­dran­ce, sin­ce we can­not be sure that the assis­ti­ve sys­tem has cor­rect­ly iden­ti­fied com­pon­ents and inter­act with them. In this case, the WAI-ARIA spe­ci­fi­ca­ti­on and frame­work come in han­dy. This gives us the pos­si­bi­li­ty to add spe­cial tags to HTML to descri­be our com­pon­ents. HTML tags like ‘<hea­der>‘, ‘<foo­ter>‘, ‘<menu>‘, ‘<but­ton>‘ etc.

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

* Wid­get roles: hel­ps to iden­ti­fy the type of a com­po­nent, e.g. menu, dia­log, list, list-item

* Struc­tu­re roles: hel­ps to iden­ti­fy parts of web­sites, such as hea­dings, regi­ons, and tables.

* Pro­per­ties:

to descri­be sta­te of cer­tain com­pon­ents, e.g. che­cked, hid­den, inva­lid, disabled

to mark parts of web­sites which need to be fre­quent­ly refres­hed, e.g. live charts or cri­ti­cal messages, like alert dialogs.

* Key­board navi­ga­ti­on: to defi­ne how pres­sing a key inter­acts with your app­li­ca­ti­on and which fea­tures a key is able to call

A short examp­le of using WAI-ARIA pro­per­ty is shown below:

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

While using WAI-ARIA tags, we should remem­ber that assis­ti­ve sys­tems have basic mecha­nisms to detect site com­pon­ents and make them acces­si­ble for users. When we intro­du­ce our own tags, we dis­turb default detec­tion mecha­nisms, so ins­tead, we should care­ful­ly use them accord­ing W3C gui­de­li­nes. We should always make sure that web­sites are well unders­tood by assis­ti­ve sys­tems and pre­vent any dis­rup­ti­on to alrea­dy working non-visu­al experiences.

Color wheel tools

While designing a con­ve­ni­ent user inter­face to be used by peop­le with various dys­func­tions, we should care­ful­ly select colors. Taking into con­si­de­ra­ti­on that sight impairments chan­ge the per­cep­ti­on of colors, we need to make sure that we pro­per­ly take it into consideration.

We can recom­mend two qui­te effi­ci­ent tools which can do the job. Both tools gene­ra­te a pre­view of how peop­le with disa­bi­li­ties see a given color or a mix­tu­re of text and back­ground. This pro­vi­des an inva­lu­able feed­back for the UX/UI designer.

How can you test the com­pli­an­ce  with acces­si­bi­li­ty rules at your website?

WCAG 2.0 auto­ma­tic test pages

The­re are a few sys­tems on the mar­ket which help to vali­da­te the web­site com­pli­an­ce with WCAG rules. One of the easiest and com­pre­hen­si­ve solu­ti­ons is WAVE.

WAVE is a suite of eva­lua­ti­on tools that help to iden­ti­fy errors in the web­site design and deve­lo­p­ment. It shows WCAG errors and non-visu­al parts of the web­site tested.

While wri­ting this arti­cle, we have deci­ded to test, against acces­si­bi­li­ty rules, our Code­lab busi­ness page which was not con­si­de­red to be pre­pa­red for acces­si­bi­li­ty. Using manu­al and auto­ma­tic tests (WAVE),  we have iden­ti­fied several issu­es which impe­de web navi­ga­ti­on for peop­le with disa­bi­li­ties. Some of the main issu­es iden­ti­fied are as fol­lows: mis­sing or incor­rect key­board navi­ga­ti­on, alter­na­ti­ve text image, many incor­rect aria tags, as well as a cou­p­le of empty ele­ments that were deli­ve­r­ed from an exter­nal third par­ty. All the­se issu­es have been fixed at the time when the arti­cle was publis­hed. Bes­i­des, we have added descrip­ti­ons for web­site regi­ons so that it can be well inter­pre­ted by screen rea­ders like JAWS® and make navi­ga­ti­on on the web­site easier for peop­le with visu­al impairments.

Such tools pro­vi­de users with a clear list of detec­ted issu­es and detail­ed infor­ma­ti­on of each pro­blem, its impor­t­ance, and impro­ve­ments recommended.

Con­trast Acces­si­bi­li­ty Validator

An important tool in the WAVE suite is the Con­trast Acces­si­bi­li­ty Vali­da­tor. It checks if the con­trast was suf­fi­ci­ent to make the ser­vice con­ve­ni­ent for peop­le with such dis­or­ders as deu­ter­an­opia, prot­an­opia, and tri­t­an­opia. The in-built con­trast che­cker hel­ps WAVE to indi­ca­te various issu­es and shows pro­ble­ma­tic are­as of our website:

We also have expe­ri­ence with Enter­pri­se app­li­ca­ti­ons used by peop­le with disa­bi­li­ties. The­se pro­ducts have been deve­lo­ped with much atten­ti­on to bar­ri­er-free ope­ra­ti­on, and they always pass exter­nal acces­si­bi­li­ty audits without any signi­fi­cant pro­blems. Our cli­ent port­fo­lio inclu­des a cou­p­le of pro­jects for one of the lar­gest telecom pro­vi­ders in Euro­pe. We have alrea­dy deli­ve­r­ed a few app­li­ca­ti­ons for their agents in con­ta­ct cen­ters which are used to con­ta­ct cli­ents through dif­fe­rent com­mu­ni­ca­ti­on medi­ums, like SMS, chat, email, etc. Fur­ther­mo­re, we suc­cess­ful­ly con­ti­nue working on new topics and we’d love to dis­cuss it. And sin­ce we want to know about chal­len­ges you face with your app­li­ca­ti­on or avai­la­bi­li­ty issu­es in your pro­jects, feel free to con­ta­ct us.