-
Notifications
You must be signed in to change notification settings - Fork 10
Need roles for page-level running header and footer #24
Comments
Perhaps the existing |
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. |
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. |
@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. |
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? |
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. |
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. |
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. |
Moved to dpub-aria. |
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.
The text was updated successfully, but these errors were encountered: