# Roadmap

## Baseline: what we have done

<table>
  <tr><td> x </td><td> <img src="/docs/images/noun_milestone_2525794.svg"> </td><td> Milestones documented, project description written, and initial OpenACR schema and catalog drafts published. </td></tr>
  <tr><td> x </td><td> <img src="/docs/images/noun_yaml_file_document_2760448.svg"> </td><td> Create the <a href="/catalog/2.4-edition-wcag-2.0-508-en.yaml">highly structured, machine-readable document format</a>. YAML was chosen as the markup language. Refine the YAML OpenACR schema to support the requirements of the current Section 508 version of VPAT (ie. the example with <a href="/openacr/drupal-9.yaml">Drupal 9</a>). </td></tr>
  <tr><td> x </td><td> <img src="/docs/images/noun_construct_validity_3159900.svg"> </td><td> Ensure that YAML documents conform to a defined <a href="/schema/OpenACR-0.1.0.json">structure</a> and <a href="/schema/openacr-catalog-0.1.0.json">catalog</a>. Build in validation code for the OpenACR schema so that key elements are evaluated. </td></tr>
  <tr><td> x </td><td> <img src="/docs/images/noun_continuous_deployment_2661276.svg"> </td><td> <a href="/tests">Build testing into the development</a> so that errors are caught early in the process. Continuous integration should be used to validate the code and process. </td></tr>
  <tr><td> x </td><td> <img src="/docs/images/noun_Target_16812.svg"> </td><td> Define outreach goals and targets. This is a GSA project, but if successful it will have implications far outside of the GSA. The team will need to raise awareness about OpenACR. </td></tr>
  <tr><td> x </td><td> <img src="/docs/images/noun_html_2407184.svg"> </td><td> The OpenACR document will be written in YAML, but this isn't an easily readable format. The YAML file must be <a href="/openacr">converted to both Markdown and a themed HTML output</a>. </td></tr>
  <tr><td> x </td><td> <img src="/docs/images/noun_Stakeholders_2743272.svg">  </td><td> Outreach and engagement will need to be done with stakeholders. Input will be needed for all roles of the procurement process. </td></tr>
  <tr><td> x </td><td> <img src="/docs/images/noun_directory_1421586.svg"> </td><td> Display a web directory listing of available OpenACRs. Users should be able to view a <a href="https://federalist-02947dd8-86df-467a-b2af-4c5b94c5b1f0.app.cloud.gov/site/gsa/openacr-website/openacr/">list of OpenACR files</a> as long as they are in a YAML format. These will need to be displayed in HTML in a format similar to the current VPAT. </td></tr>
</table>

## Optional phases: where are we going

<table>
  <tr><td> - </td><td> <img src="/docs/images/noun_submit_1862632.svg"> </td><td> Build process to submit vendor ACRs. Vendors need to be able to submit new ACRs to the GSA. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_update_3878124.svg"> </td><td> Proccess to get updates from vendors version control repositories (git). Updates need to be pulled from the source from key government ICT suppliers. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_comparison_3858497.svg/"> </td><td> OpenACR Comparison Tool - it should be simple to compare OpenACRs to understand relative accessibility.  </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_text editor_2245371.svg"> </td><td> OpenACR Editor - Editors need to be able to create, load, update and save OpenACR documents in a YAML format. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_documentation_3159052.svg"> </td><td> Procurement focused documentation. Procurement teams in government need to understand how OpenACR changes their workflow. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_documentation_3718566.svg"> </td><td> Vendor/Author focused documentation. Authors of OpenACRs need to understand how they should write and maintain the ACRS. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_Workflow_1326943.svg"> </td><td> Agency Accessibility Procurement Workflow. The flow of an ACR through the GSA should be clearly understood. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_Legal Studies_2003967.svg"> </td><td> Support government-wide documentation refresh. Current documentation is with VPAT but would need to be updated. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_training_3870491.svg"> </td><td> Training will need to be required for government and possibly vendors. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_Accessibility_488088.svg"> </td><td> Integrate with DART (Procurement Accessibility Requirements Tool). Procurement officers should be able to easily re-create requirements to evaluate. </td></tr>
  <tr><td> - </td><td> <img src="/docs/images/noun_www_3324740.svg"> </td><td> Integrate with Microsoft's Accessibility Insights & WCAG-EM reporting. Creating ACRs should be consistent and easy to implement. </td></tr>
</table>

## Source images from the Noun Project

- https://thenounproject.com/search/?q=accessibility&i=2525794
- https://thenounproject.com/search/?q=accessibility&i=2760448
- https://thenounproject.com/search/?q=accessibility&i=3159900
- https://thenounproject.com/search/?q=accessibility&i=2661276
- https://thenounproject.com/search/?q=accessibility&i=16812
- https://thenounproject.com/search/?q=accessibility&i=2407184
- https://thenounproject.com/search/?q=accessibility&i=2743272
- https://thenounproject.com/search/?q=accessibility&i=1421586
- https://thenounproject.com/search/?q=accessibility&i=1862632
- https://thenounproject.com/search/?q=accessibility&i=3878124
- https://thenounproject.com/search/?q=accessibility&i=3858497
- https://thenounproject.com/search/?q=accessibility&i=3159052
- https://thenounproject.com/search/?q=accessibility&i=3718566
- https://thenounproject.com/search/?q=accessibility&i=2003967
- https://thenounproject.com/search/?q=accessibility&i=3870491
- https://thenounproject.com/search/?q=accessibility&i=488088
- https://thenounproject.com/search/?q=accessibility&i=3324740