Access Continuum Test Results

Access Continuum returns test results to users in JSON. The format of the JSON string looks something like this: 

"[
  {
    "path": "[id='fail2']",
    "engineTestId": 87,
    "testContext": "Web",
    "needsReview": false,
    "attribute": "This SPAN (role=img) does not have a mechanism that allows an accessible name value to be calculated",
    "bestPracticeId": 362,
    "element": "<span id=\"fail2\" role=\"img\" src=\"images/goat-4.jpg\"></span>",
    "fixType": {
      "domSpec": false,
      "helperText": "Specify label text that describes the content conveyed by the image."
    },
    "bestPracticeDescription": "Provide alternative text for images",
    "severity": 10,
    "noticeability": 10,
    "tractability": 2,
    "bestPracticeDetailsUrl": "https://amp.levelaccess.net/public/standards/view_best_practice.php?violation_id=362",
    "bestPracticeStandards": [
      {
        "id": 1140,
        "name": "Section 508 and 255 (Revised 2017)"
      },
      {
        "id": 610,
        "name": "WCAG 2.0 Level A"
      },
      {
        "id": 1471,
        "name": "WCAG 2.0 Level A & AA Baseline"
      },
      {
        "id": 1387,
        "name": "WCAG 2.1 Level A"
      },
      
    ]
  }
]

The following list defines the contents of each of the name-value pairs in the JSON string: 

1. path: This attribute displays the CSS selector for the node that failed the Access Engine test. 
2. engineTestId: This attribute is an Access Engine-specific ID associated with the test that failed. Note that this is different from the Best Practice ID, and some Best Practices actually have many different tests that are run against them. 
3. needsReview: This is either true or false and indicates that the test is a Guided Automatic test that requires the tester to review the output and either validate a defect or pass it.
4. testContext: This displays either NATIVEAPP or WEB, indicating whether testing is on a native application element or a web view element.
5. attributeDetail: This is a textual description of the failure, describing why the element was failed.
6. attribute*: This is a textual description of the failure. It describes why the element was failed.
7. bestPracticeId: This is the ID for the Best Practice associated with the failed test. Users may use this ID to look up the Best Practice in the Best Practice library within AMP. 
8. element: The HTML of the element that failed is displayed as the value of this attribute. For example, if a form input fails because an accessible name cannot be calculated the <input> tag, and it's attributes, would be displayed for this field. 
9. bestPracticeDescription: The name of the Best Practice that corresponds to this accessibility concern.
10. severity: Severity is a measure of how large an impact on the user experience a violation of the best practice will have. The severity of the accessibility concern is on a scale of 1 to 10, where 1 is the least severe and 10 is the most severe.
11. noticeability: Noticeability is the likelihood that a given violation will be detected by users of a system. The noticeability of the accessibility concern is on a scale of 1 to 10, where 1 is the least noticeable and 10 is the most noticeable.
12. tractability: Tractability defines the estimated costs associated with ensuring that instances of a violation are fixed in accordance with the best practice. The tractability of the accessibility concern is on a scale of 1 to 10, where 1 is the least tractable and 10 is the most tractable.
13. bestPracticeDetailsUrl: This is the URL of the Best Practice corresponding to this accessibility concern. Navigate to this URL to view the details of the violation and recommendations for remediation. Users can access these details whether or not they have an active AMP license.
14. bestPracticeStandards: The list of accessibility standards (e.g., WCAG 2.1 A)  associated with the best practice that corresponds to this accessibility concern. By default, the standards include WCAG 2.0 Any Level, WCAG 2.1 Any Level, Section 508 (Revised 2017) and WCAG 2.0 A and AA Baseline.
15. There are some Access Engine fields that are typically used by Access Alchemy, but they may be useful to users of other products that make use of Access Engine: 
    1. fixType: This is field that categories the type of fix Access Alchemy will make, such as adding a value for an attribute. This field can be ignored when reviewing Access Continuum output. 
    2. fix: This set of fields displays the values Access Alchemy would need to fix the issue automatically. It can be ignored when reviewing Access Continuum output. 
    3. helperText: The value of this field is typically used by Access Alchemy to guide users as to how to use that product to create an Alchemy remediation. However, this field can also be valuable for Access Continuum users, as it provides remediation guidance to the developer.
    4. domSpec: This field is also Access Alchemy specific but may be useful to developers using Access Continuum. This is a Boolean field, with "true" indicating that the violation is specific to the entire page -- e.g., the title or document language -- whereas "false" indicates that there.

Note: The name of this field is slightly different in the test results between Java and Javascript. In Java, the field is named "attribute" and in Javascript, it is named "attributeDetail."