Nowa­days, the Inter­net has beco­me a medi­um for our dai­ly affairs, such as cont­ac­ting a govern­ment 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­ver­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­tion­al and non-func­tion­al issues. 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 peo­p­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 impair­ment or com­ple­te blind­ness. In such cases, acces­si­bi­li­ty gui­de­lines 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 enabler 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­lines for pro­gramm­ers and desi­gners. The multi­tu­de of disa­bi­li­ties are cover­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 fede­ral law and the ADA is a civil rights law that pro­hi­bit dis­cri­mi­na­ti­on of peo­p­le with disa­bi­li­ties. Almost every EU mem­ber sta­te has adopted 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­lines for web­sites deve­lo­ped by the W3C and a lea­ding stan­dard accept­ed 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 peo­p­le with disa­bi­li­ties. Com­pli­ance 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 wit­hout 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­t­ed 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­t­u­na­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­lo­wing acces­si­bi­li­ty gui­de­lines bring seve­ral advan­ta­ges for peo­p­le and busi­ness alike.

From the busi­ness per­spec­ti­ve, when appli­ed, acces­si­bi­li­ty prin­ci­ples affect not only peo­p­le with chal­lenges but also increase all users expe­ri­ence in unfa­vorable 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­miza­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 increased audi­ence reach, among other bene­fits. Deve­lo­ping a Web Acces­si­bi­li­ty Busi­ness Case for your orga­niza­ti­on high­lights bene­fits of web accessibility.

  1. Incre­asing the web­site sales ran­ge by pro­vi­ding real access for peo­p­le with disabilities.
  2. Buil­ding inter­nal sys­tems of enter­pri­ses to crea­te jobs for peo­p­le with disabilities.
  3. Fight­ing against social exclu­si­on (e.g., as part of orga­niza­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 yours­elf 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­ther ques­ti­on worth con­side­ring is how often you try to imple­ment or take the­se issues into account during pro­duct deve­lo­p­ment or desig­ning. Alt­hough peo­p­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­liza­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 count­ries, public sub­si­dies are offe­red to crea­te jobs for peo­p­le with disa­bi­li­ties. Expen­dit­u­re neces­sa­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 Pol­and, for ins­tance, PFRON, or the Disa­bi­li­ty Fund, par­ti­al­ly sub­si­di­zes sala­ries for peo­p­le with disabilities.

Risks in the deve­lo­p­ment process

Our com­pa­ny alre­a­dy has a few suc­cessful­ly imple­men­ted enter­pri­se-level solu­ti­ons that sup­port employ­ment of peo­p­le who are blind or with visi­on impair­ment. Our pro­jects have focu­sed on making web ser­vices available for this par­ti­cu­lar group, espe­ci­al­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, peo­p­le with such an impair­ment can hand­le web­sites crea­ted wit­hout bar­riers and dif­fi­cul­ties. We have iden­ti­fied a few chal­lenges 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 avo­id the same pitfalls:

  • Con­trast and colors rela­ted issues should be iden­ti­fied at the design stage. The­se are often obvious for ever­yo­ne but may be a real drag for peo­p­le with dys­func­tions. For exam­p­le, errors are most often mark­ed by a sha­de of red, and we’ve had a few pro­blems with the rich con­trast specification.
  • The signal­ing of asyn­chro­no­us errors by the appli­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­ance, 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­sum­ing 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, sel­ec­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 chall­enge 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­side­red at every stage of design and deve­lo­p­ment. This approach makes the adapt­a­ti­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 alre­a­dy pre­pared com­pon­ents. This might delay the pro­ject and increase its over­all cost.

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

Most peo­p­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 appli­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 desig­ning 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 helps 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 peo­p­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­drance, 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: helps to iden­ti­fy the type of a com­po­nent, e.g. menu, dia­log, list, list-item

* Struc­tu­re roles: helps 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 mes­sa­ges, like alert dialogs.

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

A short exam­p­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 careful­ly use them accor­ding W3C gui­de­lines. 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 alre­a­dy working non-visu­al experiences.

Color wheel tools

While desig­ning a con­ve­ni­ent user inter­face to be used by peo­p­le with various dys­func­tions, we should careful­ly sel­ect colors. Taking into con­side­ra­ti­on that sight impairm­ents 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 quite effi­ci­ent tools which can do the job. Both tools gene­ra­te a pre­view of how peo­p­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­luable feed­back for the UX/UI designer.

How can you test the com­pli­ance  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­ance with WCAG rules. One of the easie­st 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 artic­le, we have deci­ded to test, against acces­si­bi­li­ty rules, our Code­lab busi­ness page which was not con­side­red to be pre­pared for acces­si­bi­li­ty. Using manu­al and auto­ma­tic tests (WAVE),  we have iden­ti­fied seve­ral issues which impe­de web navi­ga­ti­on for peo­p­le with disa­bi­li­ties. Some of the main issues iden­ti­fied are as fol­lows: miss­ing 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­ple of emp­ty ele­ments that were deli­ver­ed from an exter­nal third par­ty. All the­se issues have been fixed at the time when the artic­le was published. 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 peo­p­le with visu­al impairments.

Such tools pro­vi­de users with a clear list of detec­ted issues and detail­ed infor­ma­ti­on of each pro­blem, its importance, 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 peo­p­le with such dis­or­ders as deu­te­ran­o­pia, prot­an­opia, and tri­tan­opia. The in-built con­trast che­cker helps WAVE to indi­ca­te various issues and shows pro­ble­ma­tic are­as of our website:

We also have expe­ri­ence with Enter­pri­se appli­ca­ti­ons used by peo­p­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 wit­hout any signi­fi­cant pro­blems. Our cli­ent port­fo­lio includes a cou­ple of pro­jects for one of the lar­gest tele­com pro­vi­ders in Euro­pe. We have alre­a­dy deli­ver­ed a few appli­ca­ti­ons for their agents in cont­act cen­ters which are used to cont­act 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­cessful­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­lenges you face with your appli­ca­ti­on or avai­la­bi­li­ty issues in your pro­jects, feel free to cont­act us.