Proposal: `dcterms:accessibility` and `dcterms:accessibilitySummary`

[tombaker]

Kalli, Niklas, and I took an action to propose a way forward for accessibility.

Attached below is a proposal for two properties: dcterms:accessibility and dcterms:accessibilitySummary.

We propose the following procedure:

• Get consensus on the proposal in the UB.
• Post the proposal for a thirty-day comment period, as we did for accessibilityNote in January-February.
• Finalize the proposals in light of public feedback.

For reference:

• add :accessibilityStatement either to BIBO or DCTerms #79 UB discussion of accessibility, September 2025 to April 2026
• Public comment on dcterms:accessibilityNote usage#133 Public comment on dcterms:accessibilityNote, January-February 2026

[tombaker]

We find that:

1. DC Terms should support accessibility. The comments received on dcterms:accessilityNote in February generally affirmed the need for a property about accessibility. Accessibility is already supported by other metadata standards, such as MARC, Schema.org, and EPUB.

2. Metadata based on free-text values is not precise enough. Accessibility metadata can be used to filter search results or configure interfaces based on user needs, but only if it is "structured" in a "machine-readable" way using controlled vocabularies. Describing accessibility features in free text is no substitute for tagging those features with actionable precision.

3. Existing vocabularies for accessibility use lexical terms. The accessibility vocabularies most widely used in metadata today are those defined for Schema.org. The Schema.org vocabularies define lexical terms for several types of accessibility concepts: APIs ("AndroidAccessibility"...), input methods ("fullKeyboardControl"...), content features ("synchronizedAudioText"...), access modes ("tactile"...), and hazards ("flashing"...). Each vocabulary is paired with a corresponding property. The vocabulary of accessibility hazards, for example, is paired with the property https://schema.org/accessibilityHazard, and its lexical term "none", for example, derives from the context provided by that property its actionable meaning: "no hazards".

4. Accessibility terms need URIs. In order to use accessibility concepts from Schema.org in linked data, the union catalog of Swedish libraries (LIBRIS) assigns them provisional URIs under one of its own domains. The URI https://id.kb.se/vocab/accessibilityHazard/none defines the concept of "no hazards" with actionable precision, though at the cost of a creating a dependency between LIBRIS and Schema.org that would in principle need to be maintained.

We propose the creation of two properties:

1. dcterms:accessibility for use with concept URIs. We propose the creation of dcterms:accessibility on the model of dcterms:subject. The Subject property is intended to be used with URIs of topics irrespective of type (whether person, geographic location, or other type of topic). In practice, the values of Subject are often SKOS concepts. By analogy, the Accessibility property would be intended for use with accessibility aspects irrespective of type (whether input method, content feature, access mode, or hazard). In contrast to Subject, however, Accessibility would be defined with a hard expectation that its values be URIs.

dct:accessibility a rdf:Property ;
  rdfs:label "Accessibility"@en ;
  rdfs:comment "A feature or deficiency of a resource that enhances or impedes 
     its accessibility."@n ;
  dcterms:description "Values must be referenced with URIs, preferably drawn from 
     controlled vocabularies. If such a URI does not exist, use `dcterms:accessibilitySummary`." ;
  rdfs:range skos:Concept .

2. dcterms:accessibilitySummary: for free-text annotations. Inasmuch as most accessibility vocabularies today are not based on URIs, the availability of just one property with a hard requirement for URIs would set the bar for metadata producers unrealistically high. We therefore propose the creation of a second property, dcterms:accessibilitySummary, for information about the accessibility of a resource in free text.

dct:accessibilitySummary a rdf:Property ;
  rdfs:label "Accessibility note"@en ;
  rdfs:comment "A statement describing features or deficiencies of a resource 
      that enhance or impede its accessibility."@en ;
  dcterms:description "Features or deficiencies that can be identified with
      a URI should be described using `dcterms:accessibility`."@en ;
  rdfs:range rdfs:Literal ;
  rdfs:subPropertyOf dct:description .

Discussion

1. If it were helpful, the usage note for dcterms:accessibility could suggest that values be SKOS concepts. A resource of any type (except another type of SKOS thing, such as SKOS Collection) can, without formal contradiction, also be called a SKOS Concept.

2. The fifteen-element Dublin Core was invented prior to RDF, and the use of properties such as Creator, Contributor, and Subject with literal values is an established fact of life that no official definition can realistically aspire to change. With dcterms:accessibility, however, DCMI can take a stronger stance. To be useful, accessibility metadata must be precise, and in the context of Linked Data this means that accessibility concepts must be URIs.

3. The definitions of the proposed accessibility properties use the word "accessibility". Good definitions generally avoid such circularity, but "accessibility" is strongly associated with a specific standards community and set of concerns, so using "accessibility" is safer and clearer than any attempt we might make to paraphrase its scope. The properties are defined as broadly as possible so as not to preclude the creation of more-specific subproperties in future.

Historical note

Before the invention of SKOS, thesauri were controlled sets of lexical terms. To provide a context for such literals, early DC workshops came up with the notion of vocabulary encoding scheme. The VES "LCSH", for example, could provide context for the string "China -- History". The DCMI notion of VES was later aligned with that of RDF datatype, which posits a lexical space (a set of strings such as the integer "1"), a value space (a set of underlying concepts, such as "the integer one"), and a lexical-to-value mapping from each lexical representation to exactly one underlying concept. The definition of http://purl.org/dc/terms/LCSH was tweaked to read: "The set of labeled concepts specified by the Library of Congress Subject Headings". DCMI could conceivably coin VESes for Schema.org accessibility vocabularies, such that

    dcterms:accessibility "noFlashingHazard"^^<http://purl.org/dc/terms/AccessibilityHazard>

would refer to the concept "the absence of hazardous flashing"). However, the use of RDF datatypes for contextualizing literal values never caught on as a Linked Data practice, and the DCMI Usage Board concluded in the 2000s that the creation and maintenance of further VESes would not be sustainable.

References

• Schema.org Accessibility Properties for Discoverability Vocabulary - Final Community Group Report 26 March 2026
• MARC 21 532 - Accessibility Note
• MARC 21 341 - Accessibility Content
• EPUB Expressing Accessibility Metadata in the EPUB Package Document - Draft Community Group Report 28 April 2026
• LIBRIS id.kb.se/a11y namespace
• Public comment on dcterms:accessibility:note - February 2026
• BIBFRAME bf:contentAccessibility
• 1EdTech AccessForAll Meta-data Overview - Version 1.0 Final Specification (2004)

[kcoyle]

dct:accessibility a rdf:Property ;
rdfs:label "Accessibility"@en ;
rdfs:comment "A feature or deficiency of a resource that enhances or impedes
its accessibility."@n ;
dcterms:description "Values must be referenced with URIs, preferably drawn from
controlled vocabularies. If such a URI does not exist, use dcterms:accessibilitySummary." ;
rdfs:range skos:Concept .

Suggest: (changes in italic)

dct:accessibility a rdf:Property ;
rdfs:label "Accessibility"@en ;
rdfs:comment "A feature or deficiency of a resource that enhances or impedes
its use"@n ;
dcterms:description "Values should be referenced with URIs drawn from
controlled vocabularies. For textual expressions of accessibility, use dcterms:accessibilitySummary." ;
rdfs:range skos:Concept .

[kcoyle]

If it were helpful, the usage note for dcterms:accessibility could suggest that values be SKOS concepts.

I don't think that would be helpful. You seem to say that essentially any object value could be seen as a SKOS concept even if not defined as such, but I don't think this is a common working assumption. If users of DC terms are familiar at all with SKOS they probably associate it with subject terms. However, I would bet that many people (most?) using values from, say, LCSH, are not aware that they are using a SKOS concept. I also note that schema.org uses some of the SKOS mapping properties for a few terms (~50) but it is unlikely that anyone not fully steeped in SKOS would understand those few terms as being inherently SKOS concepts, much less see the entire vocabulary as consisting of SKOS concepts.

skos:exactMatch eli:InForce ;
...
skos:closeMatch eli:LegalValue ;

[niklasl]

Note that the need for two properties need some more evaluation. For example, the value of dct:accessibilitySummary as a free-text direct counterpart of dct:accessibility needs to be considered with some examples of use. As we're basing it on existing (and still evolving) practices (schema.org, MARC21, ONIX; see also crosswalks), it is important to consider its "evolved" use, from being intended for providing a summary of the precise details, to providing more complementary free text alongside precise information.

We'd really need to see (many) concrete examples of use to be able to evaluate how these would work out in practice (what is so be conveyed; can the producer convey it clearly; can the target audiences leverage this information in library catalogues/search engines to filter out and locate the items they require).

Note that there are examples of use at https://schema.org/accessibilitySummary which illustrate possible (probable?) usage; which may look like this with the above properties (and provided the example a11y concept scheme is made reality, akin to what we're seeking at id.kb.se):

prefix skos: <http://www.w3.org/2004/02/skos/core#>
prefix bibo: <http://purl.org/ontology/bibo/>
prefix dct: <http://purl.org/dc/terms/>
prefix a11y: <https://example.net/terms/a11y/>
base <https://example.org/>

<Alice_in_Wonderland> a bibo:Book ;
  dct:title "Alice in Wonderland" ;
  dct:accessibility a11y:textual ,
    a11y:textual-visual ,
    a11y:auditory ,
    a11y:auditory-visual ,
    a11y:auditory-visual-textual ;
  dct:accessibilitySummary
    "Short descriptions are provided; long descriptions of the images are not needed for most readers."@en .

a11y:textual a skos:Concept ;
  skos:inScheme a11y: ;
  skos:definition "See the text"@en .

a11y:textual-visual a skos:Concept ;
  skos:inScheme a11y: ;
  skos:definition "See the text and images"@en .

a11y:auditory a skos:Concept ;
  skos:inScheme a11y: ;
  skos:definition "Hear the text and eventual image descriptions"@en .

a11y:auditory-visual a skos:Concept ;
  skos:inScheme a11y: ;
  skos:definition "Hear the text and see the images"@en .

a11y:auditory-visual-textual a skos:Concept ;
  skos:inScheme a11y: ;
  skos:definition "Hear the text and see the text and images"@en .

Note that the above terms probably need to be more clearly defined with the meaning of access mode sufficient, which I suspect is a key concept for helping the target audiences discover media that they can actually use to receive complete/essential information/experience.

(Hitherto I've not seen such clear metadata in actual EPub documents or descriptions thereof; I'd love for some pointers to sources of such quality!)

[kallimathios]

(Hitherto I've not seen such clear metadata in actual EPub documents or descriptions thereof; I'd love for some pointers to sources of such quality!)

@niklasl, I'll see if I can find some.

[kcoyle]

@niklasl

Note that the need for two properties need some more evaluation.

My big concern is that it is unprecedented in DC terms to have a property defined with a range of IRI. The only defined ranges (e.g. not "rangeIncludes") are all

http://www.w3.org/2000/01/rdf-schema#Literal

and properties that might logically be an IRI in some contexts are defined with rangeIncludes. If one were validating, either a literal or an IRI would pass the validation rules.

Are we really ready for the FIRST required IRI in DC terms? Wouldn't it be best to leave the value type to profiles as we do for other properties?

As for "free text alongside ... " I think this can be done again with profiles. I can imagine

accessibilityShape [
ex:accessibility "https://something" ;
rdf:label "The resource requires an 8-track tape player." ] .

This is similar to what BIBFRAME does with display forms of peoples' names -- it treats them as a label and presumably within that node their display programs know what to do with labels. I do understand the value of having a specific display property, but that does greatly increase the number of properties that one needs. This, of course, presumes that the meaning of the accessibility property and the label are considered at least parallel if not a close match, but that is also a problem with the proposal for an IRI and a different literal property.

[kcoyle]

PROPOSAL: define accessibility as:

dct:accessibility a rdf:Property ;
  rdfs:label "Accessibility"@en ;
  rdfs:comment "A feature or deficiency of a resource that enhances or impedes its accessibility."@en ;
  dcterms:description "Values should be drawn from controlled vocabularies, preferably identified with URIs. `dcterms:accessibilitySummary` should be used for free-text descriptions." ;
  dcam:rangeIncludes skos:Concept .

[kcoyle]

Some accessibility vocabularies will be simple text lists. Where should those be indicated in the definitions?

[osma]

@niklasl wrote:

it is important to consider its "evolved" use, from being intended for providing a summary of the precise details, to providing more complementary free text alongside precise information.

I think this is a key consideration. accessibilitySummary should not be described as the textual equivalent of the machine readable representation but a complement to it, providing some optional information that cannot be fully expressed with the controlled vocabularies. That should be reflected in the definitions as well. "dcterms:accessibilitySummary should be used for free-text descriptions." does not fully capture this aspect of complementarity.

Regarding @kcoyle's question "Are we really ready for the FIRST required IRI in DC terms?" - historically speaking, this wouldn't be the first such requirement. There used to be rdfs:range statements for some DCTerms properties, requiring the use of IRIs. Some of them were considered problematic (see dcmi/usage#32) and they were all replaced with rangeIncludes statements (see dcmi/usage#43). I think using rangeIncludes skos:Concept for accessibility would be consistent with the current practice in DCTerms.

[tombaker]

PROPOSED TEXT FOR PUBLIC COMMENT

In light of public comment and expert feedback on a proposal for dcterms:accessibilityNote property earlier this year, the Usage Board finds that:

1. DC Terms should support accessibility. The comments received on dcterms:accessilityNote in February generally affirmed the need for a property about accessibility. Accessibility is already supported by other metadata standards, such as MARC, Schema.org, and EPUB.

2. Metadata based on free-text values is not precise enough. Accessibility metadata can be used to filter search results or configure interfaces based on user needs, but only if it is "structured" in a "machine-readable" way using controlled vocabularies. Describing accessibility features in free text is no substitute for tagging those features with actionable precision.

3. Existing vocabularies for accessibility use lexical terms. The accessibility vocabularies most widely used in metadata today are those defined for Schema.org. The Schema.org vocabularies define lexical terms for several types of accessibility concepts: APIs ("AndroidAccessibility"...), input methods ("fullKeyboardControl"...), content features ("synchronizedAudioText"...), access modes ("tactile"...), and hazards ("flashing"...). Each vocabulary is paired with a corresponding property. The vocabulary of accessibility hazards, for example, is paired with the property https://schema.org/accessibilityHazard, and its lexical term "none", for example, derives from the context provided by that property its actionable meaning: "no hazards".

4. Accessibility terms need URIs. In order to use accessibility concepts from Schema.org in linked data, the union catalog of Swedish libraries (LIBRIS) assigns them provisional URIs under one of its own domains. The URI https://id.kb.se/vocab/accessibilityHazard/none defines the concept of "no hazards" with actionable precision.

We propose the creation of two properties:

1. dcterms:accessibility for use with concept URIs. We propose the creation of dcterms:accessibility on the model of dcterms:subject. The Subject property is intended to be used with URIs of topics irrespective of type (whether person, geographic location, or other type of topic). In practice, the values of Subject are often SKOS concepts. By analogy, the Accessibility property would be intended for use with accessibility aspects irrespective of type (whether input method, content feature, access mode, or hazard). In contrast to Subject, however, Accessibility would be defined with a strong expectation that its values be URIs.

dct:accessibility a rdf:Property ;
  rdfs:label "Accessibility"@en ;
  rdfs:comment "A feature or deficiency of a resource that enhances or impedes its accessibility."@en ;
  dcterms:description "Values should be drawn from controlled vocabularies, preferably identified with URIs. `dcterms:accessibilitySummary` should be used for free-text descriptions." ;
  dcam:rangeIncludes skos:Concept .

2. dcterms:accessibilitySummary: for free-text annotations. Inasmuch as most accessibility vocabularies today are not based on URIs, the availability of just one property with a hard requirement for URIs would set the bar for metadata producers unrealistically high. We therefore propose the creation of a second property, dcterms:accessibilitySummary, for information about the accessibility of a resource in free text. This property

dct:accessibilitySummary a rdf:Property ;
  rdfs:label "Accessibility note"@en ;
  rdfs:comment "A statement describing features or deficiencies of a resource 
      that enhance or impede its accessibility."@en ;
  dcterms:description "Features or deficiencies that can be identified with
      a URI should be described using `dcterms:accessibility`."@en ;
  rdfs:range rdfs:Literal ;
  rdfs:subPropertyOf dct:description .

Questions for public comment

1. Is it useful to have a dcterms:accessibility property that is intended to be used with value URIs? Would it be helpful if this intention were strengthened by defining a formal range of skos:Concept?

2. Is it useful to have a property for free-text descriptions of accessibility? Is it clear from the definition that this property is not intended for use with controlled vocabularies of lexical terms?

[kcoyle]

"Metadata based on free-text values is not precise enough." Precise enough for what? I suggest:

"Metadata based on free-text values is not sufficient for automation functions."
"Metadata based on free-text values does not lend itself to machine-readable functions."

Something like that, saying what "enough" means in this context.