WP rendering in non WP aware browsers

[avneeshsingh]

This concept would be attractive to different stake holders. I would like to put it forward from accessibility perspective.

I think that we are moving towards the world in which publications will be rendered by browsers natively, although we have not reached there yet.

The current approach still requires use of reading systems or a script embedded in the WP. The concerns are as follows:

• Looking at the experience in EPUB 3 world, EPUB 3 is mainly HTML content pages bundled with OPF. When the content is in HTML, it should work with browsers and many of these browsers already have good support for accessibility. But due to bundling we need to rely on n number of reading systems, and it is a massive task to ensure accessibility in such a huge list of reading systems. You can see the list of reading systems that we need to test on regular basis: http://www.epubtest.org/testsuite/accessibility/ ,and there are more that we need to start testing.
• The second approach of using scripts in publications or turning publication into its own reading system is scary from accessibility and usability perspective. It will be very very difficult to ensure accessibility in such a huge cluster of reading systems when each publication will carry its own reading system. And such scripts obviously raise security concerns.

I believe that we are quite close to having a publication that can be rendered by a browser. Two approaches that come to my mind are:

1. We have already touched upon some concepts in the direction of reading WP in non-WP aware browser for example placing TOC and PageList in entry page. I think we should leverage it to provide a WP that can be read in non-WP aware browser, and can be rendered in a much better way in WP aware user agent. One way to go is to develop a profile of WP that provides guidance for creating a WP for non-WP aware browser.

2. The other option is to develop some scripts that can be embedded in the publications, so that people use scripts developed by our WG instead of coming up with their own scripts that my not meet accessibility and usability requirements.

I am very much in favor of option 1. Because it provides a profile that can also be validated and is free from issues like security. Such a profile would provide great rendering in WP aware user agent, and would provide a basic interface in a non-WP aware browser. And because it is a profile, we do not need to make a major change in direction of the WP specifications.

I believe that such a profile will also be useful for reasons beyond accessibility, and our charter has provision of creating such a profile.

[BigBlueHat]

Great thoughts @avneeshsingh! I hope a profile isn't needed, however.

Non-WP aware browsers (i.e. all of them) should be usable now to experience a WP and without scripts. This could be made possible (as you noted) by simply requiring the ToC and/or PageList in the entry page. Requesting a publication address in a browser, then, would return something one could immediate use today to browse the publication.

Any scripts included would be focused on enhancing the existing in-browser reading experience and/or providing additional features such as offlining, searching, etc.

I'm new (sadly) to the accessibility space, but would this sort of change make WP's more accessible sooner?

[nruffilo]

Is it unreasonable to think of a server-side preprocessor or service that would be able to do this? I'm not against having a fully linked TOC or something else that would let you navigate a document that was not WP aware - but what if basic nav and other features had to be added by a service provider - similar to how there are access controls provided by the web-server via apache or other web services. I'm just thinking of ways that would make creating a WP as easy as possible. Plugins and server-side solutions will certainly spring up. The hope is you get at least one free/open source solution that allows the basics...

…

-Nick

On Thu, Aug 2, 2018 at 2:42 PM, BigBlueHat ***@***.***> wrote: Great thoughts @avneeshsingh <https://github.com/avneeshsingh>! I hope a profile isn't needed, however. Non-WP aware browsers (i.e. all of them) should be usable *now* to experience a WP and *without* scripts. This could be made possible (as you noted) by simply requiring the ToC and/or PageList in the entry page. Requesting a publication address in a browser, then, would return something one could immediate use today to browse the publication. Any scripts included would be focused on *enhancing* the existing in-browser reading experience and/or providing additional features such as offlining, searching, etc. I'm new (sadly) to the accessibility space, but would this sort of change make WP's more accessible sooner? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#271 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABM74ZJOnXBETlb0C4l2rTtU0GIrVGUjks5uM0gugaJpZM4VXgju> .

-- - Nick Ruffilo @NickRuffilo Aer.io an *INGRAM* company

[TzviyaSiegman]

Thank you @avneeshsingh. I would love to see us take a progressive approach. How can a non-WP aware browser parse this effectively and accessibly? What needs to be added to make a browser WP-aware? How can we ensure that whatever needs to be added remains accessible?

[dauwhe]

The second approach of using scripts in publications or turning publication into its own reading system is scary from accessibility and usability perspective. It will be very very difficult to ensure accessibility in such a huge cluster of reading systems when each publication will carry its own reading system. And such scripts obviously raise security concerns.

Do you see problems beyond those already faced by the web? Essentially every web site uses scripting. Do we need to extend WAI-ARIA to deal with new situations created by web publications?

[avneeshsingh]

@dauwhe
The difference is in the usage of the websites VS publications. Website surfing is mainly for getting some information while publication is used for extensive reading.
For people with disabilities locating information on websites is an adventure. Even if a webpage is accessible, we need to use different techniques to locate the required information, because the information is structured in different way on different web pages. I am using screen readers since 2004, but still I sometimes need to use brain to quickly traverse a new webpage and find relevant information. And this becomes even a bigger issue for people with cognitive disabilities.

We can live with such an adventure on websites because we surf internet for getting some information. But if we have to face the same adventure for reading huge volume of text in textbooks, it would become an inefficient and exhausting experience. Further to it, the publications are also used by children in schools, who may not be as fluent with assistive technologies.
Predictability of the user interface is essential when people with disabilities have to absorb huge volume of text from publications, so that the concentration remains on learning instead of finding out the way to operate the publications.
Our experience in DAISY world informs us that people with disabilities keep on using the same model of DAISY book players for years and years, because of additional efforts required for learning new user interfaces.

[avneeshsingh]

@BigBlueHat
It is possible to create a WP for non-WP aware browser by placing TOC and Page list in landing page. The profile is more of a guideline for creating such a publication in a proper way. It may not be normative specs, more of a set of guidelines. The purpose of putting these thought forward are:

1. To ensure that nothing in WP/PWP specifications blocks creating a WP for non-WP aware browsers, as the specifications evolve.
2. To develop a profile or set of guidelines for creating such a WP.

[avneeshsingh]

@TzviyaSiegman
Indeed the plan mentioned by you is the ultimate objective.
The approach proposed by me is the intermediate solution to facilitate people with disabilities till the ultimate objective is met.

[BigBlueHat]

To ensure that nothing in WP/PWP specifications blocks creating a WP for non-WP aware browsers, as the specifications evolve.

@avneeshsingh thank you for this conversation. I guess I'd like us to go a bit further and not make non-WP aware browser-friendly publications an afterthought, but rather make them the core of what we're building here. This is a Web specification after all. 😃

If we have to create a profile of the specification so that a WP may be created for a non-WP browser (i.e. all of them right now) to be able to render/read a WP, then we've failed.

[BigBlueHat]

@avneeshsingh here's a demo of a very slightly modified EPUB of Moby-Dick which is non-WP aware browser friendly: https://wileylabs.github.io/no-can-transclude/moby-dick-from-epub-samples/

It is not (by our current definition) a WP, but it is (by any other definition) a "web publication."

The changes I made were:

• rename nav.xhtml to index.xhtml
• add <script src="../dialog-reader.js"></script> to provide the "reading system"

The "reading system" only works in Chrome atm, but provides many of the experiences we've all been expecting for multi-document publications. Additionally, if you load the publication in Firefox, it still "just works"--though the experience is less "bookish" and more "web page-y."

Point being, that we can (if we want) spec something that builds up from where we are, can be progressively enhanced, and still be informative to non-Web-based reading systems (ala EPUB readers).

I'd be curious to know what this would need to be more accessible or to meet any other requirements you would have.

Cheers!

[avneeshsingh]

From reading experience point of view, it provides accessible reading experience on Chrome.
The TOC, next and previous links also work fine. It would be good to have another link on each chapter which takes you back to entry page (that has TOC and pagelist). This will enable user to go to TOC anytime they need.

It would be great if this could also be achieved without use of script, because when we encourage people to create a reading system inside a publication then we get into the problems that I mentioned in my first post.

[GeorgeKerscher]

Agree with Avneesh. The TOC as the entry page is good, but the only way to get back to the TOC is to use the browser's bookmark feature. Also, page list would be good and essential in education.

[BigBlueHat]

The TOC, next and previous links also work fine. It would be good to have another link on each chapter which takes you back to entry page (that has TOC and pagelist). This will enable user to go to TOC anytime they need.

The page area outside of the <dialog> (i.e. the "backdrop") is click-able and removes the overlay/dialog showing the Table of Contents, but I'll add a specific link to make that more accessible. Thanks!

It would be great if this could also be achieved without use of script, because when we encourage people to create a reading system inside a publication then we get into the problems that I mentioned in my first post.

Agreed completely! The script is only there for the demo, but the "end game" would be browser support for this HTML binding document.

[BigBlueHat]

@avneeshsingh @GeorgeKerscher I've added a close link to the dialog reader with a title attribute of "Table of Contents": https://wileylabs.github.io/no-can-transclude/moby-dick-from-epub-samples/

Please let me know if that works for you, or if it needs more detail. Thanks!

My hope is to provide the shortest runway for an existing EPUB to be accessible (in all its meanings) on the Web via the fewest possible modifications. Easy peasy, right? 😃

[avneeshsingh]

Now 3 links are reported on a chapter:
Next
Close
Previous

When I press "clos" link, Chrome returns to the TOC. So, the functionality is appropriate.
A minor issue is that link says "Close" instead of "Table of Contents" or "TOC". But it is more of labeling thing and not a functionality issue.