Nowa­days, the Inter­net has beco­me a medium for our daily affa­irs, such as con­tac­ting a govern­ment agen­cy or using public servi­ce, set­tling taxes or orde­ring new iden­ti­ty cards. The quali­ty and quan­ti­ty of servi­ces deli­ve­red have been con­stan­tly gro­wing. The pre­sen­ce on the Inter­net has beco­me a must for modern com­pa­nies. The Web gives them access to a bro­ad audien­ce and the possi­bi­li­ty of com­pe­ting in dif­fe­rent markets.

Whi­le intro­du­cing new pro­ducts, we must solve a lot of func­tio­nal and non-func­tio­nal issu­es. One of them is to cre­ate UI/UX which will guide and sup­port users in effec­ti­ve websi­te navi­ga­tion. This might be par­ti­cu­lar­ly dif­fi­cult if you want to make your websi­te acces­si­ble for people with disa­bi­li­ties. If the websi­tes are desi­gned and coded cor­rec­tly, they are acces­si­ble for vario­us types of users, inc­lu­ding tho­se with sight impa­ir­ment or com­ple­te blind­ness. In such cases, acces­si­bi­li­ty guide­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 servi­ces for as many users as possi­ble, regar­dless of the­ir limi­ta­tions. This con­cept refers not only to com­pu­ter inter­fa­ces but to any devi­ces which inte­racts with humans. The main ena­bler making websi­tes acces­si­ble is the W3C Web Acces­si­bi­li­ty Ini­tia­ti­ve (WAI), an ini­tia­ti­ve which deve­lops tech­ni­cal spe­ci­fi­ca­tions and guide­li­nes for pro­gram­mers and desi­gners. The mul­ti­tu­de of disa­bi­li­ties are cove­red by three leading docu­ments. The most impor­tant of them is the WCAG, cre­ated by the World Wide Web Con­sor­tium. The other two are Sec­tion 508 and ADA, which are essen­tial only in the US. In the Uni­ted Sta­tes, Sec­tion 508 is a fede­ral law and the ADA is a civil rights law that pro­hi­bit discri­mi­na­tion of people with disa­bi­li­ties. Almost eve­ry EU mem­ber sta­te has adop­ted legal web sys­tem requ­ire­ments which defi­ne accessibility

WCAG 2.0

WCAG 2.0 is a com­pi­la­tion of acces­si­bi­li­ty guide­li­nes for websi­tes deve­lo­ped by the W3C and a leading stan­dard accep­ted inter­na­tio­nal­ly for web acces­si­bi­li­ty. The­se set of recom­men­da­tions for the user inter­fa­ce to make it more acces­si­ble for people with disa­bi­li­ties. Com­plian­ce is voluntary.

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

Level A is easi­ly adap­ta­ble to any page witho­ut impact on its design or struc­tu­re. Level AA and AAA requ­ire a bit more work to ful­fill. AAA is hard to achie­ve, e.g. one of the rules requ­ires 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­tion to accom­plish it when our color palet­te has limi­ted possi­bi­li­ty is to add a but­ton to chan­ge from “nor­mal” to high con­trast palet­te only. For­tu­na­te­ly, we don’t have to meet the requ­ire­ment most of the time. It is inten­ded for very spe­cial websi­tes. Howe­ver, AA level is pre­fe­ra­ble and legal­ly requ­ired for some public servi­ces. Usu­al­ly, we adopt a sub­set from Level AAA to impro­ve the tar­get gro­up efficiency.

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

Fol­lo­wing acces­si­bi­li­ty guide­li­nes bring seve­ral advan­ta­ges for people and busi­ness alike.

From the busi­ness per­spec­ti­ve, when applied, acces­si­bi­li­ty prin­ci­ples affect not only people with chal­len­ges but also incre­ase all users expe­rien­ce in unfa­vo­ra­ble con­di­tions like:

  • bri­ght sunlight
  • small scre­ens 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 websi­tes more inclusive.

Acces­si­bi­li­ty over­laps with other best prac­ti­ces, such as mobi­le web design, devi­ce inde­pen­den­ce, mul­ti-modal inte­rac­tion, usa­bi­li­ty, design for older users, and search engi­ne opti­mi­za­tion (SEO). Case stu­dies show that acces­si­ble websi­tes have bet­ter search results, redu­ced main­te­nan­ce costs, and incre­ased audien­ce reach, among other bene­fits. Deve­lo­ping a Web Acces­si­bi­li­ty Busi­ness Case for your orga­ni­za­tion high­li­ghts bene­fits of web accessibility.

  1. Incre­asing the websi­te sales ran­ge by pro­vi­ding real access for people with disabilities.
  2. Buil­ding inter­nal sys­tems of enter­pri­ses to cre­ate jobs for people with disabilities.
  3. Figh­ting aga­inst social exc­lu­sion (e.g., as part of orga­ni­za­tions CSR).
  4. Ope­ning up for coope­ra­tion with the public sec­tor coope­ra­tion offers.

When it comes to points 1 and 3, ask your­self how often you can find websi­tes out­si­de the public doma­in, which inten­tio­nal­ly inte­gra­te high acces­si­bi­li­ty solu­tions. Ano­ther question worth con­si­de­ring is how often you try to imple­ment or take the­se issu­es into acco­unt during pro­duct deve­lop­ment or desi­gning. Altho­ugh people with disa­bi­li­ties are pre­sent on the Web, we often skip the tar­get gro­up when we ana­ly­ze our solu­tions. Why sho­uld you con­tri­bu­te to the deepe­ning of social exc­lu­sion for this gro­up? Good prac­ti­ces and rules may attract new users to our servi­ces and open new mar­kets, e.g. public doma­ins. This is a bro­ad mar­ket with gro­wing needs for digi­ta­li­za­tion and shift more pro­ces­ses to the Web.

You sho­uld not be too much con­cer­ned abo­ut the cost. In many coun­tries, public sub­si­dies are offe­red to cre­ate jobs for people with disa­bi­li­ties. Expen­di­tu­re neces­sa­ry for build and cer­ti­fy a solu­tion can be coun­ter­ba­lan­ced by obta­ining job-rela­ted sub­si­dies. In Poland, for instan­ce, PFRON, or the Disa­bi­li­ty Fund, par­tial­ly sub­si­di­zes sala­ries for people with disabilities.

Risks in the deve­lop­ment process

Our com­pa­ny alre­ady has a few suc­cess­ful­ly imple­men­ted enter­pri­se-level solu­tions that sup­port employ­ment of people who are blind or with vision impa­ir­ment. Our pro­jects have focu­sed on making web servi­ces ava­ila­ble for this par­ti­cu­lar gro­up, espe­cial­ly the com­ple­te inte­gra­tion of the JAWS assi­sti­ve softwa­re. The User Inter­fa­ce (UI) design itself has been deve­lo­ped to sup­port  readability.

Colors used also respond to a wide ran­ge of color vision dys­func­tions. Thus, people with such an impa­ir­ment can han­dle websi­tes cre­ated witho­ut bar­riers and dif­fi­cul­ties. We have iden­ti­fied a few chal­len­ges to plan­ning and imple­men­ta­tion during websi­te deve­lop­ment. Now, we can sha­re a few tips to help you to avo­id the same pitfalls:

  • Con­trast and colors rela­ted issu­es sho­uld be iden­ti­fied at the design sta­ge. The­se are often obvio­us for eve­ry­one but may be a real drag for people with dys­func­tions. For exam­ple, errors are most often mar­ked by a sha­de of red, and we’ve had a few pro­blems with the rich con­trast specification.
  • The signa­ling of asyn­chro­no­us errors by the appli­ca­tion shall be desi­gned in the way that can be pro­per­ly reco­gni­zed by assi­sti­ve systems.
  • The third par­ty com­po­nents shall be veri­fied befo­re intro­du­ced to the pro­ject. The­ir veri­fi­ca­tion sho­uld cover acces­si­bi­li­ty com­plian­ce, com­po­nents exten­sion, and licen­se requ­ire­ments. Altho­ugh many free com­po­nents offer basic acces­si­bi­li­ty, adap­ting them to the requ­ired level may often be time-con­su­ming or even impos­si­ble due to licen­se limitations.
  • One of the pro­ble­ma­tic com­po­nents hap­pe­ned to be a table. Most assi­sti­ve sys­tems help users effi­cien­tly deal with data tables. Howe­ver, whi­le some of popu­lar table com­po­nents 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 cho­ose tho­se that offer a possi­bi­li­ty to modi­fy the websi­te struc­tu­re. Let’s assu­me we use a fra­me­work with an HTML gene­ra­tor with a fix set of com­po­nents. In that case, we may come across a pro­blem whe­re assi­sti­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 solve the issue becau­se the gene­ra­tor itself 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 requ­ire­ments sho­uld be intro­du­ced to the sys­tem as ear­ly as possi­ble and con­si­de­red at eve­ry sta­ge of design and deve­lop­ment. This appro­ach makes the adap­ta­tion of ele­ments easier and faster. A team fami­liar with basic tech­ni­qu­es may even not expe­rien­ce a drop in per­for­man­ce. Howe­ver, the intro­duc­tion of acces­si­bi­li­ty rules at a later pha­se of a pro­ject may requ­ire us to repla­ce alre­ady pre­pa­red com­po­nents. This might delay the pro­ject and incre­ase its ove­rall cost.

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

Most people with disa­bi­li­ties use assi­sti­ve sys­tems to inte­ract with the com­pu­ter and the servi­ce itself. To help them using the appli­ca­tion invo­lves two main steps:

  1. Using of WAI-ARIA HTML tags to inform assi­sti­ve sys­tems how to navi­ga­te thro­ugh the websi­te and iden­ti­fy used components 
  2. Pro­per desi­gning of the color palet­te used on the websi­te to main­ta­in a good balan­ce betwe­en the client’s design guide and requ­ire­ments cor­re­spon­ding to dif­fe­rent vision impairments.


WAI-ARIA is a fra­me­work for adding attri­bu­tes to the HTML code that helps assi­sti­ve sys­tems to pro­per­ly inter­pret, display the websi­te and make inte­rac­tion acces­si­ble for people with disa­bi­li­ties. Most of assi­sti­ve sys­tems don’t have any pro­blem with inter­pre­ting seman­tics. Nowa­days, we often cre­ate our own com­po­nents and chan­ge beha­vior 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 assi­sti­ve sys­tem has cor­rec­tly iden­ti­fied com­po­nents and inte­ract with them. In this case, the WAI-ARIA spe­ci­fi­ca­tion and fra­me­work come in han­dy. This gives us the possi­bi­li­ty to add spe­cial tags to HTML to descri­be our com­po­nents. HTML tags like ‘<header>‘, ‘<footer>‘, ‘<menu>‘, ‘<but­ton>‘ etc.

The main featu­res 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 websi­tes, such as headings, regions, and tables.

* Pro­per­ties:

to descri­be sta­te of cer­ta­in com­po­nents, e.g. chec­ked, hid­den, inva­lid, disabled

to mark parts of websi­tes which need to be fre­qu­en­tly refre­shed, e.g. live charts or cri­ti­cal mes­sa­ges, like alert dialogs.

* Key­bo­ard navi­ga­tion: to defi­ne how pres­sing a key inte­racts with your appli­ca­tion and which featu­res a key is able to call

A short exam­ple of using WAI-ARIA pro­per­ty is shown below:

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

Whi­le using WAI-ARIA tags, we sho­uld remem­ber that assi­sti­ve sys­tems have basic mecha­ni­sms to detect site com­po­nents and make them acces­si­ble for users. When we intro­du­ce our own tags, we disturb default detec­tion mecha­ni­sms, so inste­ad, we sho­uld care­ful­ly use them accor­ding W3C guide­li­nes. We sho­uld always make sure that websi­tes are well under­sto­od by assi­sti­ve sys­tems and pre­vent any disrup­tion to alre­ady wor­king non-visu­al experiences.

Color whe­el tools

Whi­le desi­gning a conve­nient user inter­fa­ce to be used by people with vario­us dys­func­tions, we sho­uld care­ful­ly select colors. Taking into con­si­de­ra­tion that sight impa­ir­ments chan­ge the per­cep­tion of colors, we need to make sure that we pro­per­ly take it into consideration.

We can recom­mend two quite effi­cient tools which can do the job. Both tools gene­ra­te a pre­view of how people with disa­bi­li­ties see a given color or a mixtu­re of text and back­gro­und. This pro­vi­des an inva­lu­able feed­back for the UX/UI designer.

How can you test the com­plian­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 websi­te com­plian­ce with WCAG rules. One of the easiest and com­pre­hen­si­ve solu­tions is WAVE.

WAVE is a suite of eva­lu­ation tools that help to iden­ti­fy errors in the websi­te design and deve­lop­ment. It shows WCAG errors and non-visu­al parts of the websi­te tested.

Whi­le wri­ting this artic­le, we have deci­ded to test, aga­inst 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 seve­ral issu­es which impe­de web navi­ga­tion for people with disa­bi­li­ties. Some of the main issu­es iden­ti­fied are as fol­lows: mis­sing or incor­rect key­bo­ard navi­ga­tion, alter­na­ti­ve text ima­ge, many incor­rect aria tags, as well as a couple of emp­ty ele­ments that were deli­ve­red from an exter­nal third par­ty. All the­se issu­es have been fixed at the time when the artic­le was publi­shed. Besi­des, we have added descrip­tions for websi­te regions so that it can be well inter­pre­ted by scre­en readers like JAWS® and make navi­ga­tion on the websi­te easier for people with visu­al impairments.

Such tools pro­vi­de users with a cle­ar list of detec­ted issu­es and deta­iled infor­ma­tion of each pro­blem, its impor­tan­ce, and impro­ve­ments recommended.

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

An impor­tant 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­cient to make the servi­ce conve­nient for people with such disor­ders as deu­te­ra­no­pia, pro­ta­no­pia, and tri­ta­no­pia. The in-built con­trast chec­ker helps WAVE to indi­ca­te vario­us issu­es and shows pro­ble­ma­tic are­as of our website:

We also have expe­rien­ce with Enter­pri­se appli­ca­tions used by people with disa­bi­li­ties. The­se pro­ducts have been deve­lo­ped with much atten­tion to bar­rier-free ope­ra­tion, and they always pass exter­nal acces­si­bi­li­ty audits witho­ut any signi­fi­cant pro­blems. Our client port­fo­lio inc­lu­des a couple of pro­jects for one of the lar­gest tele­com pro­vi­ders in Euro­pe. We have alre­ady deli­ve­red a few appli­ca­tions for the­ir agents in con­tact cen­ters which are used to con­tact clients thro­ugh dif­fe­rent com­mu­ni­ca­tion mediums, like SMS, chat, ema­il, etc. Fur­ther­mo­re, we suc­cess­ful­ly con­ti­nue wor­king on new topics and we’d love to discuss it. And sin­ce we want to know abo­ut chal­len­ges you face with your appli­ca­tion or ava­ila­bi­li­ty issu­es in your pro­jects, feel free to con­tact us.