New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SC2.4.13 Fixed Reference Points needs another technique #1226
Comments
Techniques are only one method of meeting a guideline, it is explicit that there can be other ways. The Adobe reader example would be user-agent based, but if there is another method all we're looking for is someone to write it. @DavidMacDonald do you know who might tackle this? |
I've put out some requests to the epub group. |
NOTE: Sufficient technique are just examples of ways to successfully meet the SC. Developers can satisfy the requirements any way they want if the SC text has been met. |
Any techniques must fully meet the criteria in all aspects and not one aspect unless they are clearly marked with an AND statement with another techniques -- and even then it's very confusing for implementers. |
@DavidMacDonald Thank you for putting out the call. We all of us here know that techniques are only advisory and others can be used, because we work with the WCAG all the time. But many developers coming new to the subject may not know that, and may be somewhat wary of going outside recommended ways - especially when there is only one recommended technique showing for an SC. So having a few will be good. |
I'd note that for EPUB the user experience is typically the same as for PDF - the user would only directly access the list as a worst-case fallback. In EPUB, the page list is designed as a machine-readable input to the reading system so it can produce such an interface so authors don't have to code their own solution. The same is true for the W3C Audiobooks specification. (You have to follow the given list pattern, in other words.) The difference from PDF, of course, is that in PDF the page breaks are the pages of the PDF. The author doesn't have to encode anything. This is more akin to the virtual pages generated by reading systems. In a purely HTML rendering (no reading system, even a browser-based one), I'd expect the author would script a more user-friendly interface to the page locations. I'm not aware that there is a common pattern for how to do this, though. It's not that publishers don't offer HTML publications, but at this level there's no standardization. |
Actually, thinking about the existing Technique H99 a bit more, I don't think this alternative method even needs a new technique. The listbox selector method is held in H99 as Example 1. So the page number selector by input field and form could be added as Example 2. It would just mean renaming the technique slightly to something that covers both the listbox and number-input methods. Maybe call it "Providing a page selection mechanism". And a second test would be needed to cover the number-input method. Both methods depend on the same static anchors in the HTML. |
From George at daisy
|
Thanks @DavidMacDonald for spelling these out. By Is the MS Word functionality essentially the same as PDF? Most of us probably have the experience with PDFs where, if the author was not careful, the PDF page number (as reported by Adobe Reader) is out of sync with print page number. Does Word have this same problem? Regarding David's three examples, does anyone disagree that each is sufficient for meeting SC 2.4.13? |
@mraccess77 that is my point -- I don't recall ever having difficulty with the way Word handles restarting the page numbering, but it is pretty common in my experience for PDF pages numbering (as reported by the app) to be out of sync with the print page numbering. OTOH, I would be hard pressed to articulate exactly what is different between Word and PDF, since they both provide for As written, does 2.4.13 fail poor use of fixed reference points (as happens with PDFs, if the author is not careful)? I don't think so! |
@aubbink1 Reading the thread, I think the action is to add another example to H99. See this comment. |
@guyhickling and @DavidMacDonald , I've created a first version of these changes. I could use another set of eyes to make more modifications. |
The updates via #2130 were merged today, so I'm closing this issue. |
Many thanks for adding that example to the Technique. I've just seen the May 3 Editor's Draft. BTW just for the record, the SC in question has now become SC2.4.14 since I raised this issue, not .13. However since this has been closed I guess there's not much point in amending the title now. |
This is to suggest another Technique for this new WCAG 2.2 SC. I realise the Understanding document and the associated techniques are still work in progress and someone probably already has this in hand. So this is just to raise a GitHub issue to ensure it isn't forgotten, since the only technique for it so far is a very clumsy one.
The most obvious way to help a user locate a page by its number is by providing an input field for them to type in the number. So it merits its own Technique document.
For instance Acrobat Reader uses this method. The input field is in the toolbar above the page display area. Simple and easy to use if you need to find a page by its number.
NB: At the moment the only Technique for this SC, H99, involves providing a list of all the pages in the document. So if an EPUB book has a thousand pages, the list must show a thousand entries and the user has to scroll though them to find the one they want. Not the most convenient solution, but having it as the only official Technique for the SC would imply it is the only W3C recommended solution.
The text was updated successfully, but these errors were encountered: