Create property for repeated content

[joanmarie]

This is related to w3c/dpub-aria#10 and is an idea which @jnurthen mentioned to me. Filing it here so we don't lose it.

The basic idea is this: There may be content which is repeated for visual purposes which a screen reader user may or may not wish to have presented every time it is encountered. One example is running headers and footers in documents with a print-layout presentation. But there are undoubtedly others.

If we create a boolean property a la aria-repeatedcontent, then screen readers could add an option to present (or not) repeated content.

[joanmarie]

(Some publishing-specific notes I don't want to lose track of.)

1. doc-pullquote currently has an example of aria-hidden='true' being set "for presentational purposes only." That makes sense to me given what currently exists in ARIA. However, it could make it difficult for users who are blind to proofread or otherwise examine the visual appearance of the document. We can solve this problem by having doc-pullquote default to aria-repeatedcontent='true' and then remove the suggestion of aria-hidden='true' from the spec. Then the screen reader options could be used to show/hide the pullquote.

2. The to-be-created DPub role(s) related to running header and footer would similarly default to aria-repeatedcontent='true'.

[cookiecrook]

On board with this idea but wanted to suggest a broader approach.

"repeated content" is very specific, so understandability is a bonus, but if I understand correctly, the only purpose is to have this content be skipped in linearized audio scenarios, such as screen reader "read all" functions, or lighter weight AT like "Speak Screen." Is that the intention?

If so, perhaps we should be considering something like aria-linearize: [include (default) | exclude] which leaves an opening for expansion beyond the binary true/false. Note: "linearize" doesn't localize well (z/s) but "presentlinear" felt overly verbose.

[joanmarie]

The term "linearize" strikes me as confusing. And "presentlinear" doesn't clarify it for me. If "repeated content" is problematic, perhaps there's a third alternative.

That said, I think we could expand aria-repeatedcontent from a boolean to a token list IF the need arises. For instance, perhaps we could have true, false, header, footer?

BTW, you mentioned screen reader "read all" functions. I assume that's just one example of what you mean by "linearize" in the context of screen readers. Other examples would presumably include:

• Caret navigation
• Structural navigation / Quick Keys / VoiceOver Rotor navigation (next heading, etc.)
• Page summary ("Page has x landmarks, y headings, and z links")

In other words, something with this property would not be presented by the screen reader -- if the user had opted out of its presentation via a screen reader setting.

[cookiecrook]

After the F2F discussion, I withdraw the suggestion for the broader approach. I think “repeated content” or something similar is easier for authors to understand than the concept of linearized content for screen reader reading modes.

[ZoeBijl]

I think this property is a good idea. Not only for screen readers but also for things like Safari’s Reader Mode or Firefox’ Reader View. It’s another piece of information that can be used to provide a cleaner reading experience; for all kinds of users.

[aleventhal]

PR here, I called it aria-repeated:
#1188

[mlissner]

I'll just add my use case here too, since somebody directed me here. I run a legal research website where citations are made into links. The first time somebody cites something, it'll read something like:

As was said in Roe v. Wade, 22 U.S. 44, blah blah

And we'll make Roe v. Wade, 22 U.S. 44 into a link to the Supreme Court case.

Later in the same webpage, it'll refer to Roe v. Wade again, but instead of referring to the whole citation, it'll say:

And yes, donuts are delicious, Roe, supra at 55

And again we'll add a link to Roe. v. Wade, this time linkifying Roe, supra at 55. It'd be great to be able to have screen readers just not see the second link via something like this.

Legal writing contains dozens of Ids, Supras, and Ibids, and I'm sure they get tiresome to those using screen readers.

[jnurthen]

@mlissner (caveat: I'm not a screen reader user ) This doesn't sound like something you should do.
If the link is being presented visually you should be presenting that same link to screen reader users each time it is encountered.
If for some reason you are not presenting the link visually then we already have ways to suppress the link semantics in ARIA but - again - I really don't think you should be doing that.

[mlissner]

The thought was that a page might have 20 unique citations, but over 100 links to those citations, and that suppressing the secondary links while maintaining their text would be good. I'm very bad at aria stuff, so I apologize if I'm missing something obvious or polluting the thread, but our use case felt similar to what's being described here.

[aleventhal]

Idea: instead of a boolean, how about something like aria-filterable="repeated".
That way if we ever have more ideas on content filters they can be added as other values?

[jcsteh]

I kinda like the idea of aria-filterable or similar. I'm struggling to think of "real" use cases, but it seems like the fact that the content is "repeated" is not the real semantic reason a screen reader user is trying to filter it. Wording is difficult, but it's more that it's semi-presentational; i.e. not purely presentational like a spacer image.

As one example, ARIA DPub has doc-pagebreak, but page numbers are presented using the title attribute or aria-label/ledby. That's normally what you want... but what if a user wanted to see where the page number gets rendered (bottom of page, top of page, etc.)? And right now, if the page number is rendered, you'd have to use aria-hidden to prevent duplication with the label on doc-pagebreak, which seems like a bad thing.

[sinabahram]

@mlissner I must agree that your outlined approach is not desired. I happen to be a screenreader user, and hiding links in this way will lead to many problems, not only for screenreader users but others as well. Your use case presents an interesting situation, but maybe not one addressable in this issue; however, it's most definitely an important use case, having encountered it many times personally.

My stating of the problem:
you've got a document with full citation text being linked the first time of use and then on subsequent citations, an abbreviated form is used. The abbreviated form is also a link. Your concern is that reading the document can be highly irritating because screen readers, even with the abbreviated form, will be saying lots of stuff that can just be skipped over like you can do somewhat with vision by skimming over the citation, once you either expect it's value or don't care at that particular moment. The reason such a concern is valid is because of exactly that last part. A sighted user can choose through the mechanics of visual reading to hop over that sort of stuff, but a screenreader user cannot.

My thoughts:
Those citations are lengthy. It's a problem in the humanities, so we can't fix that. I say that jokingly, but it is also pretty true for audio-consumers of these documents. Now, in computer science, we just make a different tradeoff, which is that citations are numbers, therefore they go by super quickly e.g. "link 5, link 11, link 13). As is clear from that sample speech string, those kinds of citations are also links, and if you apply aria-describedby to them, they can even tell you where they point upon being focused. That sounds lovely, but there's a tradeoff, which is that just by looking at the link, you don't know the reference by name. It's a sliding scale in my opinion, and different disciplines have chosen a different place on that continuum.

So, I hope I've captured everything appropriately, but please tell me if that's not true. My assertion doesn't make me happy, but I claim that these links need to be just as annoying for screen reader users as for anyone else, because I can't think of a mechanism specific to assistive technology (AT) users, which does not disadvantage yet other AT users, that should allow for them to be hidden. The user could indicate some kind of filter, and maybe we could use a microformat or other way of filtering these out, but I'd argue that would be helpful to so many more folks than those with an ARIA-aware mediation layer available to them e.g. some form of AT. Instead, that seems like a website feature that could be easily toggled on/off, no?

[aleventhal]

How about:

• aria-filterable="redundant" -- this covers the case where the content is not 100% repeated (e.g. has a page number that changes), and it's more clear that the first one doesn't get the property
  and
• role="pageheader"|"pagefooter", which would automatically get aria-filterable="redundant". Having these roles will be helpful in that when the user turns off the filtering, it's still nice to know what the object you're reading is

[cookiecrook]

+1 to pageheader/pagefooter roles.

[aleventhal]

@pkra @cookiecrook -- here's what I'm looking for:
Create a PR and mark as "draft" in DPUB-ARIA, making it clear that it's a placeholder, and not intended to be merged at this time, since there is no charter for DPUB ARIA at this time. However, we can still respond to comments on it and get it in a good place.
The PR should add 2 new roles: doc-pageheader and doc-pagefooter (or we may want to call them something like doc-repeatedpageheader or doc-runningpageheader).
These are roles that authors can use to mark content that is optionally hidden by screen readers when the user wants to read published content uninterrupted.
We need to specify:

• whether doc-pagebreak should be included within
• whether page number text should be included, even though it is technically not the repeated, I believe it should be included so that it is also skipped
• whether the first instance of the header/footer should be included -- I believe it should be

The idea is that ATs would probably include this content by default, but alert users of options to hide it during a reading mode.

[aleventhal]

They're going to release a small update to DPUB-ARIA "very soon", so we have a window of opportunity right now.

[aleventhal]

Hi, I'd love to get reviews from w3c/dpub-aria#28
You may have to request to be added to the DPUB_ARIA project here:
https://github.com/orgs/w3c/teams/dpub-aria/members

[pkra]

I think this can be closed or at least out moved out of the 1.3 milestone. On the one hand, dpub-aria now has doc-pageHeader and doc-pageFooter. On the other hand, #1188 (for aria-repeated) was closed with the closing comment mentioning concerns about author misuse. Please feel free to reopen.