Accessibility Statement

 

This list is by no means a com­plete list of require­ments for WCAG com­pli­ance and the Direc­tive (EU) 2016/2102  but it does include the most impor­tant items to make our web­site acces­si­ble to peo­ple with dis­abil­i­ties, by offer­ing a mul­ti sen­so­ry jour­ney through Bren­dan’s archive of writ­ten word, audio and video.

•Text is at least 16 px in size. — where pos­si­ble, text has been set at 16px for easy read­ing and flu­id (some large areas have been adjust­ed for mobile)

•Colour con­trast rules are fol­lowed for peo­ple with low vision or colour blind­ness

•States are not com­mu­ni­cat­ed just by colour there are oth­er options pro­vid­ed also

 

•All links are key­board-acces­si­ble (usu­al­ly by using the tab key)

•All nav­i­ga­tion (menus) are key­board-acces­si­ble we have added a skip-link for screen read­ers to avoid the rep­e­ti­tion of nav­i­ga­tion links being read out on each page

•All oth­er func­tion­al­i­ty is oper­a­ble by key­board, for exam­ple ‘play video’ and test­ed with a vir­tu­al acces­si­bil­i­ty screen read­er and also with NVDA screen read­er avail­able here https://www.nvaccess.org/download/ (this link will take you to an exter­nal page)

•All of the above have vis­i­ble focus indi­ca­tor and out­line in one of the web­site colours hex #b1557f

 

•<a> tag is used for links

•Links in body are dis­tin­guished from sur­round­ing text (usu­al­ly by under­lin­ing)

•Link text in the Divi theme is not specif­i­cal­ly iden­ti­fied for a spe­cif­ic role in Aria, we are advo­cat­ing that Divi make this acces­si­ble for devel­op­ers to change the role name from oth­er than ‘link’.

 

•Only one h1 per page

•Head­ings for each page are in sequence

•Head­ing lev­els are not skipped

 

•Images have rel­e­vant alt text or cap­tions unless pure­ly cos­met­ic

•Back­ground images are pure­ly dec­o­ra­tive and used spar­ing­ly

•Slid­ers and carousels are labeled with left and right arrows, inages and text are labeled and work well with a screen read­er

 

•Video does not auto-play

•Video has labeled play icon

•Video can be paused

•Video has descrip­tion text

•Video has accu­rate tran­script and cap­tions sup­plied by Mar­tin Blake who is the cre­ative behind the pho­tog­ra­phy and video con­tent

 

•Fields have label tags

•Required fields are labeled “required” in words, not just an aster­isk

•Sub­mit but­ton clear­ly states what sub­mit­ting the form does, i.e., “sub­scribe to email list”

•Fields are key­board-acces­si­ble

 

PDFs are acces­si­ble or have HTML equiv­a­lents. Mak­ing PDFs acces­si­ble is the respon­si­bil­i­ty of the client.

 

•iframes have a title attribute describ­ing the iframe’s pur­pose

 

Inclusion

 

 

Most social embeds and embed­ded ads are not acces­si­ble.

Ani­ma­tion effects may not acces­si­ble.

Auto-play­ing videos has not been imple­ment­ed on this web­site as it traps the vis­i­tor in a loop and they can­not exit.  YouTube videos and Google Maps are not com­plete­ly acces­si­ble, strict­ly speak­ing (though most of my web­site clients are sat­is­fied with using them on oth­er­wise acces­si­ble sites)

Any linked PDFs need to be re-gen­er­at­ed with acces­si­bil­i­ty in mind, and all embed­ded videos need cap­tions or tran­scripts

 

The work of keep­ing a web­site in com­pli­ance is nev­er done. It’s an ongo­ing process through­out the life of the site.

It is very easy for a web­site to drift out of com­pli­ance as peo­ple add con­tent, fea­tures get added, and plu­g­ins get updat­ed. New font colours are added that don’t meet the min­i­mum con­trast guide­lines, for exam­ple. Or, some­one adds new images with­out adding alt tags. Acces­si­bil­i­ty com­pli­ance is not a one-time deal; any updates to the site must be made with acces­si­bil­i­ty in mind if you want to stay com­pli­ant.

 

I am an inter­ac­tion design con­trac­tor, based in West Wick­low and I have co designed many projects with Robin from Leanweb.eu. I have been a web acces­si­bil­i­ty advo­cate since 2012 and have been involved in research to inves­ti­gate the bar­ri­ers faced by peo­ple with a dis­abil­i­ty when access­ing online con­tent. Our CMS we use is Word­Press which is lay­ered with DIVI for func­tion­al­i­ty and styling pur­pos­es. This web­site was designed with acces­si­bil­i­ty and con­for­mance to the Direc­tive (EU) 2016/2102 as a pri­or­i­ty. While every effort has been made to adhere to the accept­ed guide­lines and stan­dards for acces­si­bil­i­ty and usabil­i­ty, it is not always pos­si­ble to do so in all areas of the web­site. This may include third par­ty appli­ca­tions, social media feed aggre­ga­tion, and third par­ty map inte­gra­tions, like Google maps. We are con­tin­u­al­ly work­ing to improve the user expe­ri­ence for every­one. If you expe­ri­ence any dif­fi­cul­ty in using this web­site, please let me know. we are com­mit­ted to mak­ing this web­site as acces­si­ble as pos­si­ble.

 

Thank you, Rachel