Open chasenlehara opened 3 years ago
@mikemitchel and I talked about this—it should be sufficient for us to just announce page breaks to screen readers and not add nav to “pages.”
It looks like my initial fix did not work as expected.
The sr-only
class didn’t seem to take effect (maybe bootstrap-styles
needs to be added somewhere?).
There are other page breaks created by CKEditor that aren’t fixed; the DOM looks like this:
<div style="page-break-after:always"><span style="display:none"> </span></div>
As a screen reader user, I want page breaks to be available in text, so that I can perceive them.
Currently, page breaks in the preview document are only perceivable through visual styles. They should also be available in the text a screen reader announces to users.
At a minimum, I think we should add some sort of aria element to indicate page breaks to screen readers.
The draft WCAG 2.2 spec adds Success Criterion 2.4.13 Page Break Navigation and includes these docs on understanding the criterion and techniques for meeting the criterion.
I think the minimum I mentioned above is sufficient for compliance, although we may consider adding the recommended navigation to the document. My only hesitation is that the navigation would not necessarily match what’s in the generated PDF document—I think we would need to use more advanced techniques to determine the pages that will be in the generated PDF.