Oracle Accessibility Policies and Standards Interpretation

Oracle’s Accessibility Philosophy and Policies

Oracle is committed to building standards-based products to help customers reduce complexity and get the most out of existing technology investments, and this commitment extends to our approach to accessibility. Oracle uses industry-standard technologies such as HTML, JavaScript and Java to render most user interfaces, and we follow internationally-recognized accessibility standards allowing support for a broad range of assistive technology (AT) such as screen readers, screen magnifiers, and voice recognition.

Accessibility has presented unique challenges to the Information and Communication Technology (ICT) community as a whole due to the range of laws and guidelines related to it, and the rapid pace of changes in technology, and the impact across nearly every aspect of product development from initial design through Support. Learn how Oracle is meeting those challenges below.

Accessibility Policies

Guidelines and Standards

The Oracle Accessibility Guidelines are based on the 2017 Revised Section 508 of the Rehabilitation Act of 1973 as amended, and the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines version 2.1 guidelines at the AA level (WCAG 2.1 AA).

Oracle is committed to developing new products in conformance with Revised Section 508 and the WCAG 2.1 AA standards to the extent practicable. As new products and revisions are released that conform to the Revised Section 508 and WCAG 2.1 standards, we will publish Accessibility Conformance Reports (ACRs) based on the Voluntary Product Accessibility Templates (VPATs) that use the updated VPAT 2.x template. Until then we have VPATs that include a table of all of the WCAG 2.0 'A' and 'AA' standards, in addition to the Section 508 standards.

In 2017 the U.S. Access Board announced the Revised Section 508 standard that was based on the WCAG 2.0 AA standards. In 2014, the initial version of the European Union standard EN 301 549 ‘Accessibility requirements suitable for public procurement of ICT products and services in Europe,’ issued in response to Mandate 376, was based on the WCAG 2.0 AA standards. It was updated in 2019 to include WCAG 2.1. EN 301 549 Accessibility requirements suitable for public procurement of ICT products and services in Europe (PDF) - V3.1.1 (2019-11). Oracle has been an active participant in the development of these guidelines and is closely tracking their progress.

Any standard is subject to some amount of interpretation; see Standards Interpretation for a detailed look at how Oracle addresses specific standards.

Accessibility Status

Oracle products are tested for accessibility using a variety of techniques including automated tools, expert heuristic review, visual inspection, manual operation, and testing with various AT by both disabled and non-disabled users. We report the outcome of that testing using the Voluntary Product Accessibility Template (VPAT) to create the Accessibility Conformance Report (ACR). The VPAT was developed by ITI and GSA to assist Federal contracting officials and other buyers in making preliminary assessments regarding the availability of commercial ICT products and services with features that support accessibility. See Accessibility Conformance Reports for an in-depth discussion of how we use the VPAT, and to locate the ACRs for Oracle products.

Accessible Customer Service Plan for Ontario, Canada

Oracle’s Accessible Customer Service Plan for Ontario, Canada (PDF) outlines the policies, practices and procedures approved by Oracle in order to meet the obligations under the Accessibility for Ontarians with Disabilities Act, 2005 (AODA) and specifically Regulation 165/16. Oracle’s Multi-Year Accessibility Plan (PDF) outlines Oracle’s commitment to compliance to Ontario’s accessibility standards.

Updates to the Accessibility Standards

Oracle has been an active participant in the development of the WCAG 2.2 accessibility guidelines, and will implement the additional WCAG 2.2 success criteria after WCAG 2.2 is published.

Oracle’s interpretation and position on several accessibility standards and guidance included in WCAG 2.2 or ARIA

Identify Input Purpose

Relevant standards

• https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html

Oracle’s position

Some customers have interpreted this standard to mean that all input fields require the input purpose to be identified. The standard is explicitly scoped for input fields that collect personal information about the user. Oracle is committed to identifying the input purpose of fields that collect such personal information.

On focus and On input

Relevant standards

• Understanding Success Criterion 3.2.1: On Focus | WAI | W3C
• Understanding Success Criterion 3.2.2: On Input | WAI | W3C

Oracle's position

Some customers have interpreted On Focus and On Input success criteria to broadly apply to changes in both content and context. Oracle’s interpretation is that these standards apply specifically to changes of context, and do not apply to changes of content that do not change the meaning of a page.

Accessible Rich Internet Applications Authoring Practice Guide (ARIA APG)

Relevant standards

• None

Oracle’s position

Some customers interpret the Accessible Rich Internet Applications Authoring Practice Guide (ARIA APG) as a normative document whose pattern examples must be precisely followed. The ARIA APG is non-normative. Patterns found in the APG are example implementations and do not represent the only valid patterns. “The APG does not specify normative requirements and thus does not have a conformance model.” See APG is Not a Normative Standard for more information.

Oracle’s Archived interpretation and position on several legacy accessibility standards included in Section 508 or WCAG 1.0

We provide this interpretation in response to customer inquiries regarding specific HTML content, particularly when automated validation tools indicate non-conformance. The majority of issues arise from the fact that the majority of these regulations and standards were written in 1999 or 2001, and the technology of browsers and assistive technology (AT) has advanced significantly since then. Oracle welcomes the rewrites of both Section 508 and WCAG, which modify or clarify many of the provisions discussed below to take into account technological changes, and we are actively participating on the committees that are effecting those changes.

For brevity, a reference such as ‘1194.22(l)’ refers to provision 1194.22(l) in the Section 508 standards (which can be found at Part 1194 of Title 36 of the Code of Federal Regulations), and a reference such as ‘WCAG 1.0 #6.3’ refers to standard 6.3 of WCAG 1.0.

Scripting, Especially the Use of JavaScript

Relevant standards

• 1194.22(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
• WCAG 1.0 #6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
• WCAG 1.0 #8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.

Oracle’s position

Many customers read these standards as requiring that a product can only be accessible when scripting is disabled. This is not the case. Both the section 508 standard and WCAG 1.0 allow the use of scripts that are directly accessible or compatible with AT. Most, if not all, Oracle products require javascript and rely on browsers that support javascript. Oracle believes that javascript not only can be made accessible, it improves the accessibility experience. For example, by changing partial content on a page rather than reloading an entire page, it prevents the user from having to browse and navigate a completely 'new' page in order to find a small section that has been revised. The move to rich client interfaces necessitates increased use of scripting, and Oracle is committed to making such code usable by people with disabilities, or we will generate different code that results in a comparable experience.

Validating to Published Formal Grammars

Relevant standards

• WCAG 1.0 #3.2 Create documents that validate to published formal grammars.

Oracle’s position

Several HTML tags have no bearing on accessibility, and browsers are known to interpret tags differently. The key point is that the tags related to accessibility must be interpreted unambiguously by the browser and assistive technology. Oracle's HTML may not exactly adhere to a formal grammar for a variety of reasons:

• In various cases we need to add extra information onto the HTML DOM and we use “expandos” for this purpose.
• As recommended by W3C WAI-ARIA, we use tabIndex="-1" to make certain elements focusable.
• Because browsers operate differently, we may optimize the HTML to account for specific browser behavior.

Provided the customer is current on technical support, Oracle will resolve any issue where 'non-standard' HTML impedes accessibility, in accordance with Oracle's standard technical support policies, but Oracle will not necessarily correct 'invalid HTML' that is reported by an automated tool but has no negative ramifications on accessibility.

Device Independence

Relevant standards

• WCAG 1.0 #6.4 For scripts and applets, ensure that event handlers are input device-independent.
• WCAG 1.0 #9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.
• WCAG 1.0 #9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.

Oracle’s position

Some customers have interpreted these standards to mean that any operation that can only be performed with a mouse, such as a double-click, is prohibited. Oracle is committed to providing a rich user experience to all users, and in situations where actions require complex mouse actions such as double-click or drag-and-drop, alternative mechanisms that can be performed with the keyboard only will be provided.

Frames

Relevant standards

• 1194.22(i) Frames shall be titled with text that facilitates frame identification and navigation.
• WCAG 1.0 #12.1 Title each frame to facilitate frame identification and navigation.

Oracle's position

Oracle has encountered many situations where frames were viewed as either being a ‘violation’ of accessibility standards, or not considered ‘proper HTML.’ Oracle believes that frames are a legitimate part of HTML, and we only certify with browsers that support them. In our products, frames are properly marked up according to the relevant standards cited. One exception is the use of an iFrame, when it is being used simply to communicate with the server. In this case, Oracle intentionally does not title the frame so as to make the element invisible to the user (just as it is to a sighted user).

Style Sheets

Relevant standards

• 1194.22(d) Documents shall be organized so they are readable without requiring an associated style sheet.
• WCAG 1.0 #6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

Oracle’s position

Oracle interprets this standard to mean that information (‘content’) and presentation should be separated. For example, HTML should have semantic markup identifying the information, and an external style sheet should be used to render a particular look and feel. When a user accesses the page with assistive technology, the information must be communicated in a meaningful sequence. However, Oracle does not accept that the product must run with style sheets disabled in the browser, because:

• All modern browsers support style sheets
• Setting style attributes such as display:none in the page content is commonly used to hide content from all users; disabling style sheets completely will cause this information to erroneously appear
• Modern browsers support overriding the author style sheet with a user style sheet if required

Links to Plug-Ins

Relevant standards

• 1194.22(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with 1194.21(a) through (l).

Oracle’s position

Many plug-ins, such as Adobe's PDF viewer, are now ubiquitous, and are often pre-installed on computers. In some cases, such as with the Oracle JInitiator, the plug-in is shipped with the product and automatically installs itself. Furthermore, providing a link to a site outside a company firewall, or enabling a user to download and install a plug-in, may be in violation of corporate policy. Oracle products therefore will provide links to plug-ins that meet this standard when they are either not considered ubiquitous, or are not shipped with the product.

Skip Navigation

Relevant standards

• 1194.22(o) A method shall be provided that permits users to skip repetitive navigation links.

Oracle’s position

Many Oracle products provide a link that will move focus to the ‘main content’ of a page. However, Oracle is also aware that most AT supports a mechanism that allows the user to move to various sections of a page using standard structural markup tags. Oracle may, when appropriate, use this mechanism as a means of accomplishing the goal of this provision.