EIR Accessibility Policy, Chapter 9 - Monitoring Compliance

In This Chapter

Each Health and Human Services (HHS) agency will test all new or changed Information and Communications Technology (ICT) using Web Content Accessibility Guidelines (WCAG) 2.0 Level AA compliance tools to validate compliance with Texas web accessibility standards. Additional information about testing tools and resources are available at the HHS Accessibility Center and at the World Wide Web Consortium’s (WC3) websiteExternal site.

9.1 Compliance Monitoring Policy

To ensure that HHS ICT is designed with consideration for the widest range of users’ abilities, HHS agencies must follow the monitoring provisions of this policy manual.

9.2 Roles and Responsibilities

  • responsible managers;
  • project managers;
  • content contributors—for example,
    • authors,
    • reviewers, or
    • managers with content responsibility;
  • user interface designers;
  • developers—for example,
    • website developers,
    • multimedia developers,
    • eLearning developers,
    • software application developers, or
    • web application developers;
  • quality assurance;
  • webmasters and other publishers.

Not every process of developing, procuring, or modifying ICT will include all of these roles. In many such processes, two or more of these roles will be filled by the same person.

9.2.1 Responsible Managers

The manager or the director of the department or program who initiates the request for, or creates the ICT has these responsibilities:

  • Ensure that all supervised staff understand and follow the sections of the accessibility policy for ICT created, maintained or purchased by their department.
  • Determine training needs and acquiring training for staff so that they can perform their job duties in compliance with the accessibility policy.
  • Communicate needs for training, consulting and support with the Civil Rights Office Accessibility Team.
  • Allocate budget to pay for accessibility development, remediation and training as appropriate.
  • Allocate staff resources to ensure compliance with the accessibility policy for ICT purchased, maintained or created within the department or program under the manager’s supervision.
  • Request or purchase software that allows their staff to create and maintain ICT that complies with the accessibility policy.

9.2.2 Project Managers

Managers of ICT projects involving HHS staff, contractors, and vendors have these responsibilities:

  • Ensure that the project plan calls for accessibility to be considered throughout all phases.
  • Document that accessibility has been verified as part of content creation, interface design, development, and quality assurance.
  • Ensure that each defect found during the validation process has been documented.
  • For any defect that cannot be resolved, ensure that the HHS Civil Rights Office Accessibility Team has been notified in writing that an exception must be obtained. Include this notice in the project accessibility documentation.

9.2.3 Content Contributors

Each HHS employee who creates or contributes content to be used in ICT has these responsibilities:

  • Verify readability of wording.
  • Confirm accuracy of captions and alternative text.
  • Use proper semantic structure.
  • appropriate format (chart, table, or both).
  • Ensure that any shortcomings are documented and brought to the attention of the project manager.

9.2.4 User Interface Designers

User interface designers have these responsibilities:

  • Verify that the color palette meets contrast requirements when used as intended.
  • Provide controls whose interactions can be performed with a keyboard and a mouse.
  • Ensure accessibility requirements for each interactive feature are included in the design specifications.
  • Ensure that a library of design patterns with known accessibility is followed.
  • Ensure that the accessibility of each proposed new pattern is documented.
  • Ensure that any failures are documented and brought to the attention of the project manager.

9.2.5 Developers

Developers of ICT have these responsibilities:

  • Verify design and content are coded to support accessibility.
  • Use automated tools to validate syntax.
  • Verify that any custom controls are coded to established accessible design patterns—for example, that widgets are implemented using W3C ARIA design patterns.
  • Verify that there is a valid business reason for using a non-standard control when a standard HTML control would accomplish the same function—for example, before using <span role="button">, document the business reason for not using the native HTML element, <input type="button">.
  • Ensure that any defects are documented and brought to the attention of the project manager.

9.2.6 Quality Assurance

Quality assurance entails assuming these roles in producing ICT:

  • Verify that all functionality works with a keyboard.
  • Validate that code is used to specification.
  • Verify that authors, interface designers, and developers have performed their respective accessibility tests and that any defects found have been documented and brought to the attention of the project manager.
  • Ensure that the functional performance objectives of Section 508 are met. These objectives are:
    1. At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.
    2. At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who are visually impaired shall be provided.
    3. At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided.
    4. Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided.
    5. At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided.
    6. At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided.

9.2.7 Webmasters and Other Publishers

As the last person to review ICT before its publication, deployment, or release, the webmaster or publisher has these responsibilities:

  • Verify that authors, interface designers, developers, and quality assurance staff have performed their respective accessibility tests and that any defects found have been documented and brought to the attention of the project manager.
  • If any defects have not been resolved, verify that an accessibility exception has been approved. Otherwise, notify the project manager and agency accessibility coordinator.

9.3 Automated Testing and Validation Tools

Accessibility evaluation tools cannot independently determine the accessibility of any ICT; they can only assist in doing so. Any automated testing tool used for accessibility compliance must be able to:

  • perform automatic accessibility checks when possible, and
  • indicate where human evaluation is required.

9.4 Manual Testing and Validation

Because automated testing tools cannot replace a human being for checking some elements of accessibility, HHS agencies and contracted vendors should organize manual testing of web content for accessibility compliance to complement automated testing. Testing is a recursive process wherein accessibility testers work with developers and content creators to identify accessibility errors, which are then fixed and retested for validation. Validation is the final accessibility test before release, publication, or purchase of the ICT.

Common examples where human judgment and manual testing are required for accessibility testing include these instances:

  • Although color contrast analysis uses an automated tool, it can only be accomplished by a manual tester who can appropriately identify which color pairs are used as foreground and background for meaningful content.
  • Automated testing tools cannot identify text in an image.
  • An image containing alternative text or "alt text" requires human judgment to determine whether that text will convey the appropriate meaning to end users.
  • An automated testing tool cannot indicate whether heading structure is used appropriately.

For more information, see the WCAG 2.0 Checklist for HHS Agencies and the HHS Recommended Web Development Testing Process.

9.5 Purchased Electronic Products

All ICT purchasing decisions must be made using vendor-supplied testing data. If completed in sufficient detail, a VPAT® (voluntary product accessibility template) may be a means of supplying such data. When vendors fail to supply testing data, the agency will assume that the product being purchased does not meet the accessibility requirements. Therefore, an exception is required.

For more information, see Chapter 2, Purchasing and Contracts for Information and Communication Technology.

9.6 Monitoring Accessibility Compliance Sitewide

The agency will procure a sitewide testing tool or service that will monitor the accessibility compliance of static content on agency Internet, extranet, and intranet sites. Compliance status will be reported on a monthly basis at the accessibility workgroup meeting. The workgroup will determine priorities for further testing and remediation.

See Chapter 10, Planning and Remediation.

9.7 Resources and Links

For more information about testing and validation, see the following: