Optional fields to capture product, developer, vendor, author etc

[grugnog]

Need to flesh out what the needs and data structure here is, but could be good to capture:

• name
• URL
• contact info

For the

• product
• developer
• vendor
• ACR/OPAT/VPAT author(s)

[mgifford]

Moving Owen's lists into lists so they are easier to read.

There is the URL of the project but also the URL of the repository that contains the OPAT. For instance, with Drupal, it might be somewhere like https://git.drupalcode.org/project/opat-en.yaml

Would also be useful to just outline how one would add optional fields if a department wanted to add additional metadata for their own internal use.

[mgifford]

So if we want to include issue queues, we might want to consider switching from:

          - name: "authoring-tool"
            adherence:
              level: "supports"
              notes: Generally parsing is very well supported, but there are a few places where this needs to be improved - Drupal issue 1852090 and 3144948.

to one that allows an array of links. From this the system could draw out the title or other data such as last updated date if it were available.

          - name: "authoring-tool"
            adherence:
              level: "supports"
              notes: Generally parsing is very well supported, but there are a few places where this needs to be improved
              issue_url: 
                https://www.drupal.org/node/1852090
                https://www.drupal.org/node/3144948

I'd also like to see a repository link up at the top so we can possibly update:

product:
  name: Drupal
  version: "9.1"
  description: Content Management System

to include

product:
  name: Drupal
  version: "9.1"
  description: Content Management System
  repository_yaml: https://github.com/GSA/open-product-accessibility-template/blob/main/opat/drupal-9.yaml
  repository_source: https://github.com/GSA/open-product-accessibility-template.git

Might also be useful to have repository_markdown & repository_html fields as optional.

[mgifford]

The vendor and report author are listed here - #14 (comment)

@saz33m suggested that there would be a need to allow for a developer so someone could take a project like Drupal, customize it (say with a customized install profile), and then create a VPAT for that customized tool. In which case they might want to start with Drupal's VPAT, then extend it for the customization. If an external firm is involved in authoring the ACR then we'd need to allow for that too.

[mgifford]

testing_process field

Talking to an accessibility manager at a bank, it would be useful to have optional notes fields to allow an author to verify how tests have been done. Automated processes are good but insufficient. A VPAT should not say that it conforms if only automated testing has been done. We can ask the author to specify what tools/approaches that they used to do the testing.

This might be defined in the notes field, but if we ask for it, and specifically call for examples of manual testing in the editor it might help drive home the point. A field also makes it more comparable. Might even include an array of tools and versions used.

user_impact

In a VPAT there is presently no way to measure user impact. Tools like axe identify issues as critical, serious, moderate & minor - this is one type of user impact. The other is if the errors are common or part of a key task that a user is expected to do. In order for suppliers to be able to evaluate how important an error is to their user, they need to understand its impact.

EDIT: This should describe the severity and determine if it is a show-stoper or if there are workarounds.

[mgifford]

There is also the hash filed #69 (comment)

[grugnog]

I think we might want to consider how this fits with EARL, since this captures the testing_process description https://www.w3.org/TR/EARL10-Schema/#TestMode - I think ideally users are integrating EARL test results so we have more granular detail, but I can see an argument for capturing this for authors who can't or aren't using EARL.

[mgifford]

Would also be useful to be able to document if there is any alignment with Section 504 requirements and if there is an ETA with which a vendor is working to implement a fix for the bug that is described.