Simultaneous reading, A11Y, and alt="" (re: bitmaps as spine items)

[Edward O'Connor]

Hi,

Here's an additional argument against allowing bitmaps as spine items
and relying on multiple renditions for a11y, that I didn't have a chance
to raise before the call ended:

Two friends are reading a book together in iBooks on an iPad. One of
them is visually impaired, so they have VoiceOver turned on.

In a standard EPUB, where the spine items are all XHTML or SVG
documents, this works great—the sighted friend sees the rich visual
content of the book, and VoiceOver reads the alt="" text of the
various images so her friend isn't left out.

Now suppose the book instead had two renditions, one with bitmaps as
spine items, and the other with textual equivalents in XHTML spine
items. How are these friends expected to read the book together?


Ted

[Matt Garrish]

The issue we're having seems to circle back to whether you can beat people
into accessibility conformance through standards and restrictions, or
whether you can only hope to guide those who care about a broader readership
in the direction of creating accessible content. If the issue is ensuring
that all epubs are fully accessible in all cases, epub now doesn't even meet
that bar. Formats are never the solution alone, as George pointed out on the
call, but accessibility is greatly influenced by what they offer, and don't
(and the tools available to create them accessibly). I have no doubts I can
make DAISY content that is completely inaccessible to the world, but I also
know that what I make inaccessibly I could have made accessibly.

I find it disappointing to take a step back and accommodate inaccessible
content epub hasn't allowed before, but at the same time I'm not oblivious
to the fact that a decision for allowing images in the spine likely changes
nothing in the real world except for the required presence of an xhtml
wrapper.

But I do find it discomforting that we are discussing support for AHL and
rendition mapping when that work is not done or implemented. There seems to
be an implicit requirement that all reading systems will have to implement
rendition mapping in the future in order to persist the accessible nature of
epubs, but even if anticipated and expected that this technology will be
delivered we're still counting the chickens, so to speak. I'd rather see
this discussion occur after AHL is finalized so we know exactly what is on
the table.

After so much work to promote epub as an accessible format, it would be
disappointing to introduce this change now with no option for accessibility
but to not do what we'd be allowing.

I'm also wondering whether the access mode property defined in the
accessibility metadata submission[1] to schema.org would be useful here
(adapted from Access for All). As the name suggests, it identifies whether
the primary access mode of the content is aural, textual, visual, color
dependent, etc., regardless of the format used, which was the concern raised
on the call about knowing what a rendition contains. Although designed for
web discovery of accessible resources in its schema.org form, I can't see
why it couldn't be used in the package metadata with a prefix (except the
submission was only just made this week, so getting these properties
formally adopted by schema.org is in the early stages).

Hm, I thought I had a more specific point to add, but seems I got off
rambling as usual...

[1] http://www.w3.org/wiki/WebSchemas/Accessibility

Matt

--
You received this message because you are subscribed to the Google Groups
"EPUB Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to epub-working-gr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[MURATA Makoto]

I am sorry for not attending the 

teleconf.  

I think that AHL is a referring here.

But I think that text free HTML wrappers

or fallbacks make things less accessible.

When publishers have scanned images

only, EPUB can do nothing.

Regards,

Makoto

2013年4月19日金曜日 Matt Garrish matt.g...@bell.net:

--

Praying for the victims of the Japan Tohoku earthquake

Makoto

[Ishii, Koji a | Koji | BLD]

Probably because I wasn't aware of previous discussions on this topic, it surprised me a bit that this topic has so much to do with a11y.

I support Ted's scenario, but it looks to me that it's more general issues in AHL than just a11y or image spines. If I'm reading a same book with a friend in English and Japanese, I'd like to sync where we're reading with him. If I read a book on iPhone while commuting, and then on iPad when back to home, I'd like to continue reading even if rendition was switched to different one. I support Ted in that AHL should have synchronization mechanism between renditions, but that looks like a separate topic from a11y and image spine to me.

> I find it disappointing to take a step back and accommodate inaccessible content epub
> hasn't allowed before, but at the same time I'm not oblivious to the fact that a
> decision for allowing images in the spine likely changes nothing in the real world except
> for the required presence of an xhtml wrapper.

In real world--maybe only in Japan or only around me, I don't know, but--I'm seeing opposite, unexpected side effects from what EPUB WG wanted by prohibiting image chapter. When EPUB3 started spreading in Japan, some authors put description text as <p style="display:none">. I don't know why they went that way. I don't know why they didn't use longdesc, but they did that. Then, it turned out to break layouts in some RS, so authors decided not to include any text in spines to make sure RS recognize it as image only.

I see this as an unexpected side effect. By prohibiting image spines, we're making XHTML inaccessible. I do support the idea of encouraging authors to make every publication accessible, and I do support EPUB WG's efforts to make it happen. But as long as there are some people who wants to create inaccessible publications, prohibiting image spines can only cause unexpected side effects like this.

I would like, by allowing image spines, XHML spines stay accessible, and RS can identify which publication is accessible and which is not. If author wants his publication accessible, he can simply choose XHTML spines; he could use multiple renditions, but its use is not required to build accessible publications. If author doesn't want, I want him simply to use image spines and not to pollute inaccessibility to XHTML.

In short, I think image spines will give us better a11y, and that's why I was surprised by the today's discussion.

/koji

-----Original Message-----
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Matt Garrish
Sent: Friday, April 19, 2013 12:36 PM
To: epub-work...@googlegroups.com
Subject: Re: Simultaneous reading, A11Y, and alt="" (re: bitmaps as spine items)

The issue we're having seems to circle back to whether you can beat people into accessibility conformance through standards and restrictions, or whether you can only hope to guide those who care about a broader readership in the direction of creating accessible content. If the issue is ensuring that all epubs are fully accessible in all cases, epub now doesn't even meet that bar. Formats are never the solution alone, as George pointed out on the call, but accessibility is greatly influenced by what they offer, and don't (and the tools available to create them accessibly). I have no doubts I can make DAISY content that is completely inaccessible to the world, but I also know that what I make inaccessibly I could have made accessibly.

I find it disappointing to take a step back and accommodate inaccessible content epub hasn't allowed before, but at the same time I'm not oblivious to the fact that a decision for allowing images in the spine likely changes nothing in the real world except for the required presence of an xhtml wrapper.

But I do find it discomforting that we are discussing support for AHL and rendition mapping when that work is not done or implemented. There seems to be an implicit requirement that all reading systems will have to implement rendition mapping in the future in order to persist the accessible nature of epubs, but even if anticipated and expected that this technology will be delivered we're still counting the chickens, so to speak. I'd rather see this discussion occur after AHL is finalized so we know exactly what is on the table.

After so much work to promote epub as an accessible format, it would be disappointing to introduce this change now with no option for accessibility but to not do what we'd be allowing.

I'm also wondering whether the access mode property defined in the accessibility metadata submission[1] to schema.org would be useful here (adapted from Access for All). As the name suggests, it identifies whether the primary access mode of the content is aural, textual, visual, color dependent, etc., regardless of the format used, which was the concern raised on the call about knowing what a rendition contains. Although designed for web discovery of accessible resources in its schema.org form, I can't see why it couldn't be used in the package metadata with a prefix (except the submission was only just made this week, so getting these properties formally adopted by schema.org is in the early stages).

Hm, I thought I had a more specific point to add, but seems I got off rambling as usual...

[1] http://www.w3.org/wiki/WebSchemas/Accessibility

Matt



-----Original Message-----
From: Edward O'Connor
Sent: Thursday, April 18, 2013 7:16 PM
To: epub-work...@googlegroups.com
Subject: Simultaneous reading, A11Y, and alt="" (re: bitmaps as spine items)

Hi,

Here's an additional argument against allowing bitmaps as spine items and relying on multiple renditions for a11y, that I didn't have a chance to raise before the call ended:

Two friends are reading a book together in iBooks on an iPad. One of
them is visually impaired, so they have VoiceOver turned on.

In a standard EPUB, where the spine items are all XHTML or SVG

documents, this works great-the sighted friend sees the rich visual

[MURATA Makoto]

Oops. I meant "red herring".

2013/4/19 MURATA Makoto <eb2m...@asahi-net.or.jp>:

[Matt Garrish]

But isn't that the apology for every image-based PDF ever created?

As I said originally, though, I'm not necessarily a proponent of using the
specification as a hammer of conformance. What disappoints me is the optics,
as we already have a means of providing accessibility for images in the
spine, whether you use it or not. What this proposal does is take us back to
the missing situation that fallbacks and wrappers address -- images in the
spine that can't be annotated -- without also going forward.

Of course, we'll continue to push people in the direction of accessible
production, but it's a hard sell that image-based epubs are a good thing.
Coupling the decision to some means of identifying the nature of the content
or some mechanism to provide an alternative may be a red herring, but it
also softens the blow of validating visual-only epubs.

Matt

[Matt Garrish]

Just a quick note that longdesc is not in epub 3. It was removed from HTML5
and only recently has been revived as an extension specification. We have an
open issue for a description mechanism that I expect will inevitably look at
adopting that extension spec. You can use the aria described-by attribute to
point to hidden content, though.

And I'm equally torn on this, so don't read my dismay as outright opposition
to changing. You make a good point about improving visual rendering. I just
would like to see some of the other pieces, like rendition selection and/or
access mode discovery, accompanying any change.

Matt

[Daniel Weck]

On Friday, April 19, 2013, Ishii, Koji a | Koji | BLD wrote:

I support Ted in that AHL should have synchronization mechanism between renditions, but that looks like a separate topic from a11y and image spine to me.

I think that Ted was talking about authoring a11y into the "normal" reading flow (i.e. not as a separate modality), so that users relying on screen readers can experience the same content as sighted users, without having to switch context.

/daniel

[MURATA Makoto]

I think that AHL cannot be used as a pretext for not mandating
HTML fallbacks. If it should be made optional, the reason
shouldn't be future works of AHL.

Regards,
Makoto

2013/4/19 Matt Garrish <matt.g...@bell.net>:

[Matt Garrish]

I believe we agree on that point. While I'd like to see some holes filled
in, and would prefer to wait, I think this proposal must be evaluated as
though any AHL solution does not exist, because none do.

[Ishii, Koji a | Koji | BLD]

> I think this proposal must be evaluated as though
> any AHL solution does not exist, because none do.

Agree on this point, and agree that a11y is an important to pursue.

We're disagreeing, however, on that allowing image spines will be a step back regarding the a11y, or will help a11y.

Any opinions on what I'm seeing -- vendors and publishers making recommendations not to include any text in XHTML for FL publications? I understand this trend as an unexpected side effects of not allowing image spines, and we're polluting inaccessibility to XHTML.

Prohibiting drinking by law didn't help people to stop drinking. We should build specs and tools so that a11y can be most easily achieved and authors can have more incentives to support a11y, but prohibiting things someone wants to do can only lead to unexpected side effects.

/koji

-----Original Message-----
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Matt Garrish

[MURATA Makoto]

I also think that mandating accessibility by law
will lead to alibi accessibility (e.g., text-free
FXL XHTML), which is more harmful than no
accessibility.

Regards,
Makoto

2013/4/22 Ishii, Koji a | Koji | BLD <koji.a...@mail.rakuten.com>:

[Matt Garrish]

Right, I'm actually not disagreeing on that point. As I mentioned in my
original reply, I'm aware that this proposal changes nothing but the
pretense of accessibility from those with no intention to include fallbacks.
And there are plenty of other ways of making inaccessible content if that
truly is your goal.

What I believe is problematic here is not that we're taking a step forward
or backward, but that we have imperfect image-based epub accessibility now
that we're reducing back to its primary use case (images alone in spine),
without addressing the issue of how to reliably convey what kind of epub it
is. That information is integral to the publication, at least to me.

The issue already exists in terms of someone deliberately omitting alt text
and descriptions, but if it's imperative to add images to the spine now I
would have liked to have seen a parallel addition to improve the
discoverability and/or switching problems. AHL may be coming with a
solution, but pinning hopes on future technologies doesn't help in the here
and now, and is always a hard sell when you can't say exactly what a new
technology will look like or how well it will be supported.

I understand the need for manga, comics and other image-based formats for
which accessibility is imperfect anyway, but the side effect is that epubs
that are no different than inaccessible image-based PDFs also become an
acknowledged and valid form of distribution.

But, again, I'm not objecting to this proposal, only pointing out what I
think is a failing that gets highlighted by this addition.

Matt

-----Original Message-----
From: Ishii, Koji a | Koji | BLD
Sent: Monday, April 22, 2013 4:53 AM
To: epub-work...@googlegroups.com

[Hadrien Gardeur]

    Now suppose the book instead had two renditions, one with bitmaps as
    spine items, and the other with textual equivalents in XHTML spine
    items. How are these friends expected to read the book together?

With AHL, you could potentially have two renditions, and map the resources of each rendition together.

[Ishii, Koji a | Koji | BLD]

> the side effect is that epubs that are no different than
> inaccessible image-based PDFs also become an acknowledged
> and valid form of distribution.

Image-based PDF as a file format is accessible if I understand correctly. It's just that an author doesn't put a11y information into it, and that specific PDF content is inaccessible. Because so many do so, people consider PDF as a file format inaccessible. The same applies to us too. Regardless of the media types, it's inaccessible if the author doesn't put a11y information. Prohibiting image spines is not helping anything.

For switching, I don't think it's a big issue here; authors can keep using XHTML/SVG to put a11y and stay away from image spines. They may not be able to enjoy the best performance today, but they could add a rendition of image spines when AHL is done.

We can't force a horse to drink water. We already have good enough abilities to make contents accessible for who wants to do so. Isn't it great enough?

[Leonard Rosenthol]

The problem with image-only ANYTHING - but it PDF or EPUB or TIFF - is
indeed what additional information is provided for a11y…and what type(s)
of a11y you are concerned about.

If the image is a photograph, you could easily provide an "alt" for it,
and no one would complain.

BUT if the image is a scan of a piece of paper, then what do you provide
for a11y? A simple "alt" - many would argue that's not acceptable. A
"long desc" - maybe, but of what and in what format? Or do you need to
provide "hidden text", where an OCR(-like) process might produce normal
text that accompanies the image in some way?

Leonard

On 4/24/13 12:21 PM, "Ishii, Koji a | Koji | BLD"

[matt.g...@bell.net]

Agree with all your points, and my intention was not to get into format comparisons; I was only highlighting what is a common complaint and that applies equally to EPUB, even now, whether someone is forced to go through an xhtml wrapper or not. It just becomes more obvious by having images in the spine that accessibility is never assured.

But images in spine, or images in xhtml in spine, was only my launching point into the underlying issue of discoverability, so maybe I've hijacked this discussion. Ideally the reader should be able to discover the nature of the content, as George noted on the last call, which is why I was pointing in my first email to work that has been going on to enable similar discovery for web resources. Given the information about whether the primary access mode of a publication is visual only, visual only but including some additional accessibility features like alt text and descriptions, textual or perhaps even visual and textual when multiple publications are provided, begins to allow for informed choice.

Like all accessibility features, such a mechanism will only be as useful as those who provide the information, and how it gets presented to readers/consumers, but if images in the spine aren't a bad thing I can't see how additional methods for discovery can be a bad thing, either.

Matt

[Ishii, Koji a | Koji | BLD]

Ah…I guess I’m lost here, sorry. Could you elaborate a bit more?

 

When you say “additional methods for discovery”, is it about accessMode property you mentioned before? Is it proposed before and declined, or someone said it’s a bad thing? And how does it related to image spines?

 

/koji

[Matt Garrish]

No, it’s not been proposed before; images in the spine simply highlights it as an area where we could improve in conjunction so that we have something beneficial to offer for accessibility. ONIX code list 196 addresses some aspects of the accessibility features that are included, but nothing exists right now, in epub itself, that indicates the specific access mode(s) of any give publication.

 

Or, in other words, if I were to provide you an epub, short of opening it up and rendering the content you can’t tell me anything about it from the package metadata alone. At the very least you’d have to check the spine for all-image content, but even that is suboptimal except in such very straightforward cases. I’m suggesting that it would be better if the epub itself could carry information about the access modes it’s been designed for, as only the author typically knows that information ahead of time.

 

This could probably be addressed as a parallel issue to images in the spine, but images in the spine was the seed of my opining that perhaps we should look at this broader content issue. We talked about what AHL might offer in the future on the last call to assist, but AHL is somewhere down the road.

 

Matt

[Matt Garrish]

And to briefly clarify the project I pointed to, there are a number of metadata properties that would be variously useful to adapt/adopt for publication content identification.

 

I mentioned accessMode, which distinguishes the nature of the content, but a complement to it is mediaFeature, which provides various details about accessible features in the content. An image-in-spine publication would have an accessMode of visual, but a more accessible xhtml wrapped version might list the same accessMode while including mediaFeature metadata for alt text and descriptions. A publication that wraps images in xhtml without either alt text or descriptions would again be distinguishable by only have the visual access mode and no features. Given this additional information, the reader could find the epub that will better meet their needs.

 

There are other potentially very useful properties in the proposal, too, such as for access hazards, where adaptations might exist (or what the epub is an adaptation of), etc. Again, the proposed properties and their expected values are listed in the schema.org proposal at [1].

 

But to avoid clogging the channel here with cross-talk, I’ve opened a new issue to address discoverability.[2]

 

[1] http://www.w3.org/wiki/WebSchemas/Accessibility

[2] https://code.google.com/p/epub-revision/issues/detail?id=353

 

Matt

[Hadrien Gardeur]

There's one issue that we plan on adding to the 3.0.1 tracker as a follow up to the AHL F2F meeting : the introduction of a new metadata element, that would provide a list of "features" required for the publication.

Scripting or support for fixed layout could be one of those features, but support for bitmap in spines could certainly be on that list too.

[AUDRAIN LUC]

As ONIX metadata can be included in the EPUB itself, these information from ONIX code list 196 could then made available to Reading System.

Luc

 

De : epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] De la part de Matt Garrish
Envoyé : mercredi 24 avril 2013 22:12
À : epub-work...@googlegroups.com
Objet : Re: Simultaneous reading, A11Y, and alt="" (re: bitmaps as spine items)

[Matt Garrish]

ONIX covers some of the same media features, but does not cover the access mode (or hazards, etc.). Please see the crosswalk at [1], for instance.

 

But even if it did cover access modes, wouldn’t it be better for this information to be a part of the epub rather than a part of a separate record that may or may not be available, or be embedded in the publication? The information being in ONIX would be great, too, especially in distribution channels, but it requires processing a specific metadata record format in order to obtain. We have a lot of metadata in the package that is expressed in many metadata record formats exactly because it is important for discoverability, so I would see this as the same case. The access mode would seem to lend itself to rendition selection, as well, which would necessitate an in-publication solution.

 

[1] http://www.a11ymetadata.org/metadata-crosswalk/

 

Regards,

 

Matt

[Ishii, Koji a | Koji | BLD]

Thank you Matt for creating a new issue, I agree with you that it’s important to track but it’s a separate issue.

 

Given that, it looks to me that we’re all fine—or at least can live with—adding image spines support in EPUB 3.0.1. I’d appreciate to know if there were any issues we missed.

 

/koji

[Brady Duga]

I am not sure we have resolved the issue of how such content should be rendered. I am fine with adding images to spines, but I want to make sure I know what to do with them once they are there.

[Jim Lester]

We could model this off of current browser behavior – which appears to treat these as background images with a background-size of ‘contain’ (tested IE10 / Chrome / Safari / Firefox ).

This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please contact the sender immediately and take the steps necessary to delete the message completely from your computer system. Not Intended as a Substitute for a Writing: Notwithstanding the Uniform Electronic Transaction Act or any other law of similar effect, absent an express statement to the contrary, this e-mail message, its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind this sender, barnesandnoble.com llc, barnesandnoble.com inc. or any other person or entity.

[Ishii, Koji a | Koji | BLD]

+1

[Brady Duga]

"What browsers do" isn't very consistent (or well defined). Attached are renderings from 3 browsers of a simple image, Chrome, Opera and Firefox. They are all different, but reasonable. In addition, epub has other information available that a browser doesn't, for example page turn direction and language, which could be used to change the display (pin to the right side instead of left, for instance). I can imagine other reasonable rendering as well. I have a hard time believing publishers would be ok with such random behavior.

[Garth Conboy]

Touché!

I would prefer a set of rendering MUSTs or SHOULDs that likely match really desired rendering behavior -- I'd suggest (at least):

-- Image aspect ratio maintained

-- Image zoomed-down, if required, to fit on screen

-- Image centered vertically

-- Image centered horizontally

-- Any "letter boxed" areas filled in to match current RS "reading theme" (likely black or white)

Best,

  Garth

<firefox.png><opera.png><chrome.png>

[Roger Webster]

+1

[Edward O'Connor]

Hi,

Daniel wrote:

> I think that Ted was talking about authoring a11y into the "normal"
> reading flow (i.e. not as a separate modality), so that users relying
> on screen readers can experience the same content as sighted users,
> without having to switch context.

That's right, yes.


Ted

[George Kerscher]

Hi Everybody,

It seems certain that organizations will want to have images in the spine.
An entire publication of this kind is most certainly going to be completely
inaccessible to persons who are blind and print disabled.

The suggestion to have metadata that clearly indicates that this type of
publication is for visual use only seems like a reasonable item to include
in the EPUB publication. In fact having metadata on accessibility in EPUB
3.0.1 sounds like a should to me.

When we get to the point where renditions are possible, I would hope that
the fully accessible version would be the default.

Talk to you on the call later today.

Best
George

-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of Edward O'Connor
Sent: Monday, April 29, 2013 1:33 PM
To: epub-work...@googlegroups.com
Subject: Re: Simultaneous reading, A11Y, and alt="" (re: bitmaps as spine
items)