alt text for cover image

[dauwhe]

George has mentioned the need for alt text for the cover image declared in the package file:

<item properties="cover-image" id="cover" href="cover.jpg" media-type="image/jpeg" />

Could we just add an alt attribute to item?

[mattgarrish]

If there's an aversion to adding new attributes, we could potentially follow what pub manifest did using refines:

<meta property="schema:name" refines="#cover">This is the alt text</meta>
<meta property="schema:description" refines="#cover">This is the extended description</meta>

<item properties="cover-image" id="cover" href="cover.jpg" media-type="image/jpeg" />

[HadrienGardeur]

refines are a pain to deal with for RS, I'm much more in favor of adding an alt or description attribute.

[jenstroeger]

[…] need for alt text for the cover image declared in the package file

It sounds like that alt text would duplicate the alt text of the actual cover image? Then, does that mean they have to be the same? Feels like introducing unnecessary redundancy to me.

[iherman]

It sounds like that alt text would duplicate the alt text of the actual cover image? Then, does that mean they have to be the same? Feels like introducing unnecessary redundancy to me.

If the cover image is (as in the example) a jpg image, then, as far as accessibility is concerned, that duplication (if it is a duplication) is probably necessary because there is no other place to put the alt text. But if the cover image is, e.g., an SVG file, then we should indeed rely on the intrinsic a11y features of SVG and not duplicate content. But I believe the proposal was to keep alt optional, so we are fine.

[jenstroeger]

If the cover image is (as in the example) a jpg image, then, as far as accessibility is concerned, that duplication (if it is a duplication) is probably necessary because there is no other place to put the alt text.

@iherman, I don’t follow. That jpg file would be referenced by an <img> element which should always have an alt attribute for accessibility reasons.

[iherman]

@iherman, I don’t follow. That jpg file would be referenced by an <img> element which should always have an alt attribute for accessibility reasons.

… if it is part of an HTML file. But a cover image in EPUB is a single image file, without an HTML wrapper (see the issue statement above); that is when the alt text problem occurs.

[HadrienGardeur]

I think we would need some clarification from @GeorgeKerscher but I can think of at least two cases where you wouldn't necessary have that alt attribute on the <img> easily available:

• in many RS, the cover is treated almost like metadata and extracted from the file to be presented to the user
• images could be references directly in the <spine> and if you don't use the fallback (HTML or SVG), then the alt attribute on <img> isn't available

[clapierre]

In many RS, the cover is treated almost like metadata and extracted from the file to be presented to the user.

If they are doing this without an alt text description of that cover image then they are violating WCAG 1.1.1 Non Text Content. There needs to be a way to get at the alt text description that publishers are now putting into their cover.xhtml pages.

[mattgarrish]

@clapierre I'd expect this is a UAAG consideration, since the cover in the spine would be in an HTML wrapper and have an alt to be accessible, but does UAAG require alt text be presented in all situations? (I doubt it even considers things like splash screens, unfortunately.)

To play a bit of devil's advocate, I'm concerned we may actually make things more complicated. The display of the cover is just a splash screen to show something while the content loads. It really is oriented to visual readers.

Are we introducing new problems if we require the announcement of alt text, like having to pause the splash screen during announcement, how to turn this off for people who don't care to hear the cover repeated, how to get back to the splash screen if the information is announced too quickly, etc.

Since the cover is often also a spine item, it also seems to add some redundancy.

In other words, I'm not entirely sure what to make of this issue. I understand why it's needed for audiobooks, for example, where an HTML wrapper is optional, but am less sure about EPUB.

[HadrienGardeur]

To play a bit of devil's advocate, I'm concerned we may actually make things more complicated. The display of the cover is just a splash screen to show something while the content loads. It really is oriented to visual readers.

That's just one way it could be handled by a RS. I don't think we should be that specific since a RS is free to use this info in various ways.

[mattgarrish]

That's just one way it could be handled by a RS.

What situations are there where the context isn't already handled in some other way? Bookshelves generally already provide the title and author from the metadata.

[HadrienGardeur]

Bookshelves generally already provide the title and author from the metadata.

I guess it depends what you'd like to provide as alternate text. Some covers are very basic (title/author) while others could have a lot of visual information that you might want to provide alt text for.

[clapierre]

I guess it depends what you'd like to provide as alternate text. Some covers are very basic (title/author) while others could have a lot of visual information that you might want to provide alt text for.

It really depends on what is the surrounding text for this image. if that information (title/author etc.) is already available then these images can be declared decorative, also this information with rich alt-text and potentially an extended description explaining everything going on could be found on the cover.xhtml page.

[mattgarrish]

I'd like to understand the use cases better. It seems like this could lead to unwanted redundancies since covers don't often convey more than title and author. It also potentially introduces the risk of forgotten metadata if the html also has to provide these.

[avneeshsingh]

We have already fixed this issue in Web Publications. We should try to fix this in EPUB 3 specifications also.
Many times cover images convey more than title and author. Cover image is also used for marketing and generating interest in the publication. Therefore the information which is available to visual users should also be available to non-visual users.

[llemeurfr]

As a RS developer, I'd also like to know in which context the alt-text should be "voiced" ? For example, should it be voiced when the user goes through a bookshelf and moves from "book item" (i.e. a small cover image + the title + the authors) to the next?

[mattgarrish]

Cover image is also used for marketing and generating interest in the publication.

Right, but covers are also often in the spine where additional descriptions can be provided, which wasn't the case with audiobooks. There you can have just a bare image.

As a reader trying to navigate your bookshelf, for example, would you want to hear all this extra information read out automatically? Do you want to hear the title and author followed again by the title and author in the alt text for all the books that don't have significant covers?

I'm not saying there's no benefit and it's not worth doing, of course, but it would be helpful to know when and how this information is expected to be used to make sure authors and developers don't misuse it.

[clapierre]

Cover image is also used for marketing and generating interest in the publication.

As a reader trying to navigate your bookshelf, for example, would you want to hear all this extra information read out automatically? Do you want to hear the title and author followed again by the title and author in the alt text for all the books that don't have significant covers?

As a sighted user navigates your bookshelf they see the book jacket cover which obviously has the Title of the book, and the author and they see information like "New York Times Best Seller" and other marketing information which makes them want to read this book. This is what a Screen Reader user needs the same access to.

I don't want to hear the same information announced twice (ie. Title and Author) since that is already announced, but I do want to know that this book is a "New York Times Best Seller". As long as the most important information is read first and "extra" information follows I can always interrupt the speech by moving to the next title.

[mattgarrish]

As a sighted user navigates your bookshelf they see the book jacket cover which obviously has the Title of the book, and the author and they see information like "New York Times Best Seller"

In your bookshelf, or when you go to purchase or download the book in the first place? After I have a book, the only thing the cover does for me is let me key in quickly on which of all the icons on the screen I want to open. The icons themselves are generally too small to read in any meaningful way (beyond title and author).

But if we're talking about extended descriptions, maybe alt text isn't the right way to frame this. Extended descriptions, by WCAG definition, are only needed when an alt text won't suffice (or in this case, we could say the author and title metadata aren't enough). That begins to alleviate some of my concerns that we'd be pushing authors to fill in this information no matter how redundant it might be.

[avneeshsingh]

"I'm not saying there's no benefit and it's not worth doing, of course, but it would be helpful to know when and how this information is expected to be used to make sure authors and
developers don't misuse it."

Alt text should be optional. If the cover image is just conveying title and author, then alt text should not be used. But if the cover image is conveying something meaningful, beyond title and author, then alt text should provide a description for it.

Regarding need of providing extended description, I think, if the image is quite complex, which cannot be described by alt text, then a better way is to place image on first xhtml file and provide extended description using something like details element.

[GeorgeKerscher]

Hi, Question and comment: Q: I think we are talking about some kind of alt text in the package, probably next to the reference to the cover image, right? Comment: It would be reasonable to put some short alt text in the package, but an extended description, which I would be an edge case, way, way out on the edge, would need to be inside the book in an XHTML document that would support techniques for providing an extended description, e.g. a table.

[jenstroeger]

@GeorgeKerscher Comment: It would be reasonable to put some short alt text in the package, but an extended description, which I would be an edge case, way, way out on the edge, would need to be inside the book in an XHTML document that would support techniques for providing an extended description, e.g. a table.

That’s the approach that Word takes, but very few authors make use of:

I’ve not seen a document that offers the short alt text and the long description, but it does make sense to provide such a feature.

[mattgarrish]

I think we are talking about some kind of alt text in the package, probably next to the reference to the cover image, right?

Right, this is about adding more metadata to the package document, so it's not information that would be used in the spine rendering of the content.

To help me understand this proposal better:

• is this attribute only allowed on a manifest entry with the property cover-image or is it allowed for any image/resource?
• if it's allowed for any image or resource, what guidance are we giving for publishers on why that's the case?
• in what scenarios are we expecting it to be used? (e.g., is this only intended when other metadata such as the title and author cannot be presented; should it always be made available whenever the image is displayed regardless of other information)

Fleshing these out will help ensure we have a solid foundation for the attribute.

[GeorgeKerscher]

It is now common practice in Higher Education with EPUB to include alt text, and where needed extended descriptions. In the publisher Faceoff webinar we examined the publisher usage of the techniques. The webinars are part of the DAISY Publishing and Reading series found at daisy.org/webinars We now have test books on epubtest.org that show the recommended techniques for extended descriptions.

[GeorgeKerscher]

Hi, IMO the additional information is needed only for the image used as the cover. Other images have their XHTML markup for alt text. The problem we found was that the images displayed in the bookstore or in the App provided information the blind person could not get at. Sometimes people refer to the image on the cover, e.g. in computer science the “dragon book” where there was a stylized dragon on the cover of Compiler Tools and Technology . Every student just called it the dragon book and unless you knew that, you would not know what the students were referring to. My $.02

[mattgarrish]

IMO the additional information is needed only for the image used as the cover. Other images have their XHTML markup for alt text.

This matches what I'm thinking, too. If we make this attribute too general, I think we're going to confuse people and have publishers thinking they are supposed to add this for all images even though they won't be used.

Every student just called it the dragon book and unless you knew that, you would not know what the students were referring to.

Right, we've discussed this problem before. Is this the primary case for the attribute, or is it expected that there could be lengthier descriptions including the various marketing material?

If we're just trying to capture a colloquial title for the publication, an additional metadata property might be more appropriate, as it's arguably different than the alt text for an image.

[clapierre]

Every student just called it the dragon book and unless you knew that, you would not know what the students were referring to.
Right, we've discussed this problem before. Is this the primary case for the attribute, or is it expected that there could be lengthier descriptions including the various marketing material?

I would suspect it would include George's concerns and additional marketing materials used to promote the book, any seals on the book "NY Times Best Seller" or "Barnes & Noble Book Club", etc.

Also if we eventually get into Magazines as EPUBs knowing the the title "National Enquirer" doesn't really tell you much, its a collage of photos of famous people with multiple headlines "Kelly Clarkson's Divorce turns ugly", "25 Years after OJ beats MURDER rap", "Fox News Sex Scandal Explodes", etc. All of that text is super important and currently would be unavailable as its all part of the cover image.

[GeorgeKerscher]

Hello, Another metadata property for the image is an interesting thought. First, we would hopefully avoid alt text best practices in content documents, and secondly give the publisher the freedom to convey their intent by using this cover. It might be just an interesting design, like a fractal, It might convey mood, a unique animal associated with the title, an award winning work, or anything else. The blind would know that they are not missing anything. Best George

[mattgarrish]

All of that text is super important and currently would be unavailable as its all part of the cover image.

I'm not suggesting it's not important, but I want to make sure we're not tackling it from the wrong angle.

The more I hear the more I wonder if something like dc:description would provide us what we want. It avoids an attribute that is only needed for one purpose, avoids confusion with alt text and possible redundancies of information, but provides the flexibility to give a short description that can be used within the bookshelf. It could include more than what's on the cover, if that's important, too.

As a sighted reader who honestly can't make much of the icons most reading systems display, I can see a benefit to this information being available to anyone, not just AT (although it could be used as alt text in space-constrained situations).

[GeorgeKerscher]

I could imagine people adding a lot of text to the description as for the whole title, which would not solve the cover image issue. Other thoughts?

[mattgarrish]

I could imagine people adding a lot of text to the description as for the whole title

Right, I only meant something like dc:description, as I don't think that particular property is appropriate, either. It could be something like a new cover-desc property.

[iherman]

The issue was discussed in a meeting on 2021-05-13

• no resolutions were taken

View the transcript

3. alttext for cover image

See github issue #1300.

Matt Garrish: we discussed this too in web publication, publication manifest
… cover img are sometimes used in contexts without html wrapper
… how to do this in package?
… one way is to add an alt-text attribute
… or we could use refines attribute and setup property name, refines could then point the additional metadata field at cover
… but which is more effective?
… each has its pros and cons

Avneesh Singh: whatever our group decides will become a recommendation to WG, not only our decision

Charles LaPierre: if we did the refines method, for the cases where you have cover img in XHTML wrapper (with full alt-text), would that then be duplicated in the package?
… are we worried about that duplication?

Matt Garrish: yeah, that's one of the downsides
… will be duplication between whatever is in package and what is in XHTML
… and then you'd have to maintain it in two locations
… i was just thinking that maybe a pointer into the document could potentially be a 3rd option
… but yes, could potentially be duplicative, depending on which method we choose

Tzviya Siegman: +1 to pointing to existing image description

Avneesh Singh: it would be nice to have a simpler solution

George Kerscher: so this is used in the bookshelf view (e.g. reading through list of books and this information comes up), as opposed to opening the book and reading it there
… two completely different purposes
… not sure if it would be voiced twice by AT
… some people have also complained about cases where only the text of the cover is conveyed to AT, but the rest of the cover detail isn't

Gregorio Pellegrino: we will also need best practices for how to implement this
… in a library view, it might be too verbose to have a description of the cover spoken every time

Wendy Reid: the challenge for RS would be surfacing this data
… in the bookshelf view/gallery view, i think most RS are just using title and author
… this is same situation for store carousel
… even with alt-text inside book we don't often get detailed desc
… like with frontlist titles, covers get updated often (for awards, for movie tie-in covers)
… can see publishers not keeping this up to date

Tzviya Siegman: would there be different descriptions for the actual cover and the thumbnail cover?
… as a sighted user, I don't process the info in a thumbnail the same way i process the cover in a full view
… so for the pointer based solution, we might not want the description of a thumbnail to be the same as the description inside
… for the books that I work on, where the textbook covers aren't that exciting, its likely that we'd just want to present basic title/author

George Kerscher: there's a benefit of alt-text over the refines method, as alt-text is pretty well known these days
… alt-text is intended to be brief
… and then when the user opens the book to the cover, that's where more detailed desc can be used

Charles LaPierre: in Canada there is a pilot right now to help publishers create alt-text
… the view there is that alt-text for the cover in the book should be more than just title/author
… we probably don't need all that in the package metadata
… so maybe refines is better from that perspective

Matt Garrish: kind of worried now if we also call this alt-text we will sow confusion
… we also don't want to compel people to put this metadata into the package even where it isn't needed if we call it alt-text

Wendy Reid: +1

Avneesh Singh: important to have a short desc for the bookshelf view, and a more detailed desc for inside

Matt Garrish: +1

Gregorio Pellegrino: +1

Tzviya Siegman: have we looked into how each of these different methods of approaching this works with AT?

Charles LaPierre: +1 ask RS dev. Thorium Bookshelf etc.

Wendy Reid: would like to get feedback from RS developers about how this could be done

George Kerscher: when RS developers display this information, they would probably be using the img element with alt-text
… so if we had alt-text available for them, they could just copy the alt-text over along with the img

[mattgarrish]

Here's a list (in no particular order) of the various possibilities we touched on in today's call and/or in this issue:

• a specific attribute on manifest items (e.g., alt) for alt text strings
• a specific attribute on manifest items (e.g., alt) that references the alt text in the cover's html/svg content document (to avoid duplication)
• a more general attribute on manifest items (e.g., label) for strings that could be used as the alt text when available (to avoid overuse when not needed)
• a general metadata property (e.g., schema:name) associated with the cover image using the refines attribute
• a very specific metadata property (e.g., cover-desc) that can only be the cover's alt text so doesn't need refines

[xfq]

From i18n's standpoint, defining attribute values that will contain user-readable content extends a problem we already have with <img alt="...">. For example, the page author can't indicate changes in language inside the attribute text that would allow for better assignment of fonts or styling, and can't use markup to indicate base direction.

Would it be possible to introduce an element-based solution like figcaption in HTML?

[iherman]

The issue was discussed in a meeting on 2021-05-13

• no resolutions were taken

View the transcript

3. Alt-text for cover images

See github issue #1300.

Dave Cramer: this was discussed in a11y call this morning

Matt Garrish: we didn't end with a proposal
… we're looking for feedback from RS people about which of the possible solutions could realistically be implemented

Brady Duga: not sure how we get covers

Wendy Reid: probably sent separately

[mattgarrish]

Would it be possible to introduce an element-based solution like figcaption in HTML?

This is effectively what using a property value would allow, similar to the other metadata in the package document.

So, depending on what property we settled on, a description might be expressed like this:

<meta property="cover-desc">Short description of the cover.</meta>

You could then, if needed, set xml:lang on the meta element.

Whether this information would be directly user readable I believe is still an open question, though. One thought is that the text could be translated to HTML (as the alt for an img tag) for a web-based bookshelf, but what happens with apps is a bit unknown.

It's also unknown whether information in the epub is useful for the bookshelf, as it sounds like most vendors accept the thumbnails for books separately from the epubs themselves.

Still a lot of work to do, in other words.

[avneeshsingh]

In last accessibility task force meeting we decided to seek the feedback of reading systems developers for getting a sense, which approach is suitable for their implementation.
The list of options compiled by Matt are:

1. a specific attribute on manifest items (e.g., alt) for alt text strings
2. a specific attribute on manifest items (e.g., alt) that references the alt text in the cover's html/svg content document (to avoid duplication)
3. a more general attribute on manifest items (e.g., label) for strings that could be used as the alt text when available (to avoid overuse when not needed)
4. a general metadata property (e.g., schema:name) associated with the cover image using the refines attribute
5. a very specific metadata property (e.g., cover-desc) that can only be the cover's alt text so doesn't need refines

[r12a]

Just to be clear as possible, ideally any localisable text content would:
a. allow an overall language and direction to be specified for that content if different from the surrounding content (this can't be done with attributes, so elements are preferred)
b. allow nested spans that change the language or direction for a subrange of that content (again, language changes can't be indicated in attributes; direction changes could be achieved using Unicode formatting characters, but that's not desirable).

Hope that helps. (Fwiw, this is mentioned here in our guidance for spec developers.)

[danielweck]

1. a specific attribute on manifest items (e.g., alt) for alt text strings

2. a specific attribute on manifest items (e.g., alt) that references the alt text in the cover's html/svg content document (to avoid duplication)

3. a more general attribute on manifest items (e.g., label) for strings that could be used as the alt text when available (to avoid overuse when not needed)

4. a general metadata property (e.g., schema:name) associated with the cover image using the refines attribute

5. a very specific metadata property (e.g., cover-desc) that can only be the cover's alt text so doesn't need refines

Hello,
speaking from the perspective of a reading system implementer (Readium / Thorium), I would prefer option 5, i.e. to update the EPUB metadata parser in order to extract an additional cover-desc "localized" string (much like dc:title, see https://github.com/readium/webpub-manifest/blob/e5edaef5d7b6010b17c809a5679630ad00b403c5/schema/metadata.schema.json#L26-L31 and https://github.com/readium/webpub-manifest/blob/e5edaef5d7b6010b17c809a5679630ad00b403c5/schema/language-map.schema.json#L1-L20 ). I would then subsequently update the internal data model (aka. Readium Web Pub Manifest) in order to elevate the new "cover description" as a first-class citizen in the API surface, thereby making discovery easy at the application level - such as when displaying the cover image in the bookshelf view (where the localised "cover alt text" would be accessible to screen readers, and possibly via a hover tooltip as well).

Note that as a rule of thumb, handling XML ID-based "refines" in the metadata parser in order to generate our internal data model is considered problematic from a design perspective as JSON serialization doesn't lend itself to ID-style cross-referencing. So option 4 is not preferred.

I am not sure options 1 2 and 3 solve the problem of string language (and possibly direction), which is what I was referring to when using the term "localized string". Furthermore, option 2 would impose a level of indirection into content documents that would be expensive at runtime (and from an implementation viewpoint too), compared with picking-up the data directly from the package OPF file.

One final note: in the internal Readium Web Pub Manifest data model, a native link data structure is used to express references to external assets. For example, XHTML manifest items that are used in the EPUB spine are simply expressed as links in the RWPM readingOrder list (no spine-manifest level of indirection). Another example: image manifest items that are not used in the spine but merely listed as publication assets are simply expressed as links in the RWPM resources list (which is by definition separate from the "reading order"). This common link object can have a title string which is similar to the alt attribute on images:
https://github.com/readium/webpub-manifest/blob/e5edaef5d7b6010b17c809a5679630ad00b403c5/schema/link.schema.json#L19-L22
...but the language property is associated with the referenced resource, not the title string:
https://github.com/readium/webpub-manifest/blob/e5edaef5d7b6010b17c809a5679630ad00b403c5/schema/link.schema.json#L61-L72
This is why a metadata-level "cover description" seems to make more sense, all things considered. This would mesh quite logically with the fact that a publication has a unique cover image. I suppose EPUBCheck would need to verify that when a cover-desc is present, a "cover image" is also present ... but that's a separate discussion :)

PS: I think that in cases where authors decide to embed the metadata-described cover image in a XHTML document included as a linear or non-linear spine item in the publication, there should be no expectations from reading systems to enforce any additional logic when presenting / rendering the HTML content. In other words, authors should use the most appropriate description markup to annotate the image tag, and they should ensure that the metadata-level description is consistent with the one embedded in HTML for rendering purposes.

CC @llemeurfr @HadrienGardeur

[avneeshsingh]

The issue was discussed in June 24 a11y task force meeting:
Resolution #2: close the issue 1300, since it is not looking high priority

[iherman]

The issue was discussed in a meeting on 2021-06-24

List of resolutions:

• Resolution No. 2: close the issue 1300, since it is not looking high priority

View the transcript

3. alt text for cover image

See github issue #1300.

Avneesh Singh: do we have enough data for providing recommendation to the EPUB3 WG? We got feedback from Readium 2 on issue tracker, and from another reading system developer who responded on email:

Avneesh Singh: We can parse any attribute whether it’s in the metadata or book content itself. The system of pre-processing before display ensures this. But no problem doing it on the front end either if it’s in the xhtml.

Charles LaPierre: wouldn't it be duplicating info with title / author

Avneesh Singh: originally Charles and George was concerned that if an image provides additional information, a print disabled should have access to it.

George Kerscher: if the title & author is there then I agree for the most part that this would be decorative, and the "dragon book" example as it was referred to.

Matt Garrish: is this a bookshelf issue. is this you are trying to find out

Charles LaPierre: concerns about duplicating in the bookstore where this info could be in the book itself.

Tzviya Siegman: "NewYork best seller" is interesting use case. People tend to choose books by cover not sure if they also do the same for the alt text descriptions.

Bill Kasdorf: concern, sending ambiguous message having hard time what to do/not do for alt text. alt should convey information, text as image needs that text in the alt text. Text on the cover needs to be exposed. I don't see we should make an exception.

Matt Garrish: not a description but a title is what we want, conflating issues here potentially
… its another name for this book, its a metadata not an alt text.

Tzviya Siegman: the alt text on the cover image page inside the book. this is not what is provided to the bookstore's thumbnail view of the cover image.

Ben Schroeter: useful info is title/author we have other ways to express that information. In most cases providing that same information as alt text is redundant. If a book has a nickname can't usually be anticipated, so publisher couldn't put this as an alternative name when publishing. So I prefer to drop this extra information.

Tzviya Siegman: I agree with Ben nicknames … there is also in fiction the cover can be changed when movies come out. Original Art Cover, or Movie Cover. There are some that exist, but not sure how many so this is extra info that we are worrying too much about.

George Kerscher: I get the essential info I need, and am quite happy with it. I am with Ben. I don't know where this image gets put on a website where that alt text will come from. but title and author is fine.

Avneesh Singh: should be close this or defer this issue to EPUB 3.4 or 4.0?

George Kerscher: if there are information the Publisher wants they can always put it in the EPUB on the actual cover image's alt text.

Matt Garrish: is it realistic we will come back to this. maybe pub manifest and can figure it out. I would tend to say lets close it.

*Tzviya: +1 to closing it

Proposed resolution: close the issue 1300, since it is not looking high priority (Avneesh Singh)

Ben Schroeter: +1

Matt Garrish: +1

Charles LaPierre: +1

Bill Kasdorf: +1

Laura Brady: +1

Tzviya Siegman: +1

Will Awad: +1

George Kerscher: +1

Resolution #2: close the issue 1300, since it is not looking high priority