w3c / a11y-discov-vocab Goto Github PK

Should also include EPUB example

<package …>
   <metadata>
      …
      <meta
          property="schema:accessibilityHazard">
         flashingHazard
      </meta>
      <meta
          property="schema:accessibilityHazard">
         noMotionSimulationHazard
      </meta>
      <meta
          property="schema:accessibilityHazard">
         noSoundHazard
      </meta>
     	…
   </metadata>
   …
</package>

Should we also include the "none" case which would be the most common?

When the vocabulary was first created, using slashes was the way to extend things. This method was retired a number of years ago now in schema.org, but we still mention it as a means of extending values.

We should see if there's a better practice we can follow, like what I mentioned in #3 (comment)

In ONIX code list 196, the certifier contact can be given to the end customer:

• 98 = Trusted Intermediary contact
• 99 = Publisher contact for further accessibility information

Nota: for some reason, there is no 100 value for the independant organization contact. This kind of organisation probably refuses to manage publishers' customers, and become their hotline (which is not their mission at all).

It would be interesting to mention that there is no correspondance for this information in Schema so far.
The value of this new accessibilityContact property could be a pointer to a Schema https://schema.org/Organization eventually.

under accessibilityFeatures, there are two values currently which do not follow the naming convention.
ChemML
MathML

These I think should be:

chemML
mathML

ONIX code list 81 Product content type was initially used to describe the content of the publication BEFORE accessibility adaptations.
Trying to use it, as combined with the code list 196, to value the accessModeSufficient property, meaning AFTER adaptation, is quite a challenge indeed. The warning was worth it. :-)

Some inference was tempted on textual value. But not on visual. Nor on auditory value (except for audiobook, which is not a complex inference...). Though there are ONIX values addressing specific adaptations.
As a matter of fact, the ONIX code list 196 available values cannot be used for any reliable inference of accessModeSufficient = visual or auditory values:

• 14 Short alternative descriptions (still /moving image, audio file/track)
• 15 Full alternative descriptions (same)
• 20 Synchronised pre-recorded audio
• 28 Full alternative audio descriptions

Maybe that would be interesting to keep track of this, to avoid redoing all the analysis, or to avoid believing that something is missing in the correspondance table, regarding visual and auditory values of accessModeSufficient.

The EPUB a11y:certifiedBy metadata has an equivalent in ONIX: code list 196, code 93 (Compliance certification by).
Could you correct this please? As a matter of fact, the lack of translation is very misleading on ONIX expressive power, for those who are not ONIX experts.

We don't explicitly state whether to set access modes for content that is purely presentational.

If a book has a few decorative images, for example, does it still have a visual access mode? Does it have both a visual and textual sufficient access mode and a textual one, or does it only have a textual access mode?

I've always assumed that you wouldn't set an access mode for presentational content, but I'm going solely by the word "information" in the definition.

Would help to be clearer on this.

<Many of these properties were derived directly from the Global Access for All (AfA) Information Model Data Element Specification . >

Is missing IMS in the link. Should be:

<Many of these properties were derived directly from the IMS Global Access for All (AfA) Information Model Data Element Specification .>

In the 2. Schema.org and ONIX section, and its correspondance table, the last cell contains Human-readable text. As if it was a Schema property, which is not.
It might be better to put this information elsewhere.

In the 1. EPUB and ONIX section, the following correspondance rule is missing.
dcterms:conformsTo with the URL [dcterms:conformsTo with the URL http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa](http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aaa)

So far, there is no ONIX corresponding value in the code list 196. Which must be pointed out , so it can evolve in the future.

In the 2. Schema.org and ONIX section,

1. the Schema value braille can be mapped to ONIX.
   Code from code list 21:

• BRL = Braille edition

2. The other way around, ONIX braille type cannot be mapped onto Schema which is not accurate enough.
   Codes from code list 175:

• B701 = UK Uncontracted Braille
• B702 = UK Contracted Braille
• B703 = US Braille
• B704 = US Uncontracted Braille
• B705 = US Contracted Braille
• B706 = Unified English Braille

This must be pointed out so it can evolve in the future.

While reviewing the accessibilityFeature values, I noticed that we have "printPageNumbers" but don't have a value that specifically indicates that page navigation is available.

There's maybe a fine distinction here, but indicating a publication has print page numbers doesn't necessarily mean that it has a page list (although you'd sort of hope that would be the case). Similarly, as we know, if a publication has a page list it doesn't mean that page breaks have to come from a print source, which makes what to specify for that case confusing.

My suggestion is that we introduce an explicit "pageNavigation" value to use when a publication has a page list. It can be paired with "printPageNumbers" to indicate that the publication's static pagination matches a print source.

Consider adding the Fuchsia accessibility protocol to the accessibility APIs section (currently section 2.2).
https://fuchsia.dev/reference/fidl/fuchsia.accessibility

Currently defined as:
<The structures in a PDF have been tagged to improve the navigation of the content.>

This is a bit misleading. An untagged PDF presents no content to a screen reader. It isn't just inadequate navigation/structure.

Proposed change:
<The contents of a PDF have been tagged to permit screen reader access.>

It could be more general, such as "AT access" or "to ensure accessibility". Other AT that might need it would be read-aloud tools, for example.

I think the syntax of the metadata property values could be clarified further. Based on reading the draft, the syntax appears to be
case-sensitive identifier, followed by zero or more optional extensions, where an optional extension consists of a slash ("/") followed by an identifier.

Section 4.2.4.3 (Braille) presents a series of extensions that make the most sense if more than one can be specified. However, I didn't notice a formal definition of the syntax If only one extension can be specified, then this would be an issue in the braille case, as a document can conform to multiple braille codes (e.g., "braille/grade2/math").

My suggestion would be to specify the general syntax early in the document, and to define what an "extension" is.

It should perhaps also be specified that processors should ignore values or extensions that they don't recognize (but they may issue a warning), unless of curse they are validators.

Hi!

I found this specification while reading the EU standard EN301549, which (in version 3.2.1) states that "It is best practice to provide meta data on the accessibility of the document within or separate to the document using WebSchemas/Accessibility 2.0". The reference points to a W3C wiki page, which in turn guided me to this Github instance.

The EN 301549 is tightly connected with EU regulation via the Web Accessibility Directive (WAD), and the standard is relevant even in many countries outside of the EU. The a11y-discov-vocab should earn at least some credibility and momentum thanks to the multiple references from the latest version of the EN standard, even if the references are only "best practice" and only indirect via the w3c wiki page!

One of the central requirements in the WAD is that all public sector bodies must provide an accessibility statement for each of their websites and apps (including documents such as PDF files that may be distributed there). It would therefore be useful if the metadata schema pointed out in the EN standard could be used to communicate the URL of the mandatory Accessibility Statement. However, I cannot find a suitable property for this in the specification. I guess I could use schema: accessibilitySummary (https://w3c.github.io/a11y-discov-vocab/#accessibilitySummary ) and put a URL as part of a text field, but having a separate, typed, property such as eg. "schema:accessibilityStatementURL" would be more useful. (Easier to use for automated retrieval, automatically presented as a clickable link, possibly with a standardized symbol, and so on..)

Would you be interested in adding such a property to the specification?

Or, perhaps there are other better options for indicating the location of a relevant Accessibility statement? Is there already a standardized metadata schema for pointing out the location of VPATs, that could be used? (I haven't been able to find one, but it could exist.) Or, a standardized path (part of URL) could be another alternative, similar to how the "/robots.txt" path can be expected to contain site-owners preferences for automated indexing. But for downloadable items such as pdf files a standard metadata element would be a better option since it is not always apparent from what site the file came.

Schema.org has defined semantic properties. Both names and values are set up for accessibility properties.
Unfortunately, this does not show up in the Schema.org 2 ONIX mapping table, as property names and property values has been mixed up in the same column.
A Schema.org header is surely required. But with two subheaders underneath (i.e. Names + Values) for a better reading.
Here are the property names to be extracted in a separate column (1rst one then), facing their relevant Schema permitted values (2nd column then), facing ONIX values (3rd column):

• schema:accessibilityHazard
• schema:accessMode
• schema:accessModeSufficient
• schema:accessibilityControl
• schema:accessibilityAPI
• schema:accessibilityFeature

Please note that in the list above, I also added the name space prefix before each schema.org property (i.e. "schema:") to make it even clearer.
Hoping you can improve the layout of this table.

Update the document to prevent horizontal scrolling in examples like we did in other specifications.

I raise this issue on behalf of the technical committee of the Japan DAISY consortium. (I am ccing @xfq, @kidayasuo, @r12a, and @himorin).

The current definition of rubyAnnotations in Schema.org Accessibility Properties for Discoverability Vocabulary indicates whether or not ruby annotations are present. But this is not good enough.

Attaching ruby annotations to all CJK ideographic characters in a publication is called "fully-annotated ruby". If you have really serious problems with CJK ideographic characters, you prefer fully-annotated ruby. The most common request from users of Japanese DAISY textbooks is fully-annotated ruby. Meanwhile, attaching ruby annotations to some (typically, difficult ones) is called "partially-annotated ruby". Many Japanese publications provide "partially-annotated ruby".

Accessibility metadata should indicate whether a given publication allows "fully-annotated ruby" or "partially-annotated ruby". Note that an electronic publication may allow both "fully-annotated ruby" and "partially-annotated ruby" by the use of different styles. Thus, accessibility metadata should be able to represent four possibilities: (1) "fully-annotated ruby" but not "partially-annotated ruby", (2) "partially-annotated ruby" but not "fully-annotated ruby", (3) both "fully-annotated ruby" and "partially-annotated ruby", and (4) neither "partially-annotated ruby" nor "fully-annotated ruby".

9. Examples
   9.1 Book

   <meta itemprop="accessibilityControl" content="fullKeyboardControl" />
   <meta itemprop="accessibilityControl" content="fullMouseControl" />
   <meta itemprop="accessibilityAPI" content="ARIA" />

We are planning on deprecating these so we should remove them from this example.

Also it looks like we are combining two examples in one here

ie:

 ...
  <meta itemprop="accessibilityHazard" content="noMotionSimulationHazard" />
   <meta itemprop="accessibilityHazard" content="noSoundHazard" />
   <meta itemprop="accessibilityAPI" content="ARIA" />
   <dl>
      <dt>Name:</dt>
      <dd itemprop="name">Holt Physical Science</dd>
      <dt>Brief Synopsis:</dt>
      <dd itemprop="description">NIMAC-sourced textbook</dd>
  ...

Trying to find out when the tableOfContents value got misplaced made me wish it was possible to view old versions of the vocabulary. I had to go to the wayback machine before discovering it was missing from the wiki.

Propose we manually add a "previous version" link and keep a dated copy of each release. It only adds one simple extra step to the release process (i.e., to copy the dated file that respec generates and then replace the index.html file in /latest).

2.2.9 MacOSXAccessibility: Indicates the resource is compatible with the iAccessible2 API for Windows.

Should be: MacOS

The content is in braille format, or alternatives are available in braille. This value can be extended to identify the different types of braille (/ASCII, /unicode, /music, /math, /chemistry or /nemeth), and whether the braille is contracted or not (/grade1 and /grade2). Other extensions such as the code the braille conforms to can also be specified.

Since we do mention /nemeth we should also mention /ueb to be consistent.

We have a lot of access modes that appear to only exist to describe if certain types of content are represented visually, but is this the same thing as an access mode?

What does it mean to have to read "chemistry in a visual" from a sensory or perceptive sense as opposed to just having to read visually? Where do these "onVisual" terms end if we have to account for anything? How do you combine them with "visual" to enumerate the various sufficient access modes that could result?

Should we deprecate these terms? (We've never tried to make sense of them for epub.)

4.2.4.8 longDescription

Descriptions are provided for image-based visual content and/or complex structures such as tables, mathematics, diagrams, and charts.

I think we will need to spell out here that this doesn't required the html attribute of longDescription, that any method for conveying an extended description applies here be that a link to the description, aria-describedby, summary/details etc.

I'm sure we've discussed this before, but ARIA isn't an accessibility API but more of a bridging technology between semantic-less HTML and the APIs.

The accessibilityAPI property is more for describing whether reading systems behave with the platform APIs, so isn't something we should be setting for publications. If we move the ARIA value to the features list, we could omit any need for this property (for publications, not suggesting we drop it).

That said, we might want to replace it with something more generic like accessibleScripting so that we can identify all dynamic content that is accessible, not just content that has to use ARIA.

Should there be an optional extension for distinguishing between open and closed captions?
Examples: "captions/open", "captions/closed".
Does this matter in describing media resources?

The A.1 Informative references section is lacking the link to Schema.org Accessibility Properties for Discoverability Vocabulary.

It is highly important to correctly source this standard, as Schema.org web site does not provide the list of ALL accessibility properties it has defined. Many people think there is one property = "accessibilityFeature", which is not the case. There are 6 accessiblity properties in Schema:

1. accessMode
2. accessModeSufficient
3. accessibilityControl
4. accessibilityHazard
5. accessibilityFeature
6. accessibilityAPI

With N values for EACH. Futhermore, authorized values for each property have changed location in the pages. They are no more directly provided for each property's page. They are hidden behind this sentence now: "Values should be drawn from the approved vocabulary"

Only the Schema.org Accessibility Properties for Discoverability Vocabulary provides the full picture about the way Schema handles accessibility metadata (i.e. properties, and values).

The following values appear to be new since the crosswalk was last updated:

Daisy has discouraged the use of schema:accessibilityAPI property in the EPUB.
http://kb.daisy.org/publishing/docs/metadata/schema.org/accessibilityAPI
With the true argument that "The issue of compatibility with operating system accessibility APIs is not applicable to digital publications. The means by which information is conveyed to accessibility APIs is a reading system concern."

But unfortunatley, one value of schema:accessibilityAPI property does not concern the OS, i.e. the ARIA value.
ARIA attributes (such as @aria-role, @aria-label, @aria-labelledby, @aria-describedby) must be set inside the EPUB in the first place, so that the reading system may expose them in the ARIA API.
If this ARIA communication mode is not reported anymore anywhere, there is a risk that publishers totally forget about putting any ARIA attributes when needed.

Blackberry OS was discontinued in 2013 and support for their devices ended in 2016. Blackberry sold off their phone division and the newer ones use Android. (I'm not sure if anyone even still makes phones under the brand.)

I wonder if we can drop this, or at least come up with an obsolete indicator?

In the 2. Schema.org and ONIX section, the Schema values certifiedBy + certifierCredential can be mapped to ONIX.
From code list 196
Code 93 = Compliance certification by
URL of a web page belonging to the organisation responsible for compliance testing and certification of the product – typically a ‘home page’ or a page describing the certification scheme itself.

Nota: remember that anybody qualified can certify the conformance: the publisher, a trusted intermediary (subconstractor), or an independant organism. This is why the customer must know who certified. In order to measure the level of trust of the certification.
This is also why ONIX requires complementary information on the certification+certifier.

Small nit.
In section 4.1
the term "none" broken internal links.

4.2.4.13 tactileObject

The content is a tactile 3D object, or the model to generate one is included.

I would think this should be
The content contains a tactile 3D object, or the model to generate one is included.

The Japan DAISY Consortium proposes to add two values for the use or non-use of space as word dividers in Japanese text. Either or both of these values may be specified for a given EPUB publication. 　

Although this proposal is dated in 2021 March, we hope to make more experiments before we finalize these values. I explained this idea to CLREQ people.

1) wordDividers/display

A Japanese EPUB publication containing this value can be rendered with space as word dividers as explicitly specified by its author.

<meta property="schema:accessibilityFeature">wordDividers/display</meta>

2) wordDivider/non-display

A Japanese EPUB publication containing this value can be rendered without space as word dividers.

<meta property="schema:accessibilityFeature">wordDividers/non-display</meta>

For more background information, see Discovery of Space as Word Dividers.

At the moment I can't reach the actual web page that has it (browser can't find idpf.org) but archive.org had it - in 'META-004: Identify accessibility hazards' with respect to audio it mentions:

sound — certain sound patterns, such as ringing and buzzing, can cause seizures.

There does not seem to be an expansion on that, for how to evaluate an audio as to whether or not it may have one of the patters that can be a trigger. I tried searching the web for an evaluation method but did not find one.

Can the doc be updated to give a reference for evaluation?

-=-

Also somewhat related, maybe belongs with WAI for inclusion in their WCAG general techniques and not here - many people (myself included) have an autistic input overload trigger caused by either loud audio or sudden changes in audio volume. I couldn't watch Big Bang Theory because they mixed the laugh track to be really loud compared to the rest of the show, for example, causing an input overload that stressed me.

Using loudness normalization as specified in EBU R128 should be an accessibility technique for audio and video - either by providing the metadata tags or (what I do with audio) applying EBU R128 to the source before lossy encoding, so that it is loudness normalized even if the player doesn't support the metadata tags.

EBU R128 isn't the only scheme but it is the best (ReplayGain for example I believe only takes RMS into consideration which is often inaccurate method) and EBU R128 seems to be gaining a lot of support in the broadcasting industry, including streaming services, so if a user has their volume set what they like when listening to spotify and they then open an ePub with an audio or video that uses EBU R128 the perceived loudness will be where they want it.

We should be consistent here in the pro/con values for hazards, as this is a common issue for publishers.

Currently we have:

• flashing
• noFlashingHazard
• motionSimulation
• noMotionSimulationHazard
• sound
• noSoundHazard

We either should have "Hazard" added to all of them or none of them.
Since the property is "accessibilityHazard". I don't think we also need to include "Hazard" in the value's name.

4.2.5 none
Indicates that the resource does not contain any accessibility features.

Should not be bolded.

8. The accessModeSufficient property
   8.1 Application

I think we should include what we have stated in our User Experience Guide here as well for accessModeSufficient of textual.

From our document:
If this metadata exists (ie. textual within accessModeSufficient by itself) then report Screen Reader Friendly: Yes

Important: This is not the same as visual, textual or textual, visual because the combination means that the book requires both visual and textual abilities to access the data, not textual alone. Only having accessModeSufficient be textual as a separate entry ensures the document is screen reader friendly.

The Japan DAISY Consortium proposes to add four values for CJK writing directions. At most one of these four values may be specified for a given EPUB publication.

Although this proposal is dated in 2021 March, we hope to make more experiments before we finalize these values. I explained this idea to CLREQ people.

1) cjkWritingDirection/vertical-writing

The EPUB publication containing this value can be rendered in the vertical-writing mode. Vertical-writing stylesheets are embedded.

Note: Some text in vertical-writing publications may be in the horizontal writing mode.

<meta property="schema:accessibilityFeature">cjkWritingDirection/vertical-writing</meta>

2) cjkWritingDirection/horizontal-writing

The EPUB publication containing this value can be rendered in the horizontal-writing mode. Horizontal-writing stylesheets are embedded.

<meta property="schema:accessibilityFeature">cjkWritingDirection/horizontal-writing</meta>

3) cjkWritingDirection/vertical-writing-alternate-horizontal-writing

The EPUB publication containing this value can be rendered in both the vertical-writing and horizontal-writing modes. But the primary target is vertical writing. When the horizontal-writing mode is used, the result might not be totally satisfactory.

<meta property="schema:accessibilityFeature">cjkWritingDirection/vertical-writing-alternate-horizontal-writing
</meta>

4) cjkWritingDirection/ horizontal-writing-alternate-vertical-writing

The EPUB publication containing this value can be rendered in both the vertical-writing and horizontal-writing modes. But the primary target is horizontal writing. When the vertical-writing mode is used, the result might not be totally satisfactory.

<meta property="schema:accessibilityFeature">cjkWritingDirection/horizontal-writing-alternate-vertical-writing
</meta>

For more background information, see Discovery of the Writing Direction.

The Japan DAISY Consortium proposes to add three values for the use of ruby in Japanese EPUB publications. One, two, or all of these values may be specified for a given EPUB publication. 　

Although this proposal is dated in 2021 March, we hope to make more experiments before we finalize these values. I explained this idea to CLREQ people.

1. rubyAnnotations/general

An EPUB publication containing this value can be rendered using the general-ruby method.

<meta property="schema:accessibilityFeature">rubyAnnotations/general</meta>

2. rubyAnnotations/para

An EPUB publication containing this value can be rendered using the para-ruby method.

<meta property="schema:accessibilityFeature">rubyAnnotations/para</meta>

3. rubyAnnotations/source

An EPUB publication containing this value can be rendered in a way which all ruby annotations in the source (typically printed) publication are faithfully mimicked.

<meta property="schema:accessibilityFeature">rubyAnnotations/source</meta>

For more background information, see Discovery of the Accessible Qualities of Ruby.

I think the aims of the group are broader than reading, so I suggest we remove that word from the Charter section on Goals.

We've started off embedding the change log in the vocabulary: https://www.w3.org/2021/a11y-discov-vocab/latest/#change-log

While this works for specifications, the vocabulary never "resets" its change log with a new revision, so the log will continue to grow for however long we maintain the vocabulary. That has the potential to get unwieldy.

I'm thinking it might be better to create a separate page we host in the repository that contains the list of changes.

There are problems in ONIX correspondance on certifierReport Schema property:

• wrong definition of 94
  Compliance web page for detailed accessibility information or, if a publisher is self-certifying
• lack of value 95

I agree that ONIX labels are heterogeneous and misleading. It is necessary to read definitions to understand what it is all about.

In ONIX, there are 3 types of conformance certifiers: publisher / trusted intermediary / independant organization.
Any certifier must provide a web page of conformance, containing tests results "relevant to this product". Each EPUB in other words (sic).

ONIX provides the means:

• to indicate who produced the conformance web page,
• to eventually provide multiple conformance web pages: publisher's one, intermediary's one, independant organization's one.

This is what the 3 following values are made for, in ONIX code list 96:

• 94 = Compliance web page for detailed accessibility information - look at the definition that clearly refers to "independent compliance scheme or testing organization" (=> independant organisation)
• 95 = Trusted intermediary’s web page for detailed accessibility information (=> trusted intermediary)
• 96 = Publisher’s web page for detailed accessibility information (=> publisher)

Hi from Schema.org!

It is great to see all the work on this recently.

We would love to know more about how this markup is being used, or efforts to use it, i.e. in data-consuming applications, as well as by publishers, content producers etc. Also any other specs (epub?) that reference it. Thanks for any pointers!

Should we add "unknown" as an option for accessiblityFeature?
One could just not include accessibilityFeature I assume but wanted to open this up for discussion.

Schema property accessMode / accessModeSufficient audio value has not been mapped to any ONIX value, as if there were no equivalent information in ONIX code list 81 Product content type.
The problem is not having nothing there... :-) It is having too much there! ONIX has defined a long list of specific values (same problem for images mapped onto visual Schema value). ONIX forgot to define a generic value (as for 06 Video to be mapped onto visual Schema value too):

• 01 Audiobook
• 02 Performance – spoken word
• 03 Music recording
• 04 Other audio
• 13 Other speech content
• 21 Partial performance – spoken word
• 22 Additional audio content not part of main work

It would be interesting to mention this, as it was done for visual Schema value.
This would help us align Schema / ONIX properties' values.
This would help EDItEUR add new neutral image + audio values that are still missing in ONIX code list 81 Product content type.

ONIX list 196 code 10 No reading system accessibility options disabled (except) could probably be mapped onto
schema:accessibilityControl metadata, for all its values, i. e. fullKeyboardControl, fullMouseControl, fullSwitchControl, fullTouchControl, fullVideoControl, fullVoiceControl.

In my understanding, controls are part of the reading system accessibility options. As a matter of fact, the ONIX definition of code 10 clearly says "No accessibility features offered by the reading system, device or reading software (including but not limited to choice of text size or typeface, choice of text or background color, text-to-speech) are disabled, overridden or otherwise unusable with the product".

Interactive content implemented in JS (events managt) could be concerned typically (without any way for the RS to apply its options).

Furthermore, this means that this ONIX metadata does not describe the reading system controls themselves, but rather indicates wether the current EPUB prevents or not the reading system to run any of these controls (if available in the RS of course). In this sense, this ONIX metadata is properly an ebook property, that should be kept on the EPUB, as a complement to the reading system properties. As a matter of fact, they both need to be compliant so that the controls can work for the end user.

Could schema.org schema:accessibilityControl metadata be assigned both to the EPUBs and to the RS?

We should review the titles and categorization of the terms, as I believe this was added to the wiki only to help break up the long list of values.

I was skimming the values and noticed some, at least, may be misplaced -- highContrastAudio isn't necessarily in a transformed state or able to be transformed, for example, and neither arguably is large text print (it may be the only way it's published and large print isn't necessarily intended for further transformation).

I have a strong suspicion that the "bookmark" value for accessibility feature was intended for PDFs, which is more of a table of contents. There's a WCAG technique about adding them, after all, and I don't recall promoting this for ebooks when we created the vocabulary.

Putting aside the fact we don't have a common means of distributing the kind of digital "dog-ear" bookmarks reading systems provide, is there a special accessibility case for them even if we could? They can be generally useful for all users, but what would be the scenario where they add accessibility that is missing? I can't imagine professors distribute dog-eared copies of print course material to their students, for example.

Anyway, if this is a PDF feature, it would be good to clearly label it as such and equate it with a table of contents.