EIR Accessibility Policy, Chapter 5 - Software Applications (Including Mobile Apps)

In This Chapter

In evaluating the accessibility of software, we must consider three standpoints:

  • The purpose of using the software: What tasks does it let us get done? What problems does it solve? From this standpoint, consider whether the software poses one or more barriers to completing the associated task. If so, consider the requirements an acceptable alternative means of access must meet. Section 5.1, Software Categories, evaluates software from this standpoint.
  • The means of acquiring and updating the software: Is it acquired as a one-time purchase, as a subscription, or as a free download? Are updates provided periodically and their implementation left up to the customer, or are they continually pushed in such a way that only the latest version is ever available? These factors determine the methods and documentation necessary to determine the accessibility of the software. Section 5.2, General Guidelines, evaluates software from this standpoint.
  • The risk to the agency when software fails to comply with accessibility standards. Section 5.3, Risk, addresses this aspect of software and accessibility.

5.1 Software Categories

  • Authoring software for creating documents, presentations, spreadsheets, graphic files, eLearning content, multimedia, reports, websites, and so forth.
    • Examples:
      • Microsoft Office
      • Adobe Creative Cloud
      • Drupal, SharePoint, and other CMS software
      • LMS systems, such as Moodle
      • eLearning authoring programs, such as SoftChalk and Adobe Captivate
      • Audio/visual authoring programs, such as Camtasia and Final Cut Pro
    • Accessibility documentation from the vendor—for example, a voluntary product accessibility template (VPAT®) completed in sufficient detail—must be reviewed to determine the compliance level of the software. If the vendor does not supply any accessibility documentation, an exception is required.
    • Guidelines must be developed for using the software to create accessible content. These guidelines must be provided to anyone who has the software installed on their assigned workstation.
    • If the software cannot create accessible content, procedures must be in place to ensure that all content created using the software has an accessible alternative.
      • Examples:
        • Include metadata in files produced with Adobe Photoshop. This metadata should succinctly describe the image to a person who cannot see the image.
        • Create a separate accessible version of training created using Articulate.
    • When software is being considered for purchase, staff must research what other software is available in the marketplace. If the authoring software cannot create accessible output or if the user interface is not accessible, they must document this research.
      • If the user interface is not accessible and there is no accessible alternative, an exception must be approved prior to purchase.
      • If the output of the software is not or cannot be made accessible, an exception must be in place. The exception must include a requirement that anyone using this software is required to create an accessible alternative for the content that is being created. A business process must be in place to enforce the creation of this alternative content.
    • If the authoring software being considered for purchase can be used with assistive technology to create accessible output, no exception is required. In other words, if no alternative means of access is needed, no exception is required. This is true even if the vendor’s accessibility documentation identifies technical failures of the software when reviewed against accessibility standards.
  • Embedded software
    • Software, code libraries, and frameworks included in applications developed for use by the agency
    • Examples:
      • Tableau
      • Crystal Reports
      • AddThis
      • JQuery
      • Bootstrap
      • Drupal
    • Accessibility documentation that covers the following is required:
      • Accessibility compliance of the software.
      • Accessibility compliance of the output from the software. For example, for a plug-in that generates PDF reports, the accessibility compliance of the report; for a plug-in that creates a dashboard interface, the accessibility compliance of the dashboard.
      • Instructions to developers for ensuring that the output is accessible.
    • For purchased software, the accessibility documentation must be provided by the vendor prior to purchase. Otherwise, an approved exception is required to complete the purchase.
    • For open source software, accessibility documentation must be established through research or testing before application development may begin.
    • An exception must be approved before development may begin if the accessibility documentation:
      • is not available,
      • indicates the software is not compliant,
      • indicates the output is not compliant, or
      • does not include developer guidelines for creating accessible output.
  • Assistive technology
    • Software purchased as an assistive technology does not require accessibility documentation nor is an exception required for purchase.
    • Examples:
      • Screen reading software
      • Screen magnification software
      • Voice recognition software
      • Predictive text software
  • Other
    • If the software has a user interface:
      • The supplier of the software must provide accessibility documentation. Otherwise, an approved exception is required prior to purchase.
      • If the software is not purchased (free open source) the exception is required prior to installation or deployment.
      • If the documentation does not indicate that the software is compliant then an exception is required prior to purchase.

5.2 General Guidelines

Before software may be put into use, its accessibility must be evaluated and documented. The method for evaluating accessibility and the acceptable means of documenting the results depends on the means by which the software is acquired. Follow these general guidelines to ensure compliance with Chapter 2, Purchasing and Contracts for Information and Communication Technologies, Section 2.3, Documenting the Purchase Process.

5.2.1 Commercial off the Shelf Software (COTS)

Purchased or leased software that:

  • Is installed on individual workstations or servers
  • Cannot be modified or changed by HHS

Accessibility compliance of COTS software will be determined from a VPAT® (voluntary product accessibility template) or other accessibility information provided by the vendor.

If the vendor certifies that the software is fully compliant no exception is required.

If the vendor certifies that the software is partially compliant, the agency accessibility coordinator will determine whether an exception will be required in the context of how the software will be used. For example if the expected use of the software will not require the use of inaccessible features then an exception will not be required. If the software is used to produce, manage, or modify electronic data, content, or applications and does not produce accessible output then an exception is required.

If no accessibility documentation is provided by the vendor then the software will be assumed to be non-compliant and an exception is required prior to the purchase or installation of the software.

5.2.2 Software as a Service (SaaS)

SaaS is software and services that are accessed through the Internet.

  • This software may be accessed via a web browser or a VPN or telnet client.
  • This software may be updated without notice from the vendor.
  • This software may be updated frequently, even daily.

Accessibility compliance of SaaS software will be determined from a VPAT® or other accessibility information provided by the vendor.

If the vendor certifies that the SaaS is fully compliant no exception is required.

If the vendor certifies that the SaaS is partially compliant, the agency accessibility coordinator will determine whether an exception will be required in the context of how the SaaS will be used. For example if the expected use of the SaaS will not require the use of inaccessible features then an exception will not be required. If the SaaS is used to produce, manage, or modify electronic data, content, or applications and does not produce accessible output then an exception is required.

If the vendor does not provide compliance information then the SaaS will be deemed to be non-compliant and will require an exception prior to purchase or use.

Accessibility compliance is not required for the use of unapproved or free services by an individual. See the agency Information Security Agreement for more information about the use of external software and services.

Staff may not require other staff members with disabilities to use websites or services that are not compatible with their assistive technologies.

5.2.3 Mobile Applications

5.2.3.1 Developed by or for the Agency

  • Apps must meet all of the requirements on the HHS mobile checklist.
  • As part of complying with Chapter 2, Purchasing and Contracts for Information and Communication Technology, Section 2.2, Purchasing ICT, during the development process, developers will perform functional accessibility testing with accessibility testing suites appropriate to the platform.
  • Documentation of the accessibility test results must be provided to the agency accessibility coordinator before the app may be released.
  • If documentation of test results is not available, the app will be deemed to be non-compliant and will require an exception and a fully accessible alternative.
  • A fully accessible web-based application offering the same features or functionality may be provided as an alternative to the mobile application.

5.2.3.2 Other Apps Used by HHS Staff to Perform Essential Job Functions

Staff members with disabilities will not be required to use mobile applications that are not compatible with the assistive technology that they use.

Before an app is approved for use on agency-owned or -leased mobile devices, IT must ensure that the app is accessible or that an accessible alternative is available.

If people with disabilities are unable to use an app required by their job, then an exception request must be obtained and an accessible alternative offering the same features or functionality must be provided. If appropriate the identified accessible app should become the agency standard app for delivering the functionality to the mobile device. If no accessible app is available to meet that functionality then an alternative business process may be substituted.

5.2.4 Developed, Modified, or Customized Software

When we develop, modify, or customize software, the project development team must include a project accessibility lead and must determine the accessibility of the base platform and any components being used. For each platform or component that is not in compliance with this policy:

  • An exception must be approved before further development may proceed.
  • An alternative means of access must be incorporated into the software design.

All developments, modifications, and customizations must satisfy the technical specifications in Chapter 11 of this policy. Otherwise, an exception must be approved before deployment.

Accessibility testing must be performed and documented throughout the design and development process.

5.3 Managing Risk

Project design documentation that identifies methods for implementing accessibility for all interface elements will be maintained for all development projects.

If the design documentation does not include accessibility implementation details then the project/contract manager will:

  • Notify the agency accessibility coordinator that the project design does not include accessibility design solutions for the user interface.

The agency accessibility coordinator will:

  • Conduct research to determine if either design patterns or code modules exist that would allow the user interface features to be implemented in an accessible manner and provide this information to the project/contract manager.

If accessible design patterns are identified then the project manager will:

  • Direct the design and development team to add the chosen method to the design documentation
  • Or place the project on hold and apply for an exception to the accessibility policy from the Executive Commissioner. The project cannot continue until the exception has been approved.

If accessible design patterns are not identified, then the project manager will:

  • Place the project on hold and apply for an exception the accessibility policy from the Executive Commissioner. The project cannot continue until the exception has been approved.