Web Accessibility: My share of experiences (Part 1)
We just wrapped up building a web application where section 508 compliance (accessibility) was an implicit requirement. When we started building the application, angular 2 has not yet released and since angular JS was going to get obsolete we stick our grounds to standard tech pack such as JQuery, bootstrap, HTML5, CSS3, Spring MVC, REST, JPA, JAVA J2EE for building web application. The most challenging part of this project was, apart from making the application attractive, user friendly, easy to use and robust, it should still be fully compliant with section 508.
Often, during development, our first target is to get the functionality (or what business requirement says) and then we scramble across at the end to meet the implicit accessibility requirements. Often lead to last minute major changes and may involve restructure of whole app or leave accessibility for future releases.
One of the first thing that our accessibility coordinator mentioned to us was to develop a web application with a mind set to be inclusive during design and development. What it means is during the design spikes apart from covering the business requirements it is imperative to cover accessibility requirements such is colors contrasts, layout, navigation etc., and during code development include appropriately WAI-ARIA attributes, roles as required.
Inclusive Design & Development:
Landmark Regions:
During design spikes, as we logically divide a web page into regions such as header region, footer region, menu region, main region, complementary etc. Here, implicitly from accessibility perspective, we have identified our “Landmark Regions”. Here, by using native DOM elements or by using role attribute we can let screen readers know how the element should be identified. These landmark regions also enable screen reader users to quickly jump to that section instead of tabbing throughout the page.
Form Fields:
In general, any form field will have a label tag along with associated input element. Here accessibility can be simply achieved by adding a for attribute in label tag and refer to the corresponding input id. If this notion is followed, screen readers will automatically pick these elements and announce them appropriately
<div class="form-group">
<label for="exampleInputEmail1">Email address</label><input type="email" class="form-control" id="exampleInputEmail1" placeholder="Email">
</div>Screen reader (NVDA) reads as: Email address edit Email blank
When the focus is on the input box, screen reader announces its label as ‘Email Address”, input type as ‘email’ and ‘edit’ as indication that it is an editable field followed by placeholder which in this case is “Email” and the current value is blank.
Live Regions:
When we have a web application where user has a lot of interactions, for instance, when user does a search with a certain criterion, there are two possibilities with one as “no results found” or results found, and some set are shown to the user. For obvious reasons, regular users can distinguish when results appear and doesn’t require any notification indicating the same. For screen reader users unless notified about new content availability they wouldn’t know. Here, by using “aria-live” attribute, users can be notified as and when content is made available.
<div aria-live="polite" role="status">No results found.</div>Build reusable Accessible components:
Although most of the UI framework libraries or plugins like bootstrap, datatables etc., do provide out of box components with limited accessibility features which could be directly used in any application. However, quite often they do lack certain accessibility details which may be required for it to be fully compliant. There are multiple ways to address this issue where first is to report an issue with respective library group and wait for it to be addressed. Secondly, write a wrapper around it and include all the missing accessibility related attributes as required. And thirdly, to re-write the whole component in your own format. For our application, we followed all the above three where ever it made sense.
Below is one example which gives some insight on what type of issues we encountered and steps we followed to mitigate the issue:
When using bootstrap modal window, we identified that the sync between keyboard navigation and visual representation is lost when users use up/down arrow to read the DOM nodes. From visual perspective, when modal window is shown, background is grayed out giving an impression that only the content modal window is usable.However, for screen reader it is still accessible, and it starts reading the next element in the DOM tree node as it reaches the end of modal window node. We could address this issue by applying “aria-hidden=true” to all the root nodes inside body other than modal window when modal is shown. Since this is commonly used feature throughout the application we wrote a wrapper which creates the modal window DOM as required and attaches it to end of body. Whenever it is shown/hidden, aria-hidden attribute is set to true/false applied appropriately.
E.g.,
Let’s assume we have a body tag with header, main and div[role= ‘contentinfo’] and a modal window div node inside body.
In the next part, will showcase some example custom components such as autocomplete manual selection combobox, drag and drop, Two-selection list boxes etc., Although we developed the app in native Javascript and associated libraries, will try to show case these with examples in Angular 6 and prvoide link to corresponding github project.
