Méthodologie du rapport de conformité à l'accessibilité

1. Report initialization
2. Auditing and referencing an assessment
3. Issuing and formalizing the ACR report
4. Archiving

Report initialization

1. Define the scope of the accessibility evaluation.
2. Choose a conformance criteria ruleset from the WET-BOEW ACT rules repository.
3. Fill out the assessment report template with the following information:
   • Subject: earl:subject.
   • Your name and your organization: earl:assertedBy.
   • Date created: dct:created.
   • Conformance to standard: acr:standard.
   • Conformance option: acr:conformanceOption.
4. Set the selected ruleset JSON template as a baseline in acr:conformity

Auditing and referencing an assessment

1. Edit the living ACR to include the new assessment that is in scope of the tested subject.
2. Add the referenced assessment in acr:assessment:
   • The key is the URL where the assessment in JSON can be retrieved.
   • Add the assessment title in dct:title.
   • Add a link to the HTML equivalent report in dct:references.
   • Define the main language used for that assessment (2 letter code) dct:language.
   • Set the date of when the assessment was added into this ACR dct:date.
3. Audit the assessment acr:audits:
   • Your name: earl:assertedBy.
   • Define the testing mode: earl:mode.
   • Add a reference to the assessment: acr:assessment.
   • Audit each evaluated test case and record your finding if applicable in acr:auditNote:
     • Define the accuracy (False negative, False positive, Accurate) in acr:accuracy.
     • Set the date of this note in dct:date.
     • Set the title of this note in dct:title.
     • Associate the applicable test case in earl:test.
     • Describe the concern expressed by this note in dct:description.
     • Optionally, describe the error message in earl:info.
     • Optionally, define a severity level in acr:severity.
     • Optionally, define a relevancy subject in acr:relevancy.
     • Optionally, include an attachment encoded in data URL in acr:asset.
   • If applicable, create a work item in wf:task and for each work item:
     • Set the title in dct:title.
     • Describe the work goal and additional description to provide enough context in wf:goalDescription.
     • Add a reference to the discussion page in dct:references.
     • Set the work item creation date in dct:created.
     • Define the test requirement this work item is about in acr:requirement.
     • Define the specific test case this work item is about in earl:test.
     • Optionally, define a severity level in acr:severity.
     • Optionally, define a relevancy subject in acr:relevancy.
   • Update the conformity of the criteria affected by the assessment and for each updated conformance requirement:
     • Update the conformance state (Satisfied, Not satisfied, Further test needed) in acr:conformance.
     • Add a reference to the applicable assessment in acr:assessment.
     • Add a description about its latest conformance state or the current state if applicable in dct:description.
     • Update the modified date in dct:modified.
     • Define the cumulative testing mode for this conformance requirement conformity in earl:mode.
4. If possible, add your verifiable credential.

Issuing and formalizing the ACR report

1. Edit the living ACR for which we want to set the conformance status for the tested subject.
2. Validate the integrity of the test subject for all related assessments and audits. If this is not satisfied, the ACR must be archived.
3. Revise audits, work items and all conformance requirements to ensure they are accurate.
4. Validate each conformance requirement. None of them should be marked as "Further test needed"
5. Set your name and your organization's name as the main assertor name for the conformance report using earl:assertedBy.
6. Define the conformance report's conformance as "satisfied" only if all the conformance requirements are also "satisfied." Otherwise it is "not satisfied."
7. Set the current date as the issue date using dct:issued.
8. If possible, add your verifiable credentials.

Archiving

• When we don't know its replacement:
  1. Edit the ACR report to archived.
  2. Set the expiry date of when the ACR was officially acknowledged to be outdated in schema:expires.
  3. If possible, add your verifiable credentials.
• When it is being replaced by a new report:
  1. Edit the ACR report to archived.
  2. If not defined, set the expiry date of when the ACR was superseded in schema:expires.
  3. Set the URL of the replacement ACR report in dct:isReplacedBy.
  4. If possible, add your verifiable credentials.

• When the ACR report is reissued:

  Note: A reissued accessibility conformance report must have its own identities, which must be different from the issued accessibility conformance report. In practice, this means creating a new JSON file for the reissued ACR report.

  1. Issue the reissued ACR as an independent report by including a reference to its previous version in dct:isVersionOf.
  2. Edit the original ACR report to archive it.
  3. If the expiry date of the original ACR report is not defined, set it as the date when the ACR was reissued in schema:expires.
  4. Set the URL of the reissued ACR report in dct:hasVersion.
  5. If possible, add your verifiable credentials.