Skip to content
This repository has been archived by the owner on Jan 17, 2019. It is now read-only.

Need roles for page-level running header and footer #24

Closed
aleventhal opened this issue May 14, 2018 · 9 comments
Closed

Need roles for page-level running header and footer #24

aleventhal opened this issue May 14, 2018 · 9 comments

Comments

@aleventhal
Copy link

aleventhal commented May 14, 2018

When a word process displays a "WYSIWYG" layout and shows running headers and footers, we need a role to describe them.

FWIW, it does not appear that HTML 5's <header> and <footer> are intended for running, paginated headers and footers.

Therefore, perhaps to differentiate clearly, it may be good to use names such as doc-pageheader and doc-pagefooter.

@TzviyaSiegman
Copy link
Contributor

Perhaps the existing role="contentinfo" is what we need? I don't think that we can indicate the fact that an element is recurring (running).

@mattgarrish
Copy link
Member

This has been a long-running struggle in EPUB. We had oeb-page-head and oeb-page-foot custom css display properties for these, but reading systems never utilized them and they were deprecated while awaiting a web-friendlier alternative.

ARIA roles could help, but I'd think we'd also need to find out what sort of uptake there would be for them (what they get attached to, how the running headers/footers work, etc.).

I don't know that it would help change the EPUB situation, though, as reading systems ignore authoring intent. Running headers and footers are displayed outside the current document so also outside the reach of AT.

@aleventhal
Copy link
Author

We can't really use role="contentinfo"|"banner" etc. because those are landmarks. As such, they will be injected into the landmark cycle. It would be annoying for a 100-page document to have the same contentinfo landmark 100 times (as opposed to 1 table of contents and 1 endnote section, etc.).

I'll do more asking around on the desired end-user experience. Perhaps we should keep it open for now.

@aleventhal
Copy link
Author

@mattgarrish Regarding uptake, we're in a position to drive this through implementations in Chrome, NVDA and JAWS, as part of Google Docs work we're doing.

@dauwhe
Copy link

dauwhe commented May 15, 2018

Note this probably isn't a great repo for these discussions. The Digital Publishing Interest Group no longer exists. And the use cases sound rather broader than digital publishing. Should this perhaps be discussed in ARIA?

@deborahgu
Copy link

Not disagreeing with @dauwhe, but I'd reemphasize the fact roles are specifically about user experience, not about the markup needed for layout or other authorship purposes. And I'd like to emphasize the problems inherent in TEI, which added markup for every kind of semantic or layout markup they could think of, and which has had very limited adoption, much of which because of problems cause by that layer of granularity.

The question of the ways in which "role" has been (reasonably) extended by the webdev community conflict with its interaction with ATs , which is a real concern, is definitely a subject for ARIA.

@mattgarrish
Copy link
Member

I'd reemphasize the fact roles are specifically about user experience, not about the markup needed for layout or other authorship purposes.

These are potentially important semantics for the user experience, in my opinion anyway. Imagine if the headers and footers are announced to the user every time they reach the bottom/top of a new page, or wherever in the markup they are declared. That would get annoying and/or confusing fast. That it doesn't happen in EPUB is a quirk of reading systems.

It also seems similar to the problem with pullquotes. In general, the user isn't going to be interested in the running headers or footers, but there may be times where they want to reference the information.

At any rate, I agree that the role shouldn't be the mechanism that creates them. The role should simply identify the purpose of the markup that is already being used to achieve them, and provide the necessary information to AT to handle them as the user desires. That's why I think we'd need more information on how they're implemented.

But, yes, I didn't even notice that this wasn't in https://github.com/w3c/dpub-aria Definitely not the right place to continue this discussion.

@aleventhal
Copy link
Author

Apologies for filing this in the wrong place.

FWIW, a screen reader user today told me: "I had an experience last week with a page header that was less than ideal. A lawyer added confidential indication into the header and I had no idea it was there until they happen to mention it."

This user suggests that screen reader users be able to turn on/off the verbalization of running headers/footers, column breaks, etc. This can be done in the screen readers once the semantics are exposed.

I guess we need to move this thread to dpub-aria.

@aleventhal
Copy link
Author

Moved to dpub-aria.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants