Response to the A11y checklist for the RDF specifications

[pchampin]

A11y checklist

https://w3c.github.io/fast/checklist.html

As an preliminary remark about the responses to this checklist: RDF is an abstract data model (with a well defined semantics and a number of concrete syntaxes / serialization formats). It does not define any user-facing interface or behaviour, and is only marginally concerned with accessibility. Some of the items below, however, call for more developed responses.

Note that the responses to most of the questions below follow the same pattern: RDF in itself does not provide any specific means to satisfy the requirement, because RDF is a generic data model, and that it is up to data modelers to define vocabularies to that effect. However, RDF being very flexible (“anybody can say anything about anything”), defining the appropriate vocabulary is straightforward, and has usually been done in one ore several vocabularies (we provide examples when possible).

• If technology allows visual rendering of content → NO
• If technology provides author control over color → NO
• If technology provides features to accept user input → NO
• If technology provides user interaction features → NO
• If technology defines document semantics → NO
• If technology provides time-based visual media → NO
• If technology provides audio → NO
• If technology allows time limits → NO
• If technology allows text content → YES
  • Authors can define non-text alternatives for text content. → YES
    Example schema:image. Note that when the text content is represented by a simple literal, additional properties can not be directly attached to it, but RDF 1.2 triple terms can then be used, e.g.
    <#something> rdfs:label “text content” {| schema:image <non_text_alt> [}.
  • Authors can define non-text alternatives for non-text content. → YES
    Example schema:image.
• If technology creates objects that don't have an inherent text representation → YES
  • There is a mechanism to create short text alternatives that label the object. → YES
    Example: rdfs:label
  • There is a mechanism to create extended text alternatives for fallback content. → YES
    Examples: rdfs:comment, skos:prefLabel, skos:altLabel
  • Text alternatives can be semantically "rich" e.g., with page structure, text style, hyperlinks, etc. → YES
    Example: using literals of the datatype rdf:HTML
• If technology provides content fallback mechanisms, whether text or other formats → NO
• If technology provides visual graphics → NO
• If technology provides internationalization support → YES
  • Accessibility features can be internationalized to the same degree as other features → YES
    Internationalization support is provided in RDF by language-tagged strings, which are in other aspects similar to any other kind of literals, and therefore can be subject to the same accessibility features.
• If technology defines accessible alternative features → YES
  • Accessible alternatives themselves meet the same bar of accessibility → YES
    As explained in introduction, RDF has no specific accessibility features, these features are integrated in RDF as dedicated vocabulary terms, but are otherwise similar to any other vocabulary terms, and therefore can be themselves subject to the same accessibility features.
• If technology provides content directly for end-users → NO
• If technology defines an API → NO
• If technology defines a transmission protocol → NO

Scope

This self-assessment applies to the whole family of RDF 1.2 specifications:

• RDF12-NEW
• RDF12-CONCEPTS
• RDF12-N-QUADS
• RDF12-N-TRIPLES
• RDF12-PRIMER
• RDF12-SCHEMA
• RDF12-SEMANTICS
• RDF12-TRIG
• RDF12-TURTLE
• RDF12-XML