Tags for Graphics

[wfree-aph]

The \ tag is used for images in HTML. It would also be suitable for file types for tactile graphics that are already supported as images in HTML like SVG, JPG, etc.

There are several kinds of attributes that can be attached to the \ tag such as src to signify the file type to be displayed, alt to set the alt text for the image, and style, width, and height to set the intended size of the image.

We may also want to consider how we will handle common tactile graphic file types that aren't supported as images by HTML like PDF.

There are several options here and more to consider but I wanted to make this ticket so that tags for graphics weren't seen as an omission and so everyone had a chance to comment. The Tactile Graphic Task Force will make recommendations about what to do here later but first we'll need to settle on which file types to recommend. Based on those recommendations, we can then make a recommendation for how they are handled and what information is included.

The questions remaining here are too numerous to list.

[skntkacm]

Within the placement of the tag in the e-braille file,I would include tags:

• width and height: could be added in character per line and lines per page? This way it can be easyly understandable, for what size the image was ment. This could be adjustable perhaps, resizing the image.
• Resizable Y/N: Not all images are worth to resize due to the details. There should be an option for allowing or not allowing resizing.
• Alternative text: text which will appear only if the picture is not shown, or not possible to print. Describing, what would be seen if the picture would be printed or shown.
• title: name of the picture above it. Snown always.
• describtion: text which will appear always along with the picture, describing it.

The picture itself should carry at least information about:

• format: how are the dots in the image localized on the page/braille display
• dot information: each dot information )position on x,y scale and height)

[wfree-aph]

The Tactile Graphics Task Force would like to recommend the following:

• Use img tag for svg, png, and jpg.
• Also support embedding svg directly into html using the svg tag.

Required attributes: width, height, alt text, and src.

Optional: Would like to include extended description, potentially include media, and an audio recording tour of the graphic.

• For extended descriptions, we recommend that they be used with complex tactile graphics. -- Recommend using aria-details and the details element for extended descriptions. Could also potentially include an audio file that covers the "tour" aspect using the details element.

• For media, we recommend specifying the preferred output type of the graphic (multi-height, paper, dynamic, etc.) when relevant. Not sure if media will work the way we want it to here since media seems to be deprecated in CSS.

• Use "a" tag with download attribute for pdf.

Would like to include as much of the same information here as is possible but may be limited by the anchor tag itself.

The implementation detail here is that the user will be reading the main file and then come to the download link for the PDF, they will activate that link and then the PDF will be opened. Once the PDF is opened the user will review it and potentially want to navigate back and forth between the PDF and the text. Importantly, when the user closes the PDF, they will want to remain at the same location they were at before closing the PDF.

[wfree-aph]

James recommends BRG file type for inclusion as well. William says that we could consider adding that later but that these file types were recommended because of how common they are (both in production and in file handling). BRGs can be any size. George says it sounds like the pre element, so whatever is there gets reproduced and white space is preserved. It is suggested that we could table it for now while we learn more about it and see whether it would be appropriate to include.

James asks about labelling the diagram. William talks about how the various file types handle text. Avneesh suggests that this should be its own ticket and use case. James and William agree.

Width and height would be the minimum size that the graphic could be reproduced. Units for width and height are discussed in ticket #81.

James asks could you use the anchor tag with a svg, jpg, or png? Not sure what the advantage would be of using that method for those file types. You can't use an anchor with an svg, you instead have an anchor to another page. The advantage is that you could temporarily "hide" the image file and then it appears in a different "window" rather than always being embedded in the text. Avneesh says that we could validate this and allow it.

George summarizes that the anchor tag could be used for things that are not a part of the braille file and are external to it. We need to flag the PDF to the reading system, so it can process the PDF, open it, and then process it.

There's a question of whether the question attribute is needed. Avneesh says we can figure that out when we are developing reading systems.

There's a question of whether reading systems would allow the file to go to different hardware. It could potentially but that will be on the reading system.

There's a question of how to add the additional details to anchor. George says that we can add the details element. That's just a convention, it's not a part of the content model. The validator couldn't catch the inclusion of the details element but it would have to go beyond parsing. It's just not an html construct that could be caught with the HTML validator from W3C.

[egli]

To me brg seems more like a raster format as opposed to a more flexible vector format like svg

[wfree-aph]

Discussed in the Tactile Graphic Task Force: Could define the characteristics we want for the anchor tag using CSS. There's no standard way to do that using tagging. You could embed the PDF in a special PDF viewer, which might be an iframe but it is unorthodox.

Some question of whether we should convert PDF to SVG, JPG, and PNG. Doug worries that we risk losing information in this conversion process.

Height and width are handled in PDF already, so we don't have to worry about that. The alt text could be included with the anchor tag.

If someone links to an img with an anchor tag, that HTML page with an img file, the height and width are contained in that HTML page. It does create a burden on the reading system and isn't as clean as just using the img tag.

The anchor tag can use the title attribute to know what it would be if they were to print it out.

Recommendation to use standard measurements for embossing a graphic, so pixels, mm, cm, or inches, and then using a relative units for a dynamic mediums. Most of the content authors would be more comfortable using a relative unit. This would be one image with different at medium rules. One set of rules in CSS for the static image and one set of rules for the dynamic image.

CSS will override dimensions mentioned in the tagging. Width and height are not recommended for the tagging and are instead using width and height in the CSS.

George asks, will we have unique CSS for the images? Doug is thinking that this could be the case but not necessarily.

[wfree-aph]

Here is a proposal, which is based the discussions with the group and advisement from talking with Avneesh and George. Folks please chime in on this ticket with any feedback or suggestions.

Proposal for img tags

img tag will be used with SVG, PNG, and JPG

Without title:

\

With title: How the title is utilized is on the reading system (so displaying it with the image, making available with a click, etc.) \

Width and height are handled using CSS. Will rely on the media type, so standard measurements when embossing and relative units for dynamic reading systems. CSS to be further defined in separate ticket.

Extended descriptions can be handled using aria-details and the details element.

\<img src=”xyz” alt=”alt text” aria-details=”aria-details go here”\</> \

\

This is where you put the text that your extended description is behind\

Extended description which includes markup, such as a table goes here. \

Proposal for PDFs

anchor tag will be used for PDFs

\relevant image name or link text goes here\ or \<a href="PDF file name" download title="relevant image name or link text goes here"\

Width and height will be handled using CSS in a manner similar to img tag and will be further defined in a separate ticket.

Questions to consider

For device developers, would HTML details work well with their reading device or link to extended description in another file work better? For now we can keep both of these techniques for extended descriptions, and we can update our recommendations if we find that device developers are not comfortable with either approach.

[mattgarrish]

anchor tag will be used for PDFs

Did you consider the object (or iframe) element, or do you not want the PDFs rendering within the content?

Downloading PDFs out of a container onto the local file system could be problematic. We didn't get deep into this in EPUB when we considered downloadable resources, but I recall it being one of the concerns raised.

[jylioja21]

Some questions: The title attribute: Are there thoughts on what we should use this for? In HTML, it is not always made available by browsers or assistive technology. However, it is recommended as a way to label an iframe for screen readers. It is also mentioned as a way to provide a textual description similar to aria-description. This point is discussed on Mozilla's aria-details page. The accessibility isn't as big a concern in this case since the reading systems are going to be designed to be accessible, but following the purposes in HTML as closely as possible seems like a good practice. The title attribute cannot contain formatting except for line breaks, which is cautioned in the html standard. The second example for PDF appears to use an empty anchor element. An empty anchor in HTML would have no link text to activate, so I would suggest the first example. WE could possibly use the title attribute in the first PDF example to give an additional description like alt text on an image, though it's not specifically defined for accessibility as alt text. E.g. <a href="PDF file name" download title="title goes here">relevant image name or link text goes here</a> There is also the aria-label attribute but I don't really like that in this example since it would override the link text inside the <a> element. aria-description is intended for a longer description and doesn't really seem to match the same idea as the alt attribute as a short description for an image. Maybe title fits best despite it not being specifically accessibility related? For associating text in the document such as "figure 1. title of figure goes here" with the image, there is the figure element with associated figcaption. The figcaption gets put either at the top or bottom inside the figure element. It can have formatting such as as emphasis if needed since it is document text. Ticket #63 discusses associating a legend/key with an image. Would having this in the element referred to by aria-details be enough or would there be some value in specifically associating a legend? A reading system could potentially allow the user to move from the image to its associated aria-details section of the text. There is no way to go back from the text to the image but reading systems could implement functionality to go back, or the text in the details could contain a link to go to the associated image. If a legend was defined in addition to the long description, a reading system could offer the choice to go to either one separately instead of just the long description. It would likely need some custom markup and then adoption by reading systems.

[avneeshsingh]

@mattgarrish we did discussed embedding PDF in HTML using object and IFrames. The decision to use a simple anchor link is based on simple approach for MVP. If reading devices find issues in it, we can revisit it. Unlike EPUB 3, EBraile is mainly for accessibility. Embedding PDF in objects and IFrames come with additional accessibility challenges. I still find it quite difficult to efficiently navigate the embedded PDF. We should consider this approach after fair amount of testing for accessibility and also considering requirements for security.