Creating Accessible Oracle JET Applications

Note: This learning path has a prerequisite, Develop a Web Application in Oracle JavaScript Extension Toolkit (Oracle JET), which should be completed prior to beginning this course.

Introduction to Accessibility

Now that you have a basic understanding of how to use Oracle JET to develop web applications, it is time to address the specialized needs of nearly 10–20 percent of your target audience—those with disabilities. According to a 2014 article published by the World Health Organization, approximately 15 percent of the world’s population has some form of disability, and that number grows with an ever-aging population.

History

The modern concept of accessibility originated in the late 1960s as a grassroots movement on college campuses and in local communities to address the rights of disabled individuals seeking physical access to public buildings. This access included ramps along public walkways, entrances, automatic doors, and Braille labels in elevators to public, governmental, and college buildings.

Equal Access Legislation

Today, “access” incorporates both physical access to structures and access to the current technological landscape of PCs, laptops, tablets, smartphones, and voice-controlled devices such as Amazon Alexa. Equal-access legislation continues to address the issues of physical access and the technology upon which we are dependent.

Software accessibility is mandated by civil laws in many countries around the globe. For example:

• The Americans with Disabilities Act in the United States
• The Accessibility for Ontarians with Disabilities Act in Ontario, Canada
• The Equality Act of 2010 in the United Kingdom

Challenges to Access - Types of Obstacles

As web application designers and developers, we need to be aware that disabled clients face obstacles when accessing technology. Consider the following:

• A user cannot manipulate the mouse due to impaired mobility (congenital birth defect, Lou Gehrig’s disease, Parkinson’s disease, rheumatoid arthritis, injury, or an aging-related deficit). How would such a user activate text that has an on-click event tied to it?
• A user is visually impaired and cannot see that the instructions for using a page or form follow after the content. How would the user know to read the entire page to find the instructions?
• A user has low vision and uses a screen magnifier that focuses on and enlarges only a small portion of the screen at one time. Given the limitations of the magnifier, how would the user know whether a message pops up elsewhere on the screen?
• A user is color-blind and cannot distinguish between certain colors. How would the user know which is the red, blue, or green button referenced in the text of the page?

These are just a few illustrations of the concerns that a developer needs to address while crafting an accessible web application. This learning path provides clear methods for coding and for testing for accessibility in order to comply with the most current standards set by the Web Content Accessibility Guidelines (WCAG) version 2.1.

It is prudent to look closely at the guidelines mentioned above, since they form the basis of our work in accessibility.

The Web Content Accessibility Guidelines (WCAG)

The World Wide Web Consortium (W3C) has created a set of standards called the Web Content Accessibility Guidelines (WCAG) that provide very specific rules for how to make websites and web applications accessible. These guidelines form the basis for this learning path.

The WCAG standards focus on four areas of a web application or website:

1. Perceivability: Can the interface be perceived by a vast majority of individuals regardless of disabilities?

   • Color contrast ratios that work well for those with low vision
   • Simplicity of layout that works well for those with cognitive deficits

2. Operability: Can individuals interact with the interface regardless of disabilities?

   • Keyboard-only access: Navigate and operate the interface without the use of a mouse
   • Voice-only access: Operate the interface by voice input only

3. Understandability: Is the interface easily understood by individuals regardless of disabilities?

   • The content is written to be understood by individuals with cognitive impairments
   • The interface is understood by an individual using a screen reader

4. Robustness: Does the interface support a variety of user agents (browsers, devices, and assistive technologies)?

If the WCAG criteria are met, then web applications and websites should pass all legal requirements as well.

The Cost of Accessibility

It should be noted that accessibility should never be an afterthought when writing code. Though the development process is longer, it is more cost-effective to write accessibility features into the code during the development phase than it is to modify an existing application.

Developers often complain at the need to accommodate the special requirements of an arguably small population. When implemented properly, accessible code actually makes an application easier for everyone to use—not just the disabled. For example, by simplifying the interface and by choosing colors with higher contrast ratios, applications on mobile devices or older browsers are simpler to use.

1, 2, 3 Steps to Success

Accessibility begins at the design phase. Designers create a blueprint of what the program does. They should weave accessibility throughout the design to ensure that the plan includes effective mechanics for keyboard-only access. This type of access allows for alternative input devices for those with limited or with no use of their hands.

Developers need to have both a strong working knowledge of how to code for accessibility (front-end) and a technical awareness of how to test for accessibility (back-end).

Quality assurance (QA) engineers need to speak the language of accessibility. They, like developers, need to understand and perform accessibility testing alongside the normal testing for functionality and security. QA professionals are the buffer between the software that is released and the potential for litigation if accessibility guidelines are not met.

Notes to Notice

Oracle JET is open to the public to use in non-Oracle applications and websites. Therefore, WCAG version 2.1 must be adhered to when writing Oracle JET applications.

This learning path focuses primarily on those aspects of accessibility that apply to keyboard access and screen-reader use. This path does not focus on the cognitive aspects of designing or building an Oracle JET application.