Re­act isn’t ac­ces­si­ble? Megan Zlock on why that is far from the truth

net magazine - - CONTENTS - Megan (@megan­zlock) is a front-end de­vel­oper at Viget by day and hob­by­ist il­lus­tra­tor by night, based near Wash­ing­ton, DC.

Megan Zlock ex­plains why Re­act and ac­ces­si­bil­ity can go hand in hand

As an ac­ces­si­bil­ity ad­vo­cate and Re­act de­vel­oper, it makes me sad when I hear state­ments like this. Es­pe­cially about a tech­nol­ogy so widely used and mul­ti­pur­pose. Re­act is just a li­brary for ren­der­ing and re-ren­der­ing a dy­namic data-driven UI. It does not auto-gen­er­ate HTML or en­force flawed opin­ions to your markup struc­ture. Not on its own, any­way. It doesn’t mat­ter which frame­work you might pre­fer – any of these can pro­duce ac­ces­si­ble web­sites.

The ac­ces­si­bil­ity con­cerns you hit aren’t all that dif­fer­ent than a typ­i­cal web­site, ei­ther. How­ever, there are some unique chal­lenges and some steps that you can take to dras­ti­cally im­prove the ac­ces­si­bil­ity of your client-side ap­pli­ca­tion.

Us­ing se­man­tic HTML is a great gen­eral ac­ces­si­bil­ity tip, but it ap­plies a lit­tle more here. When you can ap­ply a click event han­dler to any HTML el­e­ment with in­cred­i­ble ease, it can lead to some bad habits in your markup. I can’t name all of the key­board be­hav­iours on a se­lect in­put, so I pre­fer to use a se­man­tic se­lect in­put. Links and but­tons are a huge pain point here as well. Don’t add a click event to a div when you can use a but­ton. And if there’s any change to the URL as a re­sult of a click, then that should be a link in­stead.

ARIA (Ac­ces­si­ble Rich In­ter­net Ap­pli­ca­tions) is a spec­i­fi­ca­tion for as­sis­tive HTML at­tributes which can be ap­plied to your HTML. The im­ple­men­ta­tion of the spec­i­fi­ca­tion is split into two con­cerns: roles and state at­tributes. The role at­tribute an­nounces and pro­vides as­sis­tive nav­i­ga­tion to spe­cial­ity el­e­ments and wrap­pers. There are many state at­tributes, but the one I use most of­ten is aria-hid­den=”true”. This blocks a screen reader from read­ing any­thing within that el­e­ment. This sounds de­struc­tive, but it’s re­ally help­ful when hid­ing col­lapsed con­tent.

One big dif­fer­ence be­tween a client-side app and a typ­i­cal site is the fre­quent change of con­tent. This is fab­u­lous, but only when you can see (and ex­pect) the change. For screen reader users, los­ing the page re­fresh means los­ing a clear di­vi­sion be­tween new pages and data. To make this bet­ter, an­nounce when data is chang­ing. Cre­ate an el­e­ment to­ward the top of your app with the at­tribute aria-live=”po­lite” and con­stantly push new mes­sages into that el­e­ment.

An ap­pli­ca­tion may also have more mov­ing el­e­ments, like modals or slide-out nav­i­ga­tions. As you are open­ing and clos­ing these things, make sure that you’re man­ag­ing the user’s fo­cus. I’ll use a modal as an ex­am­ple. When you open a modal, move the fo­cus to the first item in the modal; “trap” the fo­cus within the modal while it’s open; and, on close, move the fo­cus back to the but­ton that trig­gered the modal. This helps main­tain a pre­dictable, us­able key­board and screen reader ex­pe­ri­ence.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.