What you mean with Epub Accessibility?

31 posts / 0 new
Last post

I am trying to understand this topic. Epub is not WCAG 2.0 compliant, so i have to think that you have another definition about "accessibility"? And what user agent can read accessibility things? I have done some try with different screen readers and different user agent, but no one work as expected.
So, your "accessibility" is something different?

thank you
Livio

Which version of epub are you referring to?

EPUB 2 had limited accessibility capabalities, but EPUB 3 includes support for @role all the aria-* attributes through its use of xhtml5. As epub is web content, I'm not sure I follow what you mean by the format not being wcag compliant, though? Are you referring to publishers simply not creating content that is compliant? That's a known problem we're trying to correct, but I'm not sure how it differs from anyone publishing incompatible content on the web.

And yes, you're going to find wildly varying degrees of support in reading systems. I can't argue with you there. Apple is widely cited as providing an accessible reading interface in iBooks, and Readium is striving to be a feature complete reading system. What combination of reading system/browser/AT you use to read is going to affect your experience.

No, the problem is that HTML5 is for now not accessible, and adding ARIA make also more confused the field. But because is not a specification or a standard, no one know what happens in near future. For now, talking on simple things, the headers structure of HTML 5 dont work with screen readers, or work badly. This happens in any device, Ibooks and Readium included. This derives from the fact that HTML 5 is still a work in progress, so i don't understand well what you mean with "epub 3 accessibility", is impossible have a standard based accessibility with a markup that is under developement, no?
Or we say "epub accessibility" thinking maybe in a future this can happens, if and when html5+aria is a stable platform?
Sorry for my bad english, i hope to be understandable.

For be more clear, i am worried about the fact that in 2012 also just the use of alt attribute is in discussion...
http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-206

and here you can see all the Change Proposals in discussion:

http://www.w3.org/html/wg/wiki/ChangeProposals

So, i think that for longtime we can't talk about a standard based "accessible epub", we can hope maybe.

Right, okay. I don't think that I'd go that far and say that html5 is not accessible. Certainly parts of it are under development, but that WCAG hasn't been updated to html5 doesn't mean that the principles don't apply and that the best practices aren't relevant to the new version. The baseline remains.

But yes, accessibility is something that will continue to evolve with support for html5. We've been trying to give guidance on known issues, such as not relying on h1 and the outlining algorithm for strucure, not relying on hgroup, trying to work around the problem of no out-of-band mechanism for descriptions, etc.

W3C is pushing HTML5 to Rec for 2014, too, so while support in browsers, RSes and ATs still needs to develop, a lot of the ambiguity about what the specification will support is disappearing now.

You're kind of presenting an impossible problem, though. Either EPUB stays in the past with XHTML 1.1 and doesn't get the benefits that will come with native audio/video, mathml, aria support, etc. or, it moves forward and has to live with some instability.

The decision was made to move forward with the web, so that does leave us in a position where we have to talk about an ideal future. I certainly appreciate this fact, as there's a line I find myself always treading between what you can say is possible versus what is possible right now.

To chime in a bit further: HTML5 has (as I'm sure you're aware) much improved semantic markup (elements like section, article, figure, etc.). XHTML 1.1 was semantically poor and so not good at all as a fundamental markup for  accessible content. EPUB 2 supported DAISY DTBook as an alternative basic content type but it was poorly adopted. The decision to "mainstream" accessibility and build on HTML5 and EPUB 3, and move away from specialized markup, was DAISY's. To argue that because HTML5 isn't fully final that it is less accessible than XHTML 1.1 seems a bit of a stretch to me. In fact I would veture to guess that any areas of HTML5 that have accessibility issues still to iron out are in areas of functionality that arent' even in XHTML 1.1. 

As far as accessible Reading Systems, that's about the implementations more than the specs for content. The IDPF-sponsored open source project Readium (http://readium.org) has already some accessibility feature support including screen-reader integration and Benetech has launched a beta of a new cloud reader for their accessibility-focused Bookshare service. Readium is still a  work in progress but Benetech and other supporters are working hard to make it a showcase for a comprehensive accessible EPUB 3 implementation.. IDPF is also working on a new conformance test suite project that will help "grade" reading systems including on accessibility.

Thank you Matt and Bill, so we can agree that for now is bit strange talk about "epub 3 accessibility" as a concrete and actual fact? Is something that i and we hope come fast, but for now is not true that a epub 3 IS accessibile. WCAG are important, now they are also a ISO standard. Is very important have a conformance test suite, this is a very good idea. And ok, have also some authoring programs can help :).
About the principles, nothing to say, they are perfect.

No, I wouldn't agree with that statement that EPUB is not accessible, or accessible now. As I said, HTML5 accessibility is still under development in reading systems, but that's not the same as saying that it is not accessible, as Bill points out.

By your measure, HTML is not accessible since browsers aren't perfectly accessible, either. The same baseline exists between XHTML 1.1 and XHTML5. It's not like WCAG or WAI-ARIA don't apply because the grammar underwent a revision. To my knowledge, WAI is already working on updating the guidelines for HTML5, but I wouldn't expect them to be able to release them until HTML5 is official. That doesn't mean that the content is not accessible because the guidelines aren't done. ATs are already supporting HTML5 features, after all. Accessibility API mappings of roles, states and properties haven't changed, even if some still need work.

EPUB 3 provides a more standardized and richer approach to accessibility than any other format I'm aware of in the ebook market. It has rich navigation. You can create text/audio synchronization. It supports text-to-speech enhancements. It offers native audio/video with timed tracks (right now through polyfills, but eventually through the browser itself). I'd take it to EPUB 2, Mobi, PDF, HTML4 or any other format for ebooks.

By all measures EPUB3/HTML5 is a significant improvement, and accessibility is very real in it.

Ok Matt, i don't discuss about the fact the epub 3 offer or not a more standardized or richer approach etc etc. For sure, in this moment PDF offer a more richer support than epub 3 to accessibility, and most important is standard, so all can know what is or not "accessible" for definition.
On HTML5/epub 3, this is not true... no one can know what is "accessibility" for epub 3, because don't exist a test case, a definition, something that help on understand. Is all based on HTML 5, and HTML 5 is for nothing finished or stable.
For example, is in discussion a element that for sure is accessibility related, Transcript. But is in discussion, is not available. Today, not one year ago. Is still in discussion, and maybe tomorrow this element became a part of specifications.
Also HTML5+ARIA is in discussion, is not available. I can use, but at my risk, tomorrow maybe specifications change.
And no, ATs are not supporting HTML 5 features, they start to support. But we are years far from complete support.
The HTML to Platform Accessibility APIs Implementation Guide is still in Editor Draft state, and in his page you can read big and in red "This document is subject to change without notice".
http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html

But i am not discussing this, i'd like to know just if possible have a definition about "epub 3 accessibility"? What mean this? Where i can find some info about? Someone have tested?
If yes, i can read something about?
Thank you

Have you seen this document from the W3C: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

There are only ten issues remaining to be addressed to get to REC in two years, so it's not as unstable as you're suggesting. And every specification must say it's subject to change until it reaches recommendation status.

I think we both agree that WCAG outlines best practices, but you're drawing an artificial line that it doesn't apply to HTML5 when HTML5 has not radically changed web content. Unsupported elements are treated like divs and unsupported features won't work until implemented, but that's a case for improved reading system/browser support not a case that the format itself is inaccessible. Every day HTML5 implementations become more accessible than HTML4 by improving on the base, right?

WAI-ARIA you claim is unstable but is a candidate recommendation and I believe very soon to be a final recommendation: http://www.w3.org/TR/wai-aria/

The attributes are part of the HTML5 specification instead of an add-on as in the past, and I'm not aware of any discussions of their being pulled out: http://dev.w3.org/html5/spec/single-page.html#wai-aria

I'm not sure how many users would accept a definition of accessibility that only has status in a standards process as its basis. I simply can't agree with that conclusion that PDF is more accessible because of ISO blessing, but if you want absolute stability over accessibility then that's your right.

You seem to already be aware what the resources are for web accessibility. Unfortunately, if your position is that they don't count then I don't know what else I can say to change your opinion. We'll have to respectfully agree to disagree.

Yes, i saw this document, i am only happy if in two years we have a stable document also if i am a bit old and i have some doubts. But ok, maybe i am asking something impossible. How i can stay informed about the conformance test suite project? Already exist something? And thank you for your time, i really appreciate this, i hope i can help in some manners.

Fair enough, and always welcome feedback and different opinions.

For the test suite project, see the bottom of the announcement page: http://idpf.org/news/epub-reading-system-conformance-test-suite-project-kicks-off

Information on joining the google mailing list is there.

For general accessibility information on EPUB, and apologizing for self-promotion here, but I have been involved in two projects to help provide guidance on epub's accessibility features:

I know you may not agree with the stability, but we are trying to promote web best practices and epub-specific enhancements in content production.

There are also additional projects in the works from the DAISY Consortium, such as reading system accessibility evaluations and improvements to accessibility checking in epubcheck.

I know this works Matt, so no self-promotion :).

Just as example of what i mean, i take your Accessible EPUB 3 book from O'Reilly. I can test the PDF, because for this type of document we have tools for test and references. The PDF is not accessibile (can be nice give to readers one...) but, and this is the point, i can't say nothing about Epub file accessibility because no tools, no references, etc etc.

You can test that a PDF has been tagged completely and properly by machine tools? I don't believe that at all. Conformance to a format definition alone does not make a document accessible.

You can run epubcheck and get exactly the same kind of results (and in many cases better) for EPUBs that you claim you can get from PDF checker tools.

Please stop making the erroneous claims that there are no tools or references for checking EPUBs. If that's your only agenda here, this will be my last reply.

No no sorry, this is for nothing true. I can test accessibility of a PDF with a complete set of automatic test taking WCAG 2 as reference, with a complete report. With epubcheck i can only verify markup, not accessibility. I think here is not me that do erroneus claims.
In 5 years, when i see something like this also about epub 3, ok we can talk about epub accessibility. For now is just a abstract idea.

http://www.w3.org/WAI/GL/WCAG20-TECHS/pdf.html

http://www.adobe.com/products/acrobat/pdf-accessibility-wcag-508-complia...

"EpubCheck is a tool to validate IDPF EPUB files, version 2.0 and later. It can detect many types of errors in EPUB. OCF container structure, OPF and OPS mark-up, and internal reference consistency are checked." Is all, epubcheck don't do test on accessibility.

Dear Livio, you are correct that more automated accessibility checking tools are needed for EPUB. DAISY has plans to work on this during the coming year. But it is not correct to imply that somehow PDF is more accessible than EPUB just because there are tools that automatically report that 99.9% of PDF files are inaccessible whereas there are not yet tools that report that most EPUB files are well-accessible (the point being that reflowable content in reading order is inherently more accessible than pre-typeset PDF). After all I don't  believe that there's a large array of widely available accessibility checking tools for DAISY DTBook format, yet it would be perverse to argue that DAISY DTBook, designed specially for accessibility, is inaccessible. And EPUB 3 is a superset of DAISY DTBook which is it on track to supersede as the preferred format for accessible publications and documents.

Thanks, Bill, I think that point was lost in my earlier post. I was trying to indicate that PDF checking tools can only report what they can report (even for PDF/UA), which is often little more than very weak structural tests based on tagged regions. A PDF report can tell you everything has a tag, but it can't tell you that the tags have been applied properly (paragraphs aren't headings and figures have been applied properly), or what you should have structued better. It can tell you there is a reading order (more a tab order), but not that it is the actual logical reading order. The list goes on. None of these tests are better or worse than what epubcheck structural tests can do, but at least people have better understanding of how to prepare web content to be accessible than how to create content for PDF generation, since there's no one input method to PDF,

Automation of accessibility tests can be helpful, but it hardly makes a publication accessible by most measures of accessibility, even if one passes. Human quality assurance is always necessary, whether a tool helps that process directly, indirectly, or not at all. I have no issue with PDF potentially becoming more accessible, and it's a good thing, but what are we even comparing here? This seems to be a case in saying people who have to endure inaccessible PDFs are wrong about how inaccessible they are because there are criteria that can be tested.

This framing of web accessibility as only what Livio chooses to recognize is what is making this thread pointless to me. Arguing that WCAG and WAI-ARIA don't apply to web content until some ephemeral future date is just a denial of the reality of how the web works. Claiming that tools that work on web content don't work on html5 content is beyond me, too. I can open an epub document and use Juicy Studio to run various tests for WCAG compliance, for example, but apprently the results it gives me aren't real because it's an html5 page. Who knew?

But I didn't mean to get sucked back into this. I think this is just becoming an exercise in trolling.

Matt, i think you are a bit confused. For me accessibility is a very serious thing, and i see is impossible for you talk on this without jump around without providing answers or give insults to others.
What i can see in this discussion, is that for now epub 3 accessibility is a project, and maybe in two years we have something stable and usable. If you have time, do a look at Acrobat XI accessibility report, so you can see on what we are talking, i suspect you don't know.

Bill, no, is not a fight between PDF or epub, i am not interested on this. Also MS Office have a Accessibility Checker, people have to be helped in some manners. So, we can wait when tools come also for epub, not a problem, i was wanting just be sure about this.

http://office.microsoft.com/en-us/word-help/rules-used-by-the-accessibil...

I was scheduled to present at a workshop on ePub at ISTe 2011 along with a group of fellow Apple Distinguished Educators, but since I was not able to go to the conference this year, I decided to create this ebook to be distributed to the participants instead. The ebook is in ePub format and can only be read on the iPad or another IOS device, or by using a desktop reader application such as Adobe Digital Editions or Calibre. It is an enhanced ebook that includes a few embedded video tutorials. This means it is on the large size, so please be patient with the download time on your device.

think that point was lost in my earlier post. I was trying to indicate that PDF checking tools can only report what they can report (even for PDF/UA), which is often little more than very weak structural tests based on tagged regions. A PDF report can tell you everything has a tag, but it can't tell you that the tags have been applied properly (paragraphs aren't headings and figures have been applied properly), or what you should have structued better. It can tell you there is a reading order (more a tab order), but not that it is the actual logical reading order. The list goes on. None of these tests are better or worse than what epubcheck structural tests can do, but at least people have better understanding of how to prepare web content to be accessible than how to create content for PDF generation, since there's no one input method to PDF,

Automation of accessibility tests can be helpful, but it hardly makes a publication accessible by most measures of accessibility, even if one passes. Human quality assurance is always necessary, whether a tool helps that process directly, indirectly, or not at all. I have no issue with PDF potentially becoming more accessible, and it's a good thing, but what are we even comparing here? This seems to be a case in saying people who have to endure inaccessible PDFs are wrong about how inaccessible they are because there are criteria that can be tested.

This framing of web accessibility as only what Livio chooses to recognize is what is making this thread pointless to me. Arguing that WCAG and WAI-ARIA don't apply to web content until some ephemeral future date is just a denial of the reality of how the web works. Claiming that tools that work on web content don't work on html5 content is beyond me, too. I can open an epub document and use Juicy Studio to run various tests for WCAG compliance, for example, but apprently the results it gives me aren't real because it's an html5 page. Who knew?

But I didn't mean to get sucked back into this. I think this is just becoming an exercise in trolling.

Still not clear on what accessibility means in the context of Reading Systems after reading the arguments in this thread.

EPUB 3, the spec, by being based almost exclusively on XML is implicitly as accessible as can be. XML is the de-facto standard for Web technologies and this will become more and more apparent as time goes by. As far as actual accessibility (e.g. assistive technologies for the blind), I think the onus is on the Reading Systems developers/owners. Matt, I'll check out that web page and post further comments.

Matt, how relevant do you think that UAAG thing is to actually building an accessible eReader? It's like one of those CMMI things. It wastes more time than the value it purportedly provides. It's process heavy (if anyone was mad enough to actually get it all in) and bound to send anyone who actually tries to read it in its entirety to sleep.

I'm more optimistic about getting my hands on your book, Accessible EPUB 3, which I believe will be more easy to absorb, straight to the point and immediately useful to me.

Sure, I wasn't suggesting you'd have to hit AAA status, but it is a good objective reference to the qualities any html user agent should have. Accessibility naturally isn't ever easy to pin down, as users' needs can be very individualized.

And no specification is an enjoyable read, but it's a little more practical than a lot of the project/process management mumbo jumbo.

The DAISY Consortium has also been working on an accessibility test suite for reading systems. It's not intended to be as comprehensive as uaag, but more of a benchmark to what users of assistive technologies need. It's available from epubtest.org.

And the accessibility piece we did with O'Reilly focuses more on the content creation side of the equation, as it was done as part of the best practices book (much of which is available free from epubzone.org). I did attempt to relate why content structuring affects the usability in reading systems, but it doesn't specifically lay out what makes a reading system usable.

I will surely get your book Matt. I already have in my possession the one you wrote with Gyling.

I quite enjoy reading the EPUB 3 specification actually. All that XML is a real turn on for me (in an intellectual sense of course) as I have quite an impressive depth of experience working with XML. It's riveting really.

If you have the best practices book then you don't need the accessibility piece. It and "what is epub 3" were prelude chapters to the book but packaged as their own entities.

In the case of the accessibility book, we ended up splitting it out across various chapters of the best practices book (multimedia, media overlays, text to speech and accessibility, specifically) and elaborated on parts that aren't exclusively about accessibility (e.g., media overlay production), so you'll have already read it in more detail. Only the introductory sections explaining the lack of accessible content are unique to the standalone version.

Thanks for the explanation of how you addressed accessibility in the book. I haven't actually read those chapters yet.

Secondary menu