Web QA and Accessibility Tool SOW - FY23.docx

Web Accessibility and Quality Assurance (QA) Tool Requirements Document March 2023

The U.S. Department of Education (ED), Office of Communications and Outreach (OCO), has a need to obtain a Web Quality Assurance and Accessibility Tool. ED requires a software program or online service that shall support web content quality assurance and improve website user experience by identifying and fixing common errors like broken links, outdated content, and typos. In addition, the tool shall conduct a web accessibility evaluation to help ED determine if its web content meets accessibility guidelines. To be considered, quoted products must meet ALL the requirements identified below. The period of performance is a 12-month Base Year and one 12-month Option Year.

Web Quality Assurance and Accessibility Tool Requirements

1. General definition of requirement - SaaS web accessibility assessment and content QA tool with support for multiple domains.

1.1. The tool will run a scan at scheduled dates and times (defined intervals).

1.1.1. US Department of Education will be able to define scan intervals.

1.1.2. The tool will record a completion status for an instance of a scheduled report.

1.1.3. The tool will provide the capability for an application administrator to edit the report schedule.

1.1.4. The tool will provide the capability for the owner of a scheduled report to assign users to a report subscription (email).

1.2. Tool shall be able to provide a single report for all pages within a single domain (not necessarily including sub domains) irrespective of total site page count.

1.3. Tool should provide the ability to group and filter scan results by domain.

1.4. Within domains the tool should allow for the grouping of content into different categories based on specified meta tags, page paths, or some combination thereof.

1.5. All report views within the interface should be filterable by these defined content groups.

1.6. Tool should provide a dashboard to view results of periodic scans with information about accessibility and quality assurance (readability, misspellings, broken links, etc.) as well as the change in these measures over time.

1.7. Tool will be able to crawl sites by following seed links, from sitemaps uploaded to the tool, or from ED hosted sitemaps.

1.8. All graphical data views should have accompanying exportable reports in formats such as *.csv or *.xlxs.

1.9. The tool will provide the capability for application administrators to create and maintain user accounts within the system.

1.10. The tool should provide an Application Programming Interface (API) for Interoperability with other software.

1.11. The tool should support the option to add additional websites.

1.12. The tool should support an unlimited number of user accounts.

1.13. The tool shall provide the capability to process a minimum of 250,000 HTML pages for links, formats, responses, accessibility, and quality assurance checks.

1.14. The tool shall provide the capability to make accessibility and link checking scans of a minimum of 100,000 *.pdf documents.

2. Web content inventory – the tool will provide the capability to inventory site content.

2.1. Tool will crawl specified domains at defined intervals to build or update an inventory of web content.

2.2. Inventory will include, and be filterable by, pages, links, documents, and media files.

2.3. Inventory will include CSS and JavaScript files.

2.4. Inventory will include meta tags.

2.4.1. Inventory of meta tags will include common tags such as title tags and meta description

2.4.2. Tool will provide the ability to specify custom meta tags by which content can be assigned to different groups.

2.4.2.1. Tool will allow for a page to be included in two different groups in cases where two meta tags by which content is being grouped are present on a page.

2.5. Inventory will identify pages where an email address is displayed.

2.6. Content inventory dashboarding and reporting - the tool will provide a user interface for viewing and interacting with reports detailing site content inventories.

2.6.1. The tool will identify the number of pages, a viewable list of pages, and an exportable list of pages.

2.6.2. Tool will be able to identify specific pages added or removed since the last inventory was taken.

2.6.3. Tool will be able to provide number of pages added or removed since the last inventory was taken.

2.6.4. Tool will be able to identify specific pages added or removed since a specified date.

2.6.5. Tool will be able to provide number of pages added or removed since a specified date.

2.7. Tool will indicate the date any given page in the inventory was added to the inventory.

3. Web content accessibility assessment – the tool will make periodic automated assessments of subject sites’ accessibility.

3.1. Tool will provide scheduled scans of defined domains, as well as on-demand scans, for conformance with WCAG standards.

3.1.1. Tool will allow identification of issues by type.

3.1.2. Tool will categorize identified issues by conformance level (A, AA, AAA).

3.1.3. Tool will detail the frequency of identified issues sitewide.

3.2. Tool will allow identification of issues by page, content group, or domain.

3.3. Tool will provide scheduled scans of defined domains, as well as on-demand scans, for conformance with WAI-ARIA best practices.

3.4. Tool will provide accessibility checks of *.html pages.

3.5. Tool will provide accessibility checks of *.pdf documents.

3.6. Tool will provide accessibility checks of video files.

3.7. Tool will identify images with missing or insufficiently descriptive alt tags.

3.8. Tool will identify links with missing or insufficiently descriptive tags.

3.9. Tool will identify instances where contrast may be insufficient to ensure text is readable to users with impaired vision.

3.10. Accessibility reporting – the tool will provide a user interface for viewing and interacting with reports detailing accessibility issues

3.10.1. Reports for accessibility issues should identify the nature of the issue (ie. Applicable WCAG standard, ARIA, or custom defined best practices).

3.10.2. The tool will provide a prioritized list of errors to fix.

3.10.3. Reports for accessibility issues should be filterable by domain and content group.

3.10.4. Reports for accessibility should indicate the severity of identified issues by impact on overall accessibility or value of fixing the issue toward overall accessibility goals.

3.11. Benchmarking - tool should indicate number of accessibility issues identified over time (historical trends) in a viewable dashboard report. These data should also be exportable in *.csv, *.xlxs, or equivalent format.

3.11.1. Tool should indicate a grade or score for the extent to which subject domains in conformance with accessibility guidelines and best practices (% conformance, letter grade, x/5, etc.).

3.11.2. Reports should be filterable by values/levels such as: (1) the universe of domains included within the account; (2) specific domains; and (3) specific defined sub categories or groupings of content.

3.11.3. Tool should benchmark accessibility of overall collection of domains, domain, or content grouping within a domain against like industry sites (government)

4. Content quality assurance – the tool will make periodic automated quality checks of site content.

4.1. Link checking - Tool will build an inventory of hyperlinks within the site.

4.1.1. Tool should be able to understand links with and without appended parameters to be the same page.

4.1.2. Tool will populate a report of broken links and the pages on which those links occur.

4.1.3. Tool will generate a list of internal (within domain of page) links to a specific page.

4.1.4. Tool will generate a list of external (outside the domain of page) links to a specific page.

4.1.5. Link-related reports will be viewable by either link (URL being linked to), or by page (page on which link occurs).

4.1.6. Tool will provide a report that shows each page along with the number of links to that page from other pages within the site. This should be drillable to see the specific links to a page.

4.1.7. Tool should facilitate the identification of orphaned content (pages not linked to from other pages within the site).

4.2. Misspellings – tool should identify potentially misspelled words within site content.

4.2.1. Tool should include a pre-populated common spelling misspelling.

4.2.2. Tool should allow for the inclusion of a custom dictionary and custom list of commonly misspelled words.

4.3. Readability - tool will conduct periodic scans of site content for readability.

4.3.1. Tool will assess factors such as word choice, sentence length, paragraph lengths, and use of active voice.

4.3.2. Tool will provide a grade level-based readability score for scanned pages and documents.

4.3.3. Tool will populate a report that assesses and benchmarks overall readability of site content.

4.3.3.1. Generated readability reports will be filterable by domain, or content group.

4.3.3.2. Generated readability reports will be sortable and filterable by readability rating and type of readability issues.

4.4. Page elements – the tool will audit pages for the presence of key page elements.

4.4.1. Tool will verify that each page within a scanned domain has a unique title and will generate a report of pages with duplicate titles.

4.4.2. Tool will verify that the description meta tag is present for each page and generate a list of pages for which this value is missing.

4.4.3. Tool will have the ability to scan for the presence of custom specified meta tags.

4.4.4. Tool will verify that heading tags are present on each page and generate a list of pages for which they are not present.

4.4.5. Tool will verify that heading tags are in the correct order.

4.5. Custom content checks - Tool will provide the ability to define custom quality assurance checks specific to the Dept. of Education’s use cases. This might include, but not necessarily be limited to, specific phrases we wish to find within site content, or phrases associated with inclusive language.

4.6. FEDRAMP authorization

4.6.1. The selected vendor must be Federal Risk and Authorization Management Program (FedRAMP®) authorized.

5. Security and Privacy Requirements.

5.1. The Contractor must follow all requirements outlined in “Security and Privacy Requirements for IT Procurements”.

6. IT PROJECT MANAGEMENT LANGUAGE

6.1 Implement IT project management practices, techniques, methodologies, and standards to facilitate the efficient and effective lifecycle management of IT projects, leveraging the Department’s Enterprise Program Management Review Framework

7. TECHNOLOGY BUSINESS MANAGEMENT REQUIREMENTS (DRAFT)

7.1 The Technology Business Management (TBM) Data Report template is included as an attachment to this contract. This report shall be an annual deliverable under this contract with an as-need requirement when the distribution percentages need to be changed at the contractor’s notification. The contractor shall complete all pertinent fields of the report and provide timely delivery consistent with the August due date for the annual Capital Planning and Investment Control (CPIC) submission. The specific deliverable descriptions for the TBM sub-IT Towers and sub-Cost Pools are provided as an attachment to this acquisition (attached.)

The contractor shall review all the provided informational materials and select the sub-IT Towers and sub-Cost Pools that pertain to their particular contract. Not all IT Towers nor all the Cost Pool categories may apply to the contract. The contractor shall enter the appropriate amounts into each cell for each pertinent fiscal year. The contractor shall ignore the first IT Cost Pool for Internal Labor which pertains to Government FTE costs.

8. INFORMATION MANAGEMENT REQUIREMENTS

8.1 The purpose of this document is to impart requirements for managing and ensuring accessibility to Federal records (on any medium such as paper, systems, applications, etc.) that is made or received in connection with the transaction of Department business as part of a contract. The following requirements are divided into two sections, which are mandatory: (1) Records and CUI, (2) Accessibility requirements related to Section 508 of the Rehabilitation Act.

9. RECORDS AND CONTROLLED UNCLASSIFIED INFORMATION (CUI)

· "Federal record" as defined in 44 U.S.C. § 3301, includes all information, made or received by a Federal agency in connection with the transaction of public business. ED owns rights to all records produced as part of this contract. Any Contractor rights must be identified as required by FAR 52.227-11 through FAR 52.227-20.

· Federal records must be managed according to the applicable records management laws and regulations, to include the Federal Records Act (44 U.S.C. chs. 21, 29, 31, 33), 36 CFR Chapter XII Subchapter B, and the Privacy Act of 1974 (5 U.S.C. 552a).

· Federal records which are CUI must additionally be managed in accordance with any applicable laws, regulations and government-wide policies (LRGWP) to include EO 13556, 32 CFR Part 2002, ED Directive OCIO 3-113, and NIST-800-171 Revision 2 (or current version).

· Applicability: This clause applies to all Contractors and sub-contractors (hereafter referred to as “Contractors”) and must be incorporated into all subcontracts.

· Training Requirements: All Contractors are required to take the annual Information Management Requirements training. If the contract includes CUI the CUI Identification and Marking Training is required. Additional Category or POC specific trainings may be assigned. Contractor will maintain completion certificates and provide upon request.

· Electronic Information System Requirements: Any electronic information system should address at minimum the following regulations in 36 CFR 1236.10. Agencies must incorporate controls into the system or integrate them into a recordkeeping system that is external to the information system itself (see 36 CFR 1236.20 for recordkeeping system functionalities). Information systems that process, store, or transmit CUI must fulfill the requirements outlined in 32 CFR 2002.14(g).

· Marking Requirements: The Contractor will mark CUI as outlined in Department training.

· Handling and Safeguarding Requirements: The Contractor will ensure that CUI is managed appropriately. The requirements include safeguarding, controlled environments, shipping and mailing or transporting protections, and reproduction protections (see 32 CFR 2002.14(a-e)).

· Contract Completion Requirements: Removal or destruction of records must be in accordance with assigned ED records schedule and must include written concurrence from the CO/COR. If records are removed or destroyed the Contractor must report the incident to ED immediately. Destruction or removal of records without the above requirements is subject to fines and penalties imposed by 18 U.S.C. 2701.

· Compliance with Information Protection Requirements: ED reserves the right to verify compliance with information security requirements established by this contract. The Contractor will fully comply with all ED-initiated inspections as permissible by law.

· Information Security Incidents (ISI) Requirements: Contractors must immediately report any and all suspected security incidents, breaches, and events involving ED information to ED’s Computer Incident Response Center (EDCIRC) email: edcirc@ed.gov, and ED’s Security Operations Center (EDSOC) email: edsoc@ed.gov; voice: 202-243-6550, regardless of whether the ISI is suspected, known, or determined to involve IT systems operated in support of this contract. In the event of an ISI, ED must be provided immediate access to all IT systems used in support of this contract for inspection and analysis.

10. IT ACCESSIBILITY REQUIREMENTS (SECTION 508 OF THE REHABILITATION ACT)

· Section 508 of the Rehabilitation Act, as amended by P.L. 105-220, requires that when Federal agencies develop, procure, maintain, or use information and communication technology (ICT), it shall be accessible to people with disabilities. Products, platforms and services delivered as part of this work statement that are or contain ICT, must conform to the Revised 508 Standards, at 36 C.F.R. § 1194.1 & Apps. A, C & D.

· Applicable Functional Performance Criteria: When using an alternative design or technology that achieves substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance to one or more of the requirements in Chapters 4-6 of the Revised 508 Standards, or when Chapters 4-6 do not address one or more functions of ICT. – All requirements apply

· Applicable requirements for software features and components: All WCAG Level AA Success Criteria, 502 Interoperability with Assistive Technology, 503 Application – Applies if client server software (installed on a computer) is a part of the procurement.

· Applicable requirements to Webpage and Web Applications: All WCAG Level AA Success Criteria – Applies if websites or a web-based application (browser based) is part of the procurement.

· Applicable requirements for hardware features and components: Applies if hardware is part of the procurement. (e.g. copiers, fax machines, phones, scanner etc.)

· Applicable support services and documentation: All requirements apply.