Are online word processing and slide applications in scope for 2.4.13 Page Break Navigation #2274
Comments
|
From a quick look at Google docs I can't see anything that would count as a page break locator.
It would need to put in "programmatically determinable destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document.". So you'd be looking for something with a particular role & ID that fulfils that definition. |
|
I think this the kind of detail which would be worthy of a straw poll to the WG. Personally, I am conflicted. I do not think page numbers in Word / Google Docs meets our definition for page break locators. This is regardless if Word online / Google Docs provides a thumbnail style navigation option similar to what is typical with PDF and, for example, Adobe Reader. OTOH, I do think slides numbers in PowerPoint online / Google Slides does meet that definition. Currently, I am of the opinion that 2.4.13 is applicable, and that these two web apps fail to meet 2.4.13. The difference is how slide number == page number and how slide numbers are integral to navigating the content. (In contrast, with word processing, the page numbers are (usually) entirely arbitrary, and merely an artifact of point-in-time presentational formatting for printing.) I am not entirely confident I am being rational here, so I would love to have more discussion about this question. TLDR:
|
Ok, that's good, it matches the intent.
Does the code have something that matches? You'd be looking for something in the code that provides a reference-able page mapping. From a quick look the main area is drawn-on rather than having pages or an appropriate reference in the content. In terms of the intent, the document-editor is closer because that is a stream of content which can have differing representations of pagination. Slides are not, they are 2 dimensional representations of information that has a layout and pagination that is hard-coded. In practice I don't think either are in scope because they don't include page break locators. |
|
My apologies for not linking to the editors draft definition for page break locators, but that is what I had in mind: I have not tried to find in code how the reference-able slides map from the navigation sidebar or sorter. Slide number is the primary index and if slide number is different than page number, I would not personally be able to articulate that difference. The I would be content for WG to concur that slide applications are out of scope for 2.4.13. I am also okay with the conclusion that 2.4.13 applies to online slide applications, but the currently available commercial implementations do not (yet) meet this SC. |
It would need those in order to be in scope. The start of the definition is important as well, it is a programmatic marker, not just a page break. I'm not sure how to phrase it in a definition, but the reason for having them is when there is an alternative version, and the page breaks relates to that alternative version. E.g. HTML to ePub or print. It doesn't drive the page breaks in this document, it represents page breaks in another document. In a slide based product, that just isn't relevant because the breaks are built into the format. In fact, I think having the thumbnails on the left (assuming accessible) would fulfil the SC. It just isn't relevant. Maybe something like: I'm a little wary of fiddling with that, it took a while to get to. |
|
Google Docs seems to use a class to signify page breaks: class="kix-page-paginated". This class would be predictable within Google Docs, but not across other platforms (e.g. the online version of MS Word), so I assume the class would not meet the requirement for being programmatically determinable from a WCAG standpoint. But there is nothing stopping Google from making it programmatically determinable. They would just need to add role="doc-pagebreak" to the same container. Under most circumstances in WCAG we are telling people that they are supposed to make things programmatically determinable. We tell them to add alt text, labels, roles, etc. that are programmatically determinable, and if they don't add those things, we consider those accessibility flaws. With 2.4.13 it looks like WCAG is going to take the reverse stance, meaning that we won't require page breaks to be programmatically determinable, but
This is essentially saying that the authors DON'T need to make something accessible UNLESS they make it available to assistive technologies. It's kind of a strange reversal of how we normally think about accessibility. This is a strangely ironic situation that we're putting ourselves in. In the case of Google Docs (or any paginated document interface) it is possible to convert to alternative formats like PDF or EPUB. In fact, those export functions are usually built in (especially for PDF) or easily available some other way. It's a valid and common use case for a person to say, "go to page 6 of this Google Doc" and all sighted users can easily do that. Blind users don't have an easy way to do that precisely because the page break is not programmatically determinable. Normally this is the kind of situation where we would then say, "...so authors need to make this information available to assistive technologies by making it programmatically determinable." But in the case of 2.4.13 as it's currently written, we're saying "don't worry about it; you didn't make it available to ATs, so you don't have to make it accessible, even though it would be useful to blind people." If the intent behind 2.4.13 is to limit the scope to EPUB, then we need to say that. But then the SC becomes technology-specific, which is against WCAG philosophy, so we can't say it, right? But if the intent is to make all page breaks accessible (because accessibility is good), then we would need to require role="doc-pagebreak" on Google Docs, which we don't want to do, apparently (based on the discussion above). I realize that role="doc-pagebreak" is not standard ARIA (it's intended for EPUB and similar), but what if someone adds it to HTML? Anybody can add it, and the W3C validator does not flag it as invalid, so if Google adds it, then 2.4.13 would suddenly apply, because now the page break is programmatically determinable, right? We need to take this hypothetical question into account, because as it is written right now, IF Google Docs (or any other online interface) adds it, THEN they must provide a navigation mechanism. That's literally what the SC says right now. |
Coming at it without the context, I can imagine it looks like that. There was a proposal for an associated SC which would require that page-break-locators are added in some situations, but no-one could come up with wording that would keep it to the desired scope. There is quite a a specific situation both were trying to address, which is not online document editing. It is for when people reading an HTML version of a document are given a page number from the offline (or other digital) version. So the logic of this SC is that: If you create a version which has the programmatic references in it, create the navigation to them. In other formats (e.g. ePub, PDF) the user-agents to provide the navigation, but not in HTML.
It doesn't apply to ePub, but an ePub document re-purposed for browser-based HTML would be in scope. The understanding doc has a very useful note about that.
Indeed, that is the intent. However, I can't see why they would add such a role unless they intended it to be an ePub reader. (Not authoring, reading.) If they do that then they can either remove it (if it's a mistake) or add navigation to those page numbers. |
|
@paulbohman — I do not think (and do not believe anyone in the WG would assert) that the intent behind 2.4.13 is to limit the scope to EPUB. I characterize (paraphrasing here) the applicability as being for web content where the hard copy print page numbering is of canonical importance. This is typical with PDF and common with EPUB. It is, fortunately, rare with word processing. The print page numbering in a word processing document is, usually, a presentational artifact. I have some ambivalence for slide applications, because I cannot disambiguate page number from slide number, and the latter is a key navigation mechanism. I am hoping someone will share an observation that Google Slides and/or MS 365 PowerPoint Online readily expose the slide number (I, personally, have no idea), and so the issue is moot. Or maybe someone might explain why I should not conflate slide number with Page Break Navigation? |
|
Thanks for the reply. I know this SC is a tricky one to write and to scope. Stepping back from WCAG -- and from all official definitions -- for a second, if we just think pragmatically about how the Google Docs interface is used, it is used both as a reader and as an editor. I don't mean specifically as an EPUB reader, but as a document reader in the abstract sense. Within my company, we use Google Docs a lot for internal purposes. I'll author content and share it. In most cases the other people are simply reading the content. Occasionally they comment on it or they may become co-editors, but if it's my document, my intent is often just to share what I wrote. On the other person's end, they read it, and Google Docs is the reader; it's the reading interface. Once one of my documents is "done," as determined by me, then the pages become a static property of what I wrote, and whether a person reads the document in Google Docs, or exports to MS Word, or exports to PDF, or even to EPUB, the page numbers will all be consistent, and having a way to reference those pages numbers would be useful. Google could add page navigation to their interface -- whether or not they add any new markup to the content -- and that would solve the accessibility problem for blind users. They could also add markup to make page navigation available to ATs. Or they could do both. From a pure accessibility standpoint, the absence of page navigation for screen readers is an accessibility flaw. The flaw exists whether we think of Google Docs as a reader or as an editor. Editors need to navigate to pages too. One way to think of this is that if we think page navigation is important in EPUBs, then why wouldn't we also think it's important in other reader/editor interfaces which clearly have built-in pagination? Google Docs and MS Word online are the clearest and most common use cases. If I'm given the task of explaining to people why this SC applies to EPUBs and not to Google Docs, I will have to fall back to the unsatisfying position of saying, "well, that's just what they decided, but I agree that Google Docs needs that accessibility feature too." I'd rather have an SC that encompassed both EPUBs and online doc editors/readers like Google Docs and MS Word, because that's more defensible. We'd have to rewrite the SC, but I think it's worth it. |
That is rarely the case unless the document is short & simple. You'll find the pagination changes across GDocs, Word and EPUB. Even within Word you (used to?) get differences between Mac and Windows versions of a document. (I was painfully caught out by this with a client.) The lack of a font can cause the pagination to be different. PDF will keep the pagination (part of the reason why it was used originally), but the user-agent also provides the page-navigation there.
There might be a problem there, but it isn't the one this SC was trying to solve. I think Google docs has focused it's efforts on navigating by the outline (headings), rather than pages. I think that's up to them and their intended UX, I don't think it would be appropriate for us to try and insist on page navigation.
It is not that pagination is important for accessibility as such, it is scenarios where people reference the pagination of other versions that is important. If you are working-in / sharing Gdocs or Word docs, that's fine (or at least a different problem), they have their own interfaces that do not necessarily rely on page numbering.
I thought I mentioned this above, but to repeat: It does not apply to EPUB.
We've been through this thought process several times, widening and narrowing the scope. If you would like to make a proposal for a more general page-navigation SC you are welcome to, but it would need to describe a real-world problem. In this case we had the experts from the epub working group describing a very common problem in educational settings. |
|
I teach university courses from time to time, and sometimes students buy physical printed books and sometimes they buy electronic versions of the same books. I will tell them to read pages 42-65 (for example), and they all need to know what pages I'm talking about, so I'm familiar with the problem you're trying to solve. It's part of what I deal with on a regular basis. Part of what I'm saying is that apps like Google Docs also fit into that need sometimes. Here's an example: Someone in my company writes a work order or a contract in Google Docs. The deliverable to the client will probably be in PDF format, but the original remains in Google Docs. In this scenario, the customer could say "please omit paragraph 3 on page 5" or "if you look on page 7 it neglects to take into account X, so we need to change that part." In this case, the customer is referring to the PDF document (or to a printed version of that PDF document), and the author -- or the team of people reviewing the contract -- may be viewing the content in Google Docs (or in PDF or in print). This type of scenario has the same problem to solve as the classroom setting with printed books and digital books. |
I do understand and appreciate this. I just don't agree that the Google Docs page numbers meet the current definition for Page Break Locators. @alastc mentioned a possible tweak, and I am all for closing this gap. But it seems to me that this need would be better addressed by a new and slightly different SC, maybe one at AA instead of A. It is not exactly the same idea, and I would hate to see 2.4.13 put at risk. On the other hand, I am also open to and argument that this described need is already covered by SC 1.3.1. (Even though I am not comfortable with how overloaded 1.3.1 is already.) |
Point taken about EPUB. Regarding the idea of "EPUB style documents that are rendered by the browser" I'm saying that I would absolutely include Google Docs within the definition of your phrase, precisely because Google Docs does act like a reader when you share Google Doc documents with other people. |
As written, I agree that the SC does not currently cover Google Docs, because the page break indicator in Google Docs is visual only and indicated only via CSS classes, and not via standardized tags or attributes. I see that as an unfortunate limitation in the way it is written currently, but I do agree that the limitation exists in the SC right now.
Maybe, though that sounds like a recipe for neglecting the idea, since it would require starting from scratch on an idea that is already partially covered in this SC.
Yeah, throwing it into 1.3.1 would be one way to do it, but I agree that 1.3.1 is where a lot of vague concepts get thrown, and it would be nice to not add something else vaguely there. |
|
Ok, so it is a similar problem. There are three differences I can see though:
The way the SC is structured it is targetting that publication workflow where documents already have the locators (for the other user-agents), there is just no navigation mechanism when you use a browser, which impacts people with disabilities more.
I wouldn't, not that we use that as a definition, but EPUBs is quite a different thing. Google docs is an authoring interface which displays a 2D representation of a document. EPUB is a markup language which is intended to be linear (1D). The reason this SC is needed at all is because HTML/EPUB does not have a built-in representation of pages. It is intended to paginate differently based on the user-agents settings. Of course it is possible to import/export between formats, but this 1D / 2D aspect is key. When a format like HTML or EPUB does not have a 2D page representation then page-breaks are arbitrary markers for another format. When you zoom in the Google docs it does not affect pagination. When you zoom in an HTML page (displayed like an EPUB) it does. That's the difference, and why (IMHO) the scenario that triggered the current SC is more important. |
|
If the core concept of 2.4.13 is making document page navigation accessible where multiple formats -- including PDF and print -- are possible, then on a conceptual level, the problem could be solved a few different ways:
Or, to simplify, someone -- it doesn't matter if it is a content author or a UI author -- needs to either add a UI component or markup (or both) to navigate page breaks. If I understand the SC correctly as it is currently written, it's putting the burden on content authors and not on UI authors, is that correct? It's basically saying that in HTML format we are assuming that the content will not be presented within a UI that can have page navigation built in. That's true if the end product is just a web page, but false if the end product is a Google Doc (Google authors can add page navigation if they want to). Still, I think the distinction of which authors we are talking about may be a key difference between what you're saying and what I'm saying. If that's the distinguishing factor between our two positions, then it may indeed be appropriate to separate the idea of pagination into two SC, with one requirement targeted at simple content authors and another targeted at UI content authors. I just wouldn't want to see UI content authors get off the hook, because arguably requiring UI pagination will have a far greater positive impact on accessibility than putting all the burden on content authors, who -- if we are honest -- are unlikely to do it at all, because of the invisible nature of that kind of markup. We'll get a much bigger bang for our buck if we explicitly call out the need for pagination navigation within UI content. |
I do not agree with this characterization as the core concept of 2.4.13. In my view, the core concept is only about content where cross reference to a hard copy conventional print page is essential to use of the content. An analog is that hardcopy braille typically include both print and braille page numbers. The web example I gave is the Federal Register where the print page number features heavily (see the right sidebar for any long article).
I agree with the utility of such a requirement. But, as I understand it, that is not the purpose or driver for this SC. It is out of scope, and trying to shoehorn it into this SC puts 2.4.13 at risk. This is an important point for the WG to come to consensus on, and to provide as much clarity as we can. I think 2.4.13 works as-is, but people are going keep raising this on-line word processing question. I suggest that the best way to address this is to have a different district SC for the use case of online word processing. Reference to print page numbering of HTML is a perennial issue, but not one that is in scope for 2.4.13. |
Ok. I think both my examples -- university textbooks and contracts in PDF format (originally authored in Google Docs) -- meet this definition. In both cases the page numbers are essential. Or at least in both cases they MIGHT be essential. But as to whether the page numbers are actually essential or not, that depends in part on the author's intent, and in part on the way that people happen to use the document, which is out of the author's control. As a university instructor, I could say "read chapter 4" and not have any pagination problem, even if the document is the equivalent to 3000 pages long. Navigating by chapter is equivalent to the Heading navigation feature in Google Docs. So in a sense you could say that even if pagination is provided, and even if it is programmatically determinable and accessible, it's (sometimes) not important. On the flip side, you could say that even if an author does not intend for page numbers to be used, the people reading the document could decide to use page numbers anyway. The usefulness of pagination is unpredictable in this sense. We probably need to arrive at a position that recognizes the inherently essential paginated nature of Google Docs and MS Word online (essential because of the explicit representation of the printed page via the UI) -- whether the content in question will "require" pagination references or not -- AND of any content that with an explicit relationship to printed materials as determined by the author. Or to put it differently:
|
|
In the google docs example, is there a difference between page numbers when you go from the Gdoc to PDF? These are both paginated formats, whereas reading an HTML version has no expectation of having the same pagination. That is why reading the HTML versions is in the scope of this SC.
It is not intended to apply to online 'word processors' in general, and I don't believe it does apply as written. We went through various scenarios in the early stages of this SC (and the proposed "include page-break locators" SC), and it was too wide to include anything paginated. It would catch too many scenarios where it wasn't an accessibility issue and difficult to implement. |
In all the documents I've tested today, the page breaks are in exactly the same place in Google Docs and in PDF files created from those Google Docs. While I can't claim to have done exhaustive testing to see if this is true in all circumstances, in my experience working with Google Docs it has always been true.
I'm unclear as to the distinction you're making here. A Google Doc is an HTML version, and because it has clear pagination markers for sighted users which -- as far as I can tell -- always sync with printed or PDF versions of the same content, to me the Google Doc environment considers pagination essential to the experience. It's an inescapable property of the UI because the very model that Google docs assumes you want is pages that correspond to print documents. That's basically the definition of a word processor interface. Are you saying that you are only trying to solve the problem of when pagination markers are not visible? The pagination markers in Google Docs are visible, therefore the SC doesn't apply? Are you only talking about content that can be reflowed into (possibly) infinite varieties of page breaks in terms of the visual experience in the viewport? So this would refer to a single web page that either is a long "toilet paper roll" on the screen from start to finish, or else the visual pagination on the screen (if the UI splits the content into page-like chunks) does not correspond to the printed pagination? Is that the distinction you're making? If that's the distinction you're making, I'll first say that I agree that's a problem to solve. It's essentially like my college professor problem of having ebooks that paginate arbitrarily depending on font and screen size, and printed books in which the page breaks are 100% static. But... that distinction doesn't help with my other scenario of a contract written in Google docs and shared in PDF and/or print format. In both scenarios the idea of refrenceable page breaks is essential.
I think it could apply as written, if the definitions are altered a bit. Or it could be rewritten to ensure that we include any scenario in which pagination is an essential feature of the document and/or UI. The explicit purpose of HTML-based word processors is to create an environment which is the digital equivalent to the printed page. In every way, the print equivalence of a Google Doc is an essential feature of the HTML UI, so I think it would be inconsistent to exclude online Word processors.
In the case of Google Docs, the fix is conceptually simple: provide a navigation mechanism. It could be a drop down list of pages, or forward and back buttons with a "go to page X" feature, or a side panel with page thumbnails, or any combination of these or other ideas. And if they want to throw in something in the markup, like role="doc-pagebreak", they could, but I wouldn't say that's necessary from a functional accessibility standpoint. One possible way to rewrite the SC: For web content in which page breaks are essential, a mechanism is available to navigate to each page break. In the explanatory docs, we could say this can be accomplished either through:
|
|
I would add that I know that anything can be paginated, in principle, and I would not want this SC to literally cover everything. Any web page, any note-taking UI, and really anything with text or content can be printed into pages. But for most web pages and for most HTML content the pagination is completely arbitrary and 100% non-essential. Online word processors with a printed page equivalent are clear exceptions to the norm in HTML content, because these online word processors do assume that print page equivalence is essential. We could clarify the distinction in the explanatory text. |
|
My proposed rewording of the SC would also allow a document author -- outside of a word processing context -- to add a page navigation UI component to that page (any of the types of UI components I previously listed would be fine). Maybe the simplest way to do that would be to add a table of contents to the top, with links to the start of every page. Or if the goal of this SC really is to get people to use role="doc-pagebreak" we can say so in the explanatory text, and I might not push back against that too hard, though I still think that UI components would accomplish the overall goal equally well, or perhaps even better. |
Which means there is a lack of problem here, the page numbers (generally) match up. This is different to the case for EPUB style documents rendered in a browser.
Technically, yes. However, it is a combination of canvas and SVG elements to create a 2D representation of a document, not a re-flowable HTML page.
Indeed, that is the problem this SC is intended improve.
No, but it's a slightly different problem, and if we bring that into scope it makes it a much wider SC that is likely to catch non-problematic interfaces as well.
But in those scenarios the impact is different. For the google-docs to PDF, the page numbers stay the same (in general), for the EPUB stlye pages they vary hugely. We would also need more than one person's comment, we'd need to build up evidence of an issue for that scenario. That isn't possible in the WCAG 2.2 timeframe. I'd also note that even Word online has stopped provide page navigation (I'm sure it used to) in favour of headings/outline navigation. If there is a good UX reason for that change we would need pretty strong evidence of an accessibility issue with that.
It was intentional that the definitions didn't apply. |
It's not a lack of a problem. There is no way for a blind person to navigate by page in the HTML version, which is still the same root problem that a pageless document (or differently paged document) of the type you're talking about creates.
Doesn't the phrase "in which page breaks are essential" (in my proposed wording) limit the scope appropriately?
From a blind person's perspective, there is no way to navigate to pages in either scenario. They are different manifestations of the same problem. I will come back around to the point I made earlier that the wording as it is now is still backward from a normal accessibility perspective. Rather than saying we want page breaks to be accessible, we are currently saying that where programmatically determinable page break markup is present (in the vast majority of cases it won't be), page breaks must be accessible. To avoid having to comply with this SC, I could decide to remove page break markup, and then I'd be in compliance, but accessibility would actually be worse. Doesn't my proposed wording still solve the limited-scope problem you're trying to solve while also solving the word processor problem, without causing the scope to creep into irrelevant areas? By explicitly scoping it to "content in which page breaks are essential" in the SC, as I propose, I don't see how this runs any risk of applying where it shouldn't apply. It should apply to all cases in which page breaks are essential, because in all those cases, accessibility of page breaks is essential. |
|
My wording has the added benefit that it catches content in which page navigation is essential but not reflected in the markup. As the SC is currently worded, if a college professor posts a 37-page document that has a print equivalent and if the professor does not include page break markup, then the professor is in perfect compliance and yet no accessibility problem has been solved at all. I would think that this scenario would be quite common. A quick example: as a college professor, I can write an instructional manual, make it available on my personal website as a pageless HTML file and give the link to my students, and make a printed version available to my students. When discussing things in front of my class, I can say "go to page 20" and everyone with a printed version in front of them will be able to do that easily. Anyone viewing the file on my website will have to ask "what is the phrase that this page starts with?" and they'll have to search within the content. Assuming the college professor is not an accessibility expert or EPUB expert -- which, from a statistical perspective, is pretty much everybody -- the professor will never add page break markup and will never know that there is any sort of accessibility problem. My proposed wording catches this scenario by saying that the core concept of page breaks must be accessible. In contrast, the SC now limits the scope to the tiny fraction of people who have a clue about page break markup. We won't catch hardly anything with the SC as currently written. My proposed wording catches all cases in which page breaks are essential, and explicitly excludes all instances in which page breaks are not essential. |
We would need evidence that it is a problem. No-one can navigate by page so is that feature, in this scenario, really required for people with disabilities? If no-one can do it why is it an accessibility issue? We have that from the publishing group for the scenario they brought forward.
Essential has a defined meaning in WCAG: I think the existence of the heading navigation would mean it's not essential.
I understand the point, but that is the mechanism of scoping it to the intended target. |
|
Proposed response for the group to discuss: On the original question:
Generally not, they do not include "page break locators", i.e. something which is marking where page breaks are with the appropriate programmatic role. It is possible they could add such a thing, in which case they would need to provide a navigation mechanism.
Same as above for being in scope, only if it had "page break locators". If it did, the film strip would meet the intent if they were accessible and match the page break locators. On the question later in the thread of changing the SC to include (web based) word-processing applications:
If someone wishes to pursue that, they should raise a separate issue (as this one will be closed if the response is agreed), and collect evidence of the issue. It could be a candidate for a later version of WCAG. |
Fair point if the HTML document is pageless (even if the printed version of the document has pages), as in my example of the college professor posting an instruction manual in which there are no visual pages of any type, though the word processor scenario is very much a scenario in which sighted users have page numbers and blind users do not, unless there is a navigation mechanism, so the word processor example is definitely an accessibility shortcoming. Thinking about it further though, in your target scenario of a document with arbitrary paginated views that don't correspond to the print version, isn't it true that nobody has access to the print pages in the HTML version? So that would in fact be a scenario in which everybody is at the same disadvantage if they are using the HTML version, and it would not be pure accessibility problem. In light of that logic, the word processor scenario -- where sighted users have access to pages but blind users do not -- may in fact be the only type of scenario that we've discussed that is purely about accessibility. |
The scenario brought to us was students sitting in class, most with the paper textbook. Some, due to low or no vision have digital copies. The teacher says to turn to page X. I’m not going to continue with this discussion. I don’t know that word processor isn’t a problem, but we don’t have evidence that it is, and it is too late in the process to increase the scope of a 2.2 SC. The next steps are above. |
I hear your frustration with the discussion, but as it is, the SC would apply only if the digital copy has programmatically-determinable page markers, which in most cases it won't. That's still a scenario that the SC doesn't address, but which my proposed change to the wording does, while still solving your original intent. |
According to the EPUB group, for the larger educational publishers, they are there now. They are included because they use the same code-base for their EPUB and HTML (in a browser) versions. The EPUB user-agents use them, but the browser doesn't do anything with them so it lands on the author to add navigation. It might not include everything you'd like, but it is what we can tackle now. Please open a separate issue for a future requirement and I'll tag it WCAG.next |
|
Agreed response from the group: On the original question:
Generally not, they do not include "page break locators", i.e. something which is marking where page breaks are with the appropriate programmatic role. It is possible they could add such a thing, in which case they would need to provide a navigation mechanism.
Same as above for being in scope, only if it had "page break locators". If it did, the film strip would meet the intent if they were accessible and match the page break locators. On the question later in the thread of changing the SC to include (web based) word-processing applications:
If someone wishes to pursue that, they should raise a separate issue (as this one will be closed if the response is agreed), and collect evidence of the issue. It could be a candidate for a later version of WCAG. Also noting #2366 will be included shortly. |
Online applications such as Google docs and Microsoft Office Word (see office.com) have page breaks and the ability to add page numbers. I cannot find a mechanism to navigate to pages within Google docs nor online MS Word.
Similarly, while I do see a way to navigate to Google slides, I have these questions:
The text was updated successfully, but these errors were encountered: