earl:passed
The subject passed the identified test.
State what was checked. This result alone is not a WCAG conformance claim.
Standards & practice / EARL
Turn test results into
shareable evidence.
The Evaluation and Report Language gives testing tools and people a common vocabulary for reporting results. Learn the structure, choose an honest outcome, and build an assertion you can take to another system.
4 parts of an assertion5 outcomes + 5 modes2 export formats
EARL 1.0 Schema · W3C Working Group Note · 2 February 2017. This is a non-normative Note, not a W3C Recommendation. The schema did not complete the Recommendation process. Status checked against W3C on 15 September 2026.
Read the report as a statement
Who tested what, against which test, with what result?
One assertion connects four resources. Keep the test scope narrow enough for the evidence to support it.
- 01 / AssertorWho is responsible?
A person, a testing tool or a team. Use an identifier and a useful name.
earl:assertedBy - 02 / SubjectWhat was tested?
A page, a document, a component or another resource. Capture the relevant state.
earl:subject - 03 / CriterionWhich test was used?
A specific test case or a broader requirement. These have different scope.
earl:test - 04 / ResultWhat was found?
An outcome, evidence and context, connected through a result node.
earl:result
Two levels matter: earl:mode belongs to the assertion. earl:outcome, earl:info and earl:pointer belong to the result. A result is a resource with properties, not a word placed directly in earl:result.
Report what the evidence actually supports
earl:failed
The subject failed the identified test.
Describe the observed failure, location and steps needed to reproduce it.
earl:cantTell
The available evaluation does not establish pass or fail.
Record the missing information or human review needed to decide.
earl:inapplicable
The test does not apply to this subject.
Explain why the applicability conditions are absent; do not use this for skipped work.
earl:untested
The test has not been carried out.
Keep this separate from an attempted test whose outcome is uncertain.
Uncertain is different from untested
A tool finds image text but cannot judge whether the description communicates the purpose: record cantTell and explain the review needed. If nobody ran the test, record untested.
Not applicable is different from passed
A video-caption test on a page without relevant video may be inapplicable. It does not demonstrate that captions were tested and passed. Record why the applicability conditions were absent.
Local assertion workshop
Build one reportable assertion
Describe a test you performed, or load a clearly fictional example to learn the format. This tool formats your evidence; it does not inspect the subject or decide the outcome.
The required fields below are choices of this builder, not claims that the EARL schema enforces these exact cardinalities. It exports one assertion and one result at a time. Data stays in this tab until you download or copy it; there is no automatic saving or upload.
Review these fields
Enter your evidence, then generate an assertion.
Your generated assertion
Turtle and JSON-LD express the same RDF graph. Namespace identifiers deliberately keep their exact HTTP spelling. This builder does not fetch them.
Turtle preview
JSON-LD preview
The assertion builder validates its supported input syntax and serializes the fields. It does not verify that an identifier resolves, that the evidence is accurate, or that the subject conforms to WCAG.
A fictional worked example
A keyboard failure is evidence about a test
What the evaluator observed
In a sample booking interface, the date picker opened with Enter. After selecting a day, keyboard focus moved to the document body instead of returning to the date field. A manual focus-return test failed.
The report names the specific test, describes the initial state and steps, and records the failure. It does not announce that the entire website was audited.
Keep the distinction: the evaluator is the assertor; the booking page is the subject; the focus-return check is the test; the failure and supporting description belong to the result.
A minimal RDF shape
@prefix earl: <http://www.w3.org/ns/earl#> .
@prefix dct: <http://purl.org/dc/terms/> .
_:assertion a earl:Assertion ;
earl:assertedBy <urn:example:reviewer> ;
earl:subject <https://example.org/booking> ;
earl:test <urn:example:focus-return> ;
earl:mode earl:manual ;
earl:result _:result .
_:result a earl:TestResult ;
earl:outcome earl:failed ;
dct:description "Focus did not return to the date field." .Original teaching example. The builder adds explicit evaluator, subject and criterion types, the result date and your full evidence.
Vocabulary desk
Explore the 34 EARL terms
Fifteen classes, nine properties, five outcome individuals and five mode individuals from the EARL 1.0 Schema. These explanations are original learning notes; each term links to its W3C definition.
34 terms available.
No terms match. Try a shorter search or reset the filters.
earl:Assertion Class
A report statement that connects an evaluator, a subject, a test and its result.
Attach the testing mode to this node, rather than to the result.
earl:Assertor Class
The evaluator responsible for the statement: a person, tool, organisation or group.
Give the evaluator a useful identity and, when appropriate, a more specific type.
earl:TestSubject Class
The resource being evaluated.
Record the relevant version or page state so that another person can reproduce the test.
earl:TestCriterion Class
The criterion or test against which the subject is evaluated.
Identify the actual test performed; avoid implying that a narrow check covers a whole standard.
earl:TestRequirement Class
A broader requirement that may need several separate checks.
This refines TestCriterion; use it for the requirement itself.
earl:TestCase Class
A specific test that can contribute evidence about a broader requirement.
This refines TestCriterion; a passing test case does not establish every aspect of that requirement.
earl:TestResult Class
The result node connected to an assertion.
Attach outcome, human-readable evidence, date and any relevant pointer to this node.
earl:TestMode Class
The category describing how testing was performed.
Use the mode individuals below when one describes the process.
earl:OutcomeValue Class
The category of values used to express a test outcome.
Use the outcome individuals below for ordinary result categories.
earl:Software Class
A software resource that may be the evaluator or the thing evaluated.
Record a tool name and version when they matter to reproducing a result.
earl:Pass Class
A class for outcomes that represent passing.
For an ordinary passing result use the individual earl:passed, not this class as a substitute.
earl:Fail Class
A class for outcomes that represent failure.
For an ordinary failed result use earl:failed.
earl:CannotTell Class
A class for outcomes that remain undetermined.
For an ordinary undetermined result use earl:cantTell.
earl:NotApplicable Class
A class for outcomes where a test does not apply.
For an ordinary non-applicable result use earl:inapplicable.
earl:NotTested Class
A class for outcomes where testing was not performed.
For an ordinary untested result use earl:untested.
earl:assertedBy Property
Connects an Assertion to its Assertor.
Its object is a resource identifying the evaluator, not just a name string.
earl:subject Property
Connects an Assertion to its TestSubject.
Keep the scope of the subject consistent with the evidence.
earl:test Property
Connects an Assertion to its TestCriterion.
Use an identifier for the precise rule, test case or requirement being reported.
earl:result Property
Connects an Assertion to its TestResult.
Use a result resource; do not put the word “passed” directly here.
earl:mode Property
Connects an Assertion to a TestMode.
Use a resource such as earl:manual or earl:semiAuto.
earl:mainAssertor Property
Identifies the primarily responsible evaluator within an assertor grouping.
Useful when reporting a person working with tools or a testing team.
earl:outcome Property
Connects a TestResult to an OutcomeValue.
Use an outcome resource such as earl:failed, rather than a literal string.
earl:pointer Property
Links a TestResult to a pointer locating relevant content.
Its range is a pointer resource. A CSS selector string alone is not an EARL pointer.
earl:info Property
Adds human-readable warnings or explanatory information to a TestResult.
This takes a literal; keep observations understandable alongside machine-readable outcomes.
earl:passed Outcome
The subject passed the identified test.
State what was checked. This result alone is not a WCAG conformance claim.
earl:failed Outcome
The subject failed the identified test.
Describe the observed failure, location and steps needed to reproduce it.
earl:cantTell Outcome
The available evaluation does not establish pass or fail.
Record the missing information or human review needed to decide.
earl:inapplicable Outcome
The test does not apply to this subject.
Explain why the applicability conditions are absent; do not use this for skipped work.
earl:untested Outcome
The test has not been carried out.
Keep this separate from an attempted test whose outcome is uncertain.
earl:automatic Mode
Software carried out the test without human intervention.
Choose this for the actual testing process, not merely because a tool created the report.
earl:manual Mode
A person carried out the test procedure.
Software instructions or guidance can still accompany manual testing.
earl:semiAuto Mode
Software and human input or judgment contributed to deciding the result.
Describe the tool contribution and the evaluator’s decision.
earl:undisclosed Mode
The testing process is not disclosed.
Use when the process is withheld, rather than merely unknown.
earl:unknownMode Mode
The testing process is unknown or undetermined.
Useful for a received result whose testing method cannot be established.
Keep the report useful beyond your tool
Separate a rule from its result
ACT describes how a test is defined and applied. EARL can express a result from that test. WCAG provides accessibility requirements. Keep all three identifiers and scopes clear.
Explore ACT rulesPreserve context when results move
Include page state, time, versions, evaluation method and enough evidence to reproduce the result. A URL can identify a changing page; note the version you actually reviewed.
Record a testing worksheetAvoid accidental aggregation claims
A collection of passed assertions does not automatically prove that a page or site meets every WCAG requirement. Keep incomplete, inapplicable and untested results visible in your review process.
Read the WCAG referenceExtending beyond this builder
EARL can be combined with other vocabularies to describe tool versions, teams, HTTP responses, captured content and pointers. This single-assertion builder uses a deliberately small subset. It does not create a complete evaluation report, preserve snapshots or generate machine-readable content pointers.
For result locations, the earl:pointer property expects a pointer resource. Explore the Pointer Methods in RDF Note before inventing a selector property or putting a raw selector string in that relation.
Sources and status
This independent guide uses original explanations and code. The EARL vocabulary comes from Evaluation and Report Language (EARL) 1.0 Schema, W3C Working Group Note, 2 February 2017. The Note is non-normative and did not become a Recommendation.
- WAI EARL overview — audience, purpose and related documents. Its older ACT-development wording is not used here.
- ACT Rules Format — the current rule-format specification, separate from the result vocabulary.
- RDF 1.1 Turtle and JSON-LD 1.1 — serialization formats used by the builder.
- EARL RDF schema — machine-readable vocabulary.
Verified 15 September 2026. Source links provide the authoritative vocabulary and document status. This page provides learning support and a local formatting tool, not certification.