Celebrating Global Accessibility Awareness Day – How LEADTOOLS Makes Applications More Accessible

Incorporating accessibility features into application development needs to be an integral part of the development process. Not all software is initially designed with accessibility in mind, but because the ability to access and utilize features is not a shared experience for all individuals, it must be taken into consideration. With today being Global Accessibility Awareness Day, we want to highlight one of the many ways that LEADTOOLS SDKs help make technology and applications more accessible to a larger audience.

The LEADTOOLS Document Viewer is an OEM-ready, document-viewing solution with support for over 165 format types and robust features like text search, annotations, eSignatures, speech-to-text, and screen reading. With accessibility in mind, we recently updated our LEADTOOLS Document Viewer Demo to use ARIA (Accessible Rich Internet Applications) attributes so that users are able to tab through menu items while a screen reader easily reads the items aloud. This is extremely helpful for anyone with vision impairment to be able to hear the items audibly. When developers buy LEADTOOLS, they get access to all of our fully-sourced demos and many will just package it up with some customizations for their particular application needs. Having these ARIA attributes already in this demo means that many more applications developed with LEADTOOLS will also have them!

The Game Plan

In fact, implementing ARIA attributes into the Document Viewer was one of the first projects I worked on here at LEAD. The game plan was very simple – when something was updated on the screen, the screen reader would need to be able to recognize it. I needed a way to ensure that disabled elements were able to be read and highlighted as well. Luckily, the MDN Web Docs for Aria states/properties had me covered. The most important piece would be the aria-live tag (which you will see in the divs) as this allows the screen reader to know which parts of the page to read.

The Invisible Divs

Like the header says, the answer to the first part of the game plan was the “hidden” div tags which would have the text updated as events occurred around the application (events such as zoom-in, page orientation change, selected text, etc.). These divs all look the same, except for a few id name changes, and they all have the same styling applied to them so they are un-seen and do not interrupt the application layout. Hiding these divs allows there to be one location from which the screen reader can read.


//styling for the divs below
.srOnly {
    position: absolute;
    left: -10000px;
    width: 1px;
    height: 1px;
    overflow: hidden;
}
<div role="region" id="srOnly-zoom" class="srOnly" aria-live="polite"/>
<div role="region" id="srOnly-rotate" class="srOnly" aria-live="polite"/>

Next we need a way to generate the text for the screen reader to read. We do this by latching onto what is being changed and updating the corresponding div to the new value. The screen reader notices each change and reads out the new value to the user. We can look at a small sample of this with the zoom and page rotation lines of code:


//We grab corresponding hidden div we initialized before and assign it to a variable  
var srOnlyZoom = document.getElementById("srOnly-zoom");
var srOnlyRotate = document.getElementById("srOnly-rotate");
//Now we check to see if the current value has changed, and if so then we change the value in the hidden div to match the newly changed value

//Check scale/zoom
if (this._oldScaleFactor !== this._documentViewer.view.imageViewer.scaleFactor) {
     var x = this._documentViewer.view.imageViewer.scaleFactor * 100;
     srOnlyZoom.innerHTML = "Currently zoomed at " + x.toFixed(1) + " %";
}
//Check rotate
if (this._oldRotateAngle !== this._documentViewer.view.imageViewer.activeItem.rotateAngle) {
     srOnlyRotate.innerHTML = "The current page is rotated by " + this._documentViewer.view.imageViewer.activeItem.rotateAngle + " degrees";
}

When those values in the hidden div change, the screen reader will catch it and let the user know!

What About Tabbed Menu Items?

There is a difference between HTML elements with the tag disabled and aria-disabled. They may look similar, but their functionality is quite different. Below you will find code that shows their similar declarations. Notice how the disabled elements cannot be focused whereas aria-disabled ones can, meaning that you can tab through aria-disabled elements but not disabled elements – an important detail since those with vision impairment could potentially not know if certain buttons even exist on regularly disabled buttons.


<div role="button" disabled>Sample Button</div>
<div role="button" aria-disabled="true" tabindex="-1">Sample Button</div>

With a little styling and JavaScript, we can mimic the looks and functionality of a regular disabled button but have it tab-able with an aria-disabled button. The code below showcases the styling to mimic a disabled button:


//styling to mimic disabled button
[aria-disabled="true"] {
    opacity: 0.5;
    color: #666666;
    cursor: not-allowed;
}

//code to enable/disable functionality depending on the state aria-disabled is in 
public preventClicks(clickable: any): boolean {
    if (clickable.attr("aria-disabled") == "true") {
        return false;            
    } else {
        return true;
    }
}

Accessibility Matters: Let’s All Do Our Part!

This is just one easy way to implement accessibility into application design and development. Another? There are Alt tags on the images used throughout the document viewer in order to serve the same purpose of being able to be read aloud by a screen reader. These are just a couple of the many ways developers using LEADTOOLS are able, and encouraged, to build more accessible and inclusive applications! Be sure to keep accessibility in mind when building your applications so that more users will be able to navigate and use your apps.

Download our FREE 60-day evaluation SDK to test all of our features and see how our SDK can help you build better (and more accessible) apps. As mentioned above, you’ll also receive access to all of our fully-sourced demos, tutorials, and more!

Not sure where to start? Schedule a walk-through with our support team to check out our many features that will expedite your application development.

For pricing or licensing questions, contact our sales team via email or call us at 704-332-5532. Be sure to check out our product wizard and pricing estimator as well.

About 

This entry was posted in General. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *