Tactile Graphics Taskforce Meeting Notes
Avneesh Singh, Dilip Ramesh, Ka, Nicole Gaines, Sarah Welch, Susan Osterhaus, Will Freeman
How many more meetings does the tactile graphics task force need?
Will have some questions later about how does CSS work with tactile graphics. These questions might be better in large group. So technical people and tactile graphics people can collaborate.
Will cancel meetings going forward but can reinstate them if needed. A lot of discussion on mark up needs to happen in main group.
Will - Susan and Ka, do you have thoughts on tactile graphics to include as samples that you have the right to share?
Susan – Did speak to BANA tactile graphics people. They do not want to share due to copyright issues. Their concerns are that you need the print graphic to know if the tactile graphic has been does well.
Will – Our issue is can the software by company “x” do the tactile graphic. The original creation of the tactile graphic is outside this current scope.
Susan – The graphic artists use CorelDRAW. They convert to pdf to share with Susan. The artists do not want to be associated with a pdf – the images are better viewed in CorelDRAW.
Will – The idea was that not all exemplars to not come from APH. Looking for representation of each file type.
Susan – Agrees on having exemplars from more than just APH.
Ka – Trying to figure out if they have rights to share their graphics.
Will – Will talk with TGIL and try to find graphics that we have the right to share. Then get these graphics made in all the formats they can. Then put a call out on the mailing list for people to check them and send in additional graphics. Each file type is going to be handled by the embosser differently. For example – two different ways to make the color black – and different embossers need different ways for black.
Ka – Same thing with transparency and white backgrounds. It can add an extra layer of dots that are not needed.
Will – Do we need to go as specific as these are for these graphics. Or more general, like these graphics have these backgrounds.
Ka – Thinking about the Graphiti – different resolutions and filters can apply.
Will – Each reading system needs to know which embosser/Graphiti/ monarch the graphic was designed for.
Ka – Will be matter of transparency versus something that is more ease for use.
Will – Worry about leaving someone out, like the smaller manufacturer.
Ka – Got a message from coworker saying anything in their repository should be fine to use.
Will – The approach on GitHub is what is the most basic straightforward way to handle pdfs. Include in first spec. then revise it as feedback comes in from community.
Avneesh – Need to test the objects. The structure is sometimes lost. Need thorough testing. There is a way of building pdfs in html, something can cause structure to appear as a series of lines instead of going through.
Ashley Nashleanas, Dan Gardner, George Kerscher, Ka, Nicole Gaines, Sarah Bradley, Sarah Welch, Steve Landau, Susan Osterhaus, Svetlana Vasilyeva, William Freeman
Do we just create a project on GitHub?
Project area already set up. Create a sub folder at the same level as the specs. Make a samples folder. Then can make sub folders for each file type like PDF, PNG, etc. For each sample have people put a statement on the copyright status.
Do we have some type of standard form for copyright permissions?
At which point is a tactile graphic far enough removed from the original work to not require permission of the original owner. No really good answer for this right now. For full answer would need input from an IP attorney.
Not sure people would have the time to make something for an eBraille spec. People can take what they already have.
Could we use an old textbook at APH? Especially one from Pearson’s – they have been supportive in the past.
We are only talking about taking a small number of tactile graphics from a book to use as an exemplar. Not for profit. May be under fair use exemption, will check with IP person at APH for advice.
APH can supply the PDFs. Other places can supply PDFs if they want.
Files can be sent to William Freeman [email protected]. They will be added to the GitHub.
Looking for 2 to 4 examples per file type to get started. Max of 10 of each file type.
What do we need associated with each file we upload? This will be made into a template:
- What is this
- Why is this here
- How do we know it is working properly?
- Language of sample
- Permissions
- Contracted or uncontracted braille
- Source
Nicole Gaines, Avneesh Singh, Sarah Welch, George Kerscher, William Freeman, Susan Osterhaus, Doug Schepers, Ashley Nashleanas, Sarah Bradley, Svetlana Vasilyeva, Ka Li, Dan Gardner
We sent in recommendation to the main group. The main group had questions and comments
- Using BRG file type.
- Use case for labeling diagram.
- Width and height and minimum size of graphics
- If you use the anchor tag, then it temporarily hides the image file instead of appearing directly in the text.
- Do we want to recommend the anchor tag for all graphics?
Nicole- Implications of using anchor versus image tag?
William – The main issue is more options and built-in support with image tag.
George – The anchors are links to something on same page or another page. Issue is that you are leaving your publication with an image tag
Nicole – Implications for embossing?
William – We are only including anchor tag because we have to for pdf. Only including pdf because it is it is currently so common for tactile graphics
Doug – If you want to treat the image and emboss that you may want to isolate the image from the text. A mixed medium with a style sheet. An argument for both the image tag and the anchor for people to access the image. Supplementing the image tag.
William – Good point about combining image and anchor tag. What is the best way to get the additional information with the anchor tag?
Doug – No standard but could use CSS. It is a matter of in line versus replacement
William – Any way to get the information we want with a pdf?
Doug – It can be done, but it is unorthodox.
George – Some applications taking the pdf and converting on the fly. If we could figure out a way to transform or done on the fly for a reading system to put into a SVG
Doug – Could transform into SVG. No native way for SVG to render a pdf. Can end up with a lot of gibberish with preprocessing.
George – Explain why they cannot require the pdfs be converted for use in these publications to convert ahead of time? The rendering time will be faster.
Doug – Not sure if true. Converting a pdf into a different format that can be rendered will be very inefficient. It becomes very large.
George – The pdfs we are talking about are just tactile graphics and shorter in length.
Doug – Does the spec talk about this being the use case?
William – This is the use case. It is a fear that people will just put into pdf and say they created an ebraille file.
George – You convert it. You know height and width, then use the image element with it.
Doug – PDF has drivers to print or emboss. Using other file types might introduce errors
George – We do want it in line. Want to treat it as image.
Avneesh – This is mainly for the legacy content of the pdf. May be deprecated in the future. Then can handle both cases.
William – We are stuck with pdf for the near future. Could the answer be embedding the alt text into the pdf itself?
Avneesh – In the text inside the anchor that can be going to the alt text.
William – Trying to think of how the reading system will handle it. Could mistakenly end up changing the original document.
Avneesh – Width and height is carried inside the pdf format.
Dan – Alt text in pdf is built in.
Avneesh – If it is exposed in the text then that is sufficient.
Doug – You can add the alt text in the anchor text as well.
William – Main thing was the alt text. Improving tactile graphics generally by making alt text standard. Back to where we were with better justification for how the anchor tag can be used.
William – The relevant ones can be a benefit. Can be measured in braille cells. Can also be pixels, cm, mm, and inches. For a lot of measurements in ebraille the braille cell could make sense. With tactile graphics you are not dealing with braille characters anymore. Best measurements are cm, mm, and pixels.
Dan – Rather use actual measurements like inches, mm, pixels, and cm.
William - That makes a lot of sense.
Doug – Document that is both digital and printed?
William – Yes.
Doug – Encourage people to use physical dimensions. You are talking about a relative unit in your display space. Agree with Dan that physical units are useful in a printed medium. Many content creators do not know how to do that.
Dan - You want enough resolution. Relative units are fine. Use the abstract user units of SVG and define on the root. SVG has a lot of work to be done to know what size things will be printed at. Might be out of purview of this group, but something that the community at large needs.
Doug – Want the text to remain the same size no matter the magnification of the image. Special considerations with SVG. Think it is good to raise the issue of SVG text sizing. Separate issue to be discussed later.
William – Standard measurement for print and relative measuring for dynamic medium.
Doug – Want to do certain things for print versus dynamic medium. CSS would override the dimensions in the image tag.
Avneesh – Width and height are not needed. CSS can handle it.
Doug – The width and height of the anchor tag is meaningless.
George – Does this mean that we will have unique CSS for each image?
Doug – If the image has an implicit size, and you specify you want the image to be a specific width. The height would be determined by the width.
Discussion will be continued on the mailing list.
Sarah Welch, George Kerscher, William Freeman, Ashley Nashleanas, Avneesh Singh, Danielle Montour, Ka, Sarah Bradley, Susan Osterhaus, Svetlana Vasilyeva, Nicole,
William - Main agenda item – tags for graphic tickets - issue 75
Image tag is a standard html tag. Example: img src="img_girl.jpg" alt="Girl in a jacket" width="500" height="600"
Width and height is important – when not included it can cause issues with the page loading or a document loading, so they should be included where possible.
PDF would need to treat as download link. Example: a href="/images/myw3schoolsimage.jpg" download img src="/images/myw3schoolsimage.jpg" alt="W3Schools" /a
We will be limited by the anchor tag.
SVG will use image tag. Could also do a link to a long description.
What else do we need to include?
George - Info to tour a graphic – is that in extended description? audio recording tour to explore image / tactile.
Willaim – Feels like this is needed in audio and text.
Avneesh – The minimum required is alt text with width and height. Once minimum is established then we can determine farther.
George – It is possible to wrap one or more images in a figure element.
William – Image tag for SVG, JPEG. Use the anchor tag with the download attribute for PDF – include width, height and alt text. This is all expanded upon in the ticket.
Ka – would caution with saying extended is optional - a complex diagram would need this.
William – With media specify the preferred output medium of the graphic when relevant.
Demonstration from George – Extended description using HTML details and summary
The details element is located within the file. Has expand and collapse capabilities.
Recommended to put html and aria details right below the element.
Ka – Would it be also possible to also support link method?
Avneesh – That is already supported with hyperlinks.
George – We see this fail sometimes that the reading system when you link back will put you back at the start of the page instead of where you were. When the audio is being played – need to make sure the display still shows the tactile.
William – The recommendation is added to the ticket as a comment.
Attendance: William Freeman, Sarah Welch, Avneesh Singh, James Coughlan, Sarah Bradley, Svetlana Vasilyeva, Susan Osterhaus, Orbit Research, Ka Li, George Kerscher, Ashley Nashleanas, Nicole Gaines, Dan Gardner, Danielle Montour
Notes: The main goal of the meeting today is to finalize file types.
One of the main things from the last meeting was reaching out to hardware developers to see what can be supported
Monarch – most excited about SVG for dynamic tactile graphics, and not excited about PDF. PNG is fine, but not scalable.
Orbit – JPEG is by far the most common currently. Thinks PNG is better in many ways but not as available. Third choice would be SVG. Hopeful that SVG becomes more widely used. Do support PDF, but that has been a mixed bag. PDF can have any content / mixed text and graphics / diagram. This becomes hard to deal with on a hardware system. Does not see utility of PDF. Graphical content can be converted, the user can convert PDF files to another format. Thinks challenges of PDF outweighs benefits.
PDF is a document file type in its own right.
Dan – all have unique challenges. SVG is the most interesting, is scalable, and can mix graphics and text. Challenge is with braille that does not scale. This is a common standard. Not all SVG is identical. Views PDF is a necessary evil since they are not all created the same. Pure graphics like JPEG are fine for graphical content but are not good for text. JPEG and PNG are currently very common. Would need a way to render text on these files.
SVG and PDF created the right way would allow tactile graphic with layers – like text and graphics. Thinks it is not as much the file type, but how things are standardized across devices.
Susan – What does Dave like?
William – Dave said that PDF does not make sense.
William – We don’t have to limit ourselves to 3 file types. Can do 4. Could be good for tactile graphics generally if they do not recommend PDF.
Dan – Why is that burdensome?
William – It is burdensome because of all the PDFs that would have to be converted.
Dan – Challenge is they would love for PDF to go away, but they do not seem to. PDF has a free viewer. Not many good free conversion tools for PDF’s. Most TVI’s do not have the tools to convert PDF’s. Currently, a lot of content is in PDF.
Susan – The teachers want the things at no cost. Maybe we need our own free software
Orbit – Some free software programs available, but these seem not well known in the TVI community.
William – Stakes seem high to not include PDF. Looking at 4 types – SVG, JPEG, PNG and PDF. Can recommend things like only single page PDF. Maybe they can improve PDF to make more palatable and can recommend best practices. PDF is an option but not the best one.
George – Would like to not include PDF.
A vote was proposed on including PDF’s, but was never carried out.
George – How many people can live without PDF?
William – Knows that people will be upset at having to convert all their files
Nicole – How difficult to do conversions?
William – Tools exist to convert files out of PDF, but may be hard on large scale. Does burden of converting outweigh the burden of supporting them?
Dan – PDF is predominant in print text. Maybe support but give guidance on how to do good pdf. For instance, having the PDF be only one page and the text must actually be text instead of a picture.
Avneesh – We can always write the specification in a way to allow user to support PDF for legacy content but know that new content should not be PDF. Would be more complex to include PDF. Complexity could discourage authors of eBraille.
William – Thinks we should discourage future PDF.
George – likes that approach. Group should look at pdf to sng conversions. Can they be batch processed?
Avneesh – in the specifications should not encourage iframe. Would take away accessibility.
Dan – For the supporting file types are we talking about input, output or internal use?
William – Was thinking supporting the inclusion of these file types in the eBraille file. Can give recommendations for each file type so files can be viewed tactically and not wrapping everything in a svg. Must think about lower powered devices – these devices will be the standard until prices can be driven down.
Dan – looking at content creation side of it.
William – braille blaster is not going to convert anything – things can be inserted. User tells minimum amount to be scaled, full out alt text, and additional metadata. Then they will click done and it will get inserted. Have print view and braille view. Will not show tactile graphic in braille view – but could have an image viewer.
Dan – What if you bring image type and then define scalability, then all the other metadata – svg component with all the metadata. Then resave the jpeg with all the information.
William – Think we are getting into implementation, and should refocus on support for now.
Dan – Says support all 4 types is fine but will come down to implementation.
William – Some of that you can do with HTML tags and you do not necessarily need a wrapper
George – PDF linked. SVG, JPEG, and PNG referenced.
William – how to implement in next piece. PDFs will have to be treated as a download link.
George – UI reading document – link to PDF launches another program that views PDF then go back to regular interface. Very similar to having your extended description of am image linked.
William – simple example how to do PDF – <p>Open a PDF file <a href="/uploads/media/default/0001/01/540cb75550adf33f281f29132dddd14fded85bfc.pdf">example</a>.</p>
William – that is the most basic implementation using object data. Probably what we want to do for alt text and image descriptions
Dan – likes all but PDF. Legacy support for PDF to get into system. Maybe not part of the spec but part of the implementation. Special flag for PDF Ka – from library perspective – going with best practices, but most likely link to PDFS.
William – How to simple implementation for images: <img src="img_girl.jpg" alt="Girl in a jacket" style="width:500px;height:600px;">
William – image tag is already set up to include many things we need for accessibility but does not have text.
William – will look more into batch processing PDF into other file types
Next meeting will be the 6th. William will get thread going on email list of what kinds of information we want to include with these file types.
In Attendance: Avneesh Singh, Danielle Montour, William Freeman, Dan Gardner, George Kerscher, Ka Li, Nicole Gaines, Svetlana Vasilyeva, Ashley Nashleanas, Sarah Bradley, Steve Landow
William thanked all for attending and asked everyone to introduce themselves.
Svetlana shared the following link to a podcast recording in the cat: https://www.eyesonsuccess.net/show%20notes/show%20notes%202313.htm. George said this podcast covers the DAISY pipeline app and focused on developing countries.
Last week we introduced file types. Our goal for today is to talk about them more specifically, reviewing pros and cons for using each with the eBRF. If there are instances of uncertainty about a file type, we will note that and perform additional research.
Pros: In a pdf, you can have text (not just images of text); this is relevant for zooming and rescaling. There can be clickable links, like a link that takes you to a specific region. William suggested this could be used to connect a key to the rest of the graphic or other interactive elements. Pdf uses both vector and raster graphics (vector graphics generate images using math so they retain quality while zooming; raster graphics are made with pixels, so as you zoom in, the quality of the graphic is reduced). It is commonly used in North American for tactile graphics.
Cons: Since pdf can have both types of graphics, it becomes harder to control. While we can recommend against it, we cannot stop anyone from include raster graphics. Another issue is that pdf is not traditionally used for images. In HTML, tags support many file types but not pdf. We would have to come up with a workaround. Pdfs have a lot of issues with accessibility, although it is possible to create an accessible pdf. Pdf does not have a great reputation in our field. It used to be a proprietary file type, but it has been an open standard since 2008.
Pdf is a bit problematic, but it is a common file type used for tactile graphics. To bridge wider eBRF support, we should consider including pdf in our recommendation.
Svetlana said they do not use pdfs in her country for tactile graphics. They use PNG and other file types.
William asked Dan to share about his difficulties using pdf. Dan explained that it was an issue with Adobe Acrobat Reader. When printing to pdf, fonts are automatically embedded, so they print as graphics. If you don’t have the font on your computer, it draws the font. Dan had to unembed the font from the pdf file, and they ended up making their own pdf import to properly handle the fonts. Dan pointed out braille fonts post a challenge. Dan and his team were unsuccessful in getting Adobe to support free tools that allow the use of system fonts rather than the embedded font.
William asked about programs used to create professional tactile graphics like CorelDRAW and Inkscape.
Dan replied that there are lots of ways to create pdfs. You can raster-ize the whole image. There are bad ways to make a pdf, but most tools (like Adobe Illustrator) use the fonts. It is just Adobe Reader having issues. Pdf is only a pseudo “open standard” since you have to pay $500 for the spec. Danielle Montour pointed out that not only are there not a lot of free options for TG software, but there are not accessible options to create images. There are no coauthoring options for blind users at this time with pdf.
George stated that pdf is outside the XHTML environment. How would we refer to pdf in the code? And then, what does XML parser do when they hit this thing? The ecosystem is completely different and that is his biggest concern.
Dan agreed. Pdf is meant to be a final result, not an embedded document. If you have something fixed to a full-page size, it may or may not be resizable or have embedded fonts. He said it would be “kind of a nightmare to ever think of it has being embedded in full eBraille file.”
George pointed out that while pdfs are useful for printed material, in eBraille, he does not know how the user will be able to reference and insert a pdf into a reflowable document.
William said, “Since they are so popular, let’s imagine we don’t support pdfs. How difficult would it be for people to convert pdf libraries to a different file type? Would existing tools help?”
Dan replied that it depends on how the pdf is made. Converting a scanned image to anything will be next to impossible. It will not be resizable, vectorized, or have selectable text. We should manage expectation that it will have the same properties as the new standards. George suggested that users swim upstream. They can use the original tool to create the same graphic in a different file format.
Ka said that even with pdfs, if we were to include them because of fixed layout, the tactile artist would have to adjust things for a different display. By that point, it takes a lot of time. That could be problematic as well.
Avneesh suggested that we check with device manufacturers and ask about how pdf is supported on their braille displays. One way of using pdf is supporting eBraille content, other is using pdf as an image. We cannot have pdf in tags, but you can have a link to a pdf. If the device can support it, we can link to pdfs. This would make it simple to support legacy content and could be implemented for other document types.
William shared that on APH’s Monarch, there is already support because APH is using the Tactile Graphic Image Library for early graphic testing. The one problem they are running into is being able to recognize the braille as text so the device can support different levels of zooming. The Monarch currently supports an overview view, which allows you to take in entire graphic, and a size view, which is what the image was made for. Braille support is built in. The user does not have to know it is text for the device to render as is. It would be good to know what other multiline braille manufacturers have to say.
Pros: There is a text element. It can be hand-coded to include text. It can at least identify text versus an image. They can have clickable links. There is an SVG element in HTML; could use or tags. SVG tag could potentially allow for more options. SVG uses lossless compression – this means after a file is compressed, it can be uncompressed without losing any data. It uses vector graphics. Since they can be hand-coded, it is easier to make these accessible. Accessible SVG editors.
Cons: Requires additional processing power
Danielle shared that SVG has description tags which can be used to identify different elements. Tags can be used judiciously to help with nonvisual awareness of elements. SVG is not ideal for every blind content creator, but it is at least better than other file types! Danielle has been experimenting with using conversation AI to create SVG tactile graphics. She provided specific criteria to GPT4.0 which then generated an SVG of a stegosaurus. These can be scaled up and filled differently. SVG has lots of pros for blind content creators!
Ka said that for him, SVG is very helpful. As he experiments with code, he can send the graphic to an embosser then go back into code and fix things. Beyond notepad, there is an accessible SVG editor. His priorities are being able to add text and description elements so that even on a touchscreen, the user can slide their finger around and hear the tags have been added. Ka or William will find out the name of this accessible editor.
Danielle stated SVG can be used with Adobe Illustrator (thought code hygiene is not great); hand coding is not the only option. SVG can be put into devices like Cricut Maker and Silhouette Cameo. Danielle likes how open it is and can be used in different tactile forms. SVG also renders well on braille displays.
George recalled Doug Sheeper advocated for SVG. George could arrange to get him on the call. He also offered to contact Volker Sorge from his web end and publishing community group. Volker has developed accessible chemistry TGs using SVG that allow you to navigate molecules and diagrams.
Dan shared that he is working on an audio touch device with Doug and Volker. It is based on SVG with multi-layers to sonify and include data metatag. Everything is available, WAV files, text can be displayed, up to 20 layers. SVG is a must have in his opinion.
George clarified that we could have an SVG file as a standalone item and then with HTML, it could be embedded in text document or with an tag. He thinks the most common way we would want to use this is through
tag element, which gives you alt text. This provides all the same benefits as an image.
Avneesh added that we should document processing requirement for SVG. Since it is XML based, it needs processing power. We should do this to manage expectations.
Danielle recalled that APH’s Graffiti used SVGs. A lot of folks are trying to make sure SVG is included, but we also need to make sure we talk about good alt text! While she does not believe this is a con for SVG, Danielle suggested we need to be conscientious about how we put resources out about those things. William proposed we can require alt text and extended descriptions. While we cannot control quality, we can put out guidelines including links to resources that teach how to write good alt text.
Svetlana said she would vote for SVG, and William remarked there is a lot of excitement around the file type.
Pros: Lossless compression; traditional file type; uses image tags in HTML
Cons: Can only do images of text; only does raster graphics
William explained there are two different types of PNG, PNG 8 and PNG 24. The distinctions are mostly about color (24 has a larger file size). William said that although he is not sure we need the colors from 24, one advantage is different levels of transparency (unlike with PNG 8). That could be used to depict multi-height graphics. Since it is a traditional file type, we wouldn’t have to do anything special for it.
Steve voiced his endorsement of using opacity for height. That is something he currently does.
Ka suggested it would still be worth supporting PNG or JPEG. They are more limited than SVG but more useful in a publishing context. From a publishing standpoint, we should think about a fixed layout file type and having some support for that.
William proposed supporting SVG primarily and supporting PNG and another file type as a fallback. Dan replied that if you use PNG files, we won’t get real braille. PNG does not allow the user to make a braille layer. We don’t want to move braille dots around to avoid collisions like you do graphic dots. Fixed graphic formats in PNG and JPEG, especially labeled diagrams, are tricky to backwards engineer, even with graphic artist or AI William responded that this is something we would want in the metadata. This would make it easier for users to seek out SVGs. This could be a place to let the market decide, but we should also have PNG support available for lower powered devices that won’t have the processing power for complicated file types.
Ka explained that when his team is looking at fixed image layouts, they have found it very difficult to take a complex illustration and remediate it. At his organization, when they talk to graphic artists and introduce them to good design for TGs, they ask them to start from scratch or do an outline of a drawing and fill it in that way.
Pros: IPTC metadata; JPEG can hold a large amount of metadata, including accessibility descriptions
Cons: This can introduce artifacts; Not much advantage to using JPEG over PNG
Avneesh suggested we should decide whether to support raster graphics or not.
William replied they haven’t had any rendering issues on Monarch EXCEPT with braille, which he says is obvious. The braille is an image, so as the user zooms, the text gets corrupted. But the Monarch has been great for different levels of zooming! One of the cool experiences has been a tactile graphic of the Eiffel tower. The user can zoom in to see the way the beams are arranged. It is a neat way to use a dynamic tactile graphic. William will email Vinkatesh and Schleppenbach to ask opinions about their multiline braille displays.
William asked if anyone in the group knew of any other device manufacturers and asked if they could reach out. Danielle is going to see a new display coming out of Ann Arbor. She will ask them and send to the mailing list.
Pros: PRNs in TG library are much less complex than pdfs; No ambiguity in graphic output; No limit to complexity
Cons: It provides instructions for a printer which tend to be specific to printer they were made for.
While this is not a common file type for tactile graphics, it is used occasionally. File type tends to be used for simpler graphics.
Dan said that since PRNs are Tiger-based, they were never really meant to be open. They have the exact code for the printer so there would be no ambiguity what you would get. There is no limit to the complexity though. You can capture anything in a PRN file that you can emboss. Just a capture of the instruction set sent to the printer from the printer driver. It isn’t an open standard, and it isn’t portable, so he would not recommend it.
Pros: Can integrate braille and TGs
Cons: Proprietary file type
Dan asked, “Are you trying to integrate braille and tactile graphics? How do bring all those things together to see how they would look like or to put them into one flowing document?” At his organization, they use docx as a starting point for transcription. They fall back on doc instead of docx (XML based). They can be used interchangeably, but their output is more often doc than docx (docx is more proprietary)
William suggested we might want to stay away from proprietary file types.
Dan suggested that this is a good solution if we are trying to find something other than SVG that allows you to combine multiple elements in one file and be treated as a graphic. Docx can do a lot and fits within HTML5, and it works on virtual devices as well. But he still recommends SVG because it is an open file type.
Pros: Simple animations and interactive tactile graphics
Cons: Refresh rates on displays may not support this
These tend to be used for animation, but it can be used for static images as well. The possibility of using it for animation interested William. While users would not want to make truly animated TGs, it could be used to make a more interactive TG. We could potentially have each slide of animation be a different aspect of TG. For example, there might be a map, then next slide has info about one region, then next slide has different information.
Ka agreed the GIF would be very interesting. He pointed out that refresh rate on lots of devices couldn’t support complicated animations, but it would be useful to see how a bouncing ball might be rendered. In New York with Danielle, they had an instructor who showed them the breakdown of a bouncing ball animation. Being able to see it move would make it more interesting.
William will post his notes as a ticket on the Github project and then share link through both mailing lists (TG and main group). He invited all to chime in through ticket or email in hopes that by next meeting, we can settle on a file type.
Attendees: Ashley Nashleanas, George Kerscher, Venkatesh, Dan Gardner, Andrew Flatres, Avneesh Singh, Danielle Montour, Michael Ryan Hunsaker, Sarah Bradley, Susan Osterhaus, Svetlana Vasilyeva, Tkáčik Michal, and William Freeman
William introduces the goals. He mentions that we shouldn't hold our feature list to what is currently possible. We should shoot for the moon. We can figure out later what is possible.
Michael agrees that the goals are adequate.
Venkatesh feels that two file types might be too limiting. He mentions that there are about half a dozen possible file types. Andrew agrees that two is very limited but we need to focus ourselves. He mentions PDFs are a common file type in the US. Ashley asks, are their places where we want to involve other people and how would we want to involve other people? Are there things that could be maybe things that the main group could do but because they are doing their job, that it might be necessary to have other people step in. Who besides the main group and at what points in time should they be involved. It is agreed that this is a good point and that we probably should think about how other experts may be able to assist our efforts as we approach each piece.
William suggests we recommend two as a minimum and then any additional file types could be included as optional with reasons for why they are recommended.
Michael talks about how SVG is easy to zoom and its possible to resize while keeping the braille in the correct location.
William mentions how we can't forget paper too. Could a graphic be resized for a different size of paper or represented in a different way. Dan comments on this to say that they don't tend to worry about the file type. The easiest one for Dan to mix it all is Word (DOCX) and he questions who would want to support DOCX as an open format.
William recommends changing from "at least" to "a minimum" and the group generally agrees so the change is made.
Discussion then moves to timelines as no one has anything that they would like to add. We need to establish what we want first and then our recommendations are two parts of the same piece and
George mentions that image share has a couple thousands and that we could grab some examples from there. Venkatesh mentions the TGIL, and that they have PDF and PRN and those could serve as examples. He then adds web content points the way that a lot of the source of graphics could be, and trying to collect samples is a good idea. William asks Michael about what SVG graphics he has seen. Michael says it is easy enough to take a PRN and turn it into an SVG. But the challenge will be what is actually indicative of what is being used, like a map versus a bar graph or an image of an animal.
Danielle mentions that they have a braille and talking book library and they have a wide range of production methods for graphics and hand coding graphics and that coding hygiene going into something like Illustrator is not great. And she suggests that we might want to bookmark that since the end result will look good but the backend will be ugly. They have some SVGs that they have handmade, and she could share those. Illustrator to SVG conversions are really ugly and are hard to edit manually. George mentions how having clean files is good and you run into the same thing going from Word to EPUB and the files look clean unlike what you can get going. Maybe we could recommend tools that give good clean code.
Dan says setting the standard of objects that you can put labels on or keeping text as text instead of keeping it as a bunch of arcs. More than the file type is the method of what is inside the file. Having access to insertables will be very important and will be necessary.
George asks is there an authoring tool that does a good job of providing good code?
William says this sounds like another goal? What authoring tools exist, how are they being used, what features exist, and what is actually being used? Dan says that any tool could be taught to do what we need, so it's a chicken and egg thing.
Susan says the three transcribers on the BANA Tactile Graphics Committee use Corel Draw but that some don't have access to that. The rest, teachers and such, that tends to not be available and they would use something.
Danielle adds too that financial accessibility and accessibility to folks that are blind.
Dan adds that there is this group using Corel Draw but then there are also Adobe Illustrator, used at San Francisco Lighthouse.
William ask if considering authoring tools as one of our goals.
Avneesh says that we need to recommend file types to the main committee, and that we need to have the basic features and which are being met by main file types and which have the broadest implementation both in reading and authoring, and the second channel is more of a horizon what are the more exciting features that we want to have and advance the format. He suggests start from the first channel and then pursue the second channel.
George asks why not just copy what the EPUB standard currently support, which is SVG, JPG, PNG, and WEBP (?), a new file format that is like PNG but a little smaller? Avneesh asks are the multiline displays and embossers supporting these? Are there ways to make these file types?
Avneesh also adds that mapping all of this to EPUB because the EPUB reading system is based on browsers, so reading devices do not have to do much but this could be complicated for multiline and embosser software. George says that we're going to have to make sure that we can convert those formats into whatever we identify as the target format because the requirement to convert existing content into this file format. So if we can convert JPG into SVG, which is done all the time.
Andrew asks, what are the most known file types that are being used today? Andrew says PDF and worries if we're not including PDF in the MVP then we're maybe going in the wrong direction.
Michael says he sees a lot of PDF because you can use it with different thermoforms or VP embossers very efficiently to get an embossed tactile graphic. After that it is the Tiger Software Suite in Word and some have started using Firebird with the PageBlaster. He thinks to some extent we reinvent the wheel rather than seeking out what already exists.
Michal says they use SVG, with QuickTac, import into Duxbury, and then reproducing with high-capacity embossers. He says swelling paper is not good for adults. If we want to speak only about the dot graphics, he doesn't know how well a graphic for swelling paper can be recoded into a dot graphic.
Danielle says that at the library is that they will print SVG and then run that swell paper through the PIAF.
Svetlana says they use SVG and PRN.
Susan says some of her work she mainly use PDF and they use that on swell touch or PIAF or DOCX that they can use on a Tiger embosser. BANA Guidelines address font size and most of the guidelines are for swell-touch paper or tiger graphics.
Venkatesh's perspective from a consumer, says he sees a lot of JPGs. Svetlana agrees on seeing a lot of JPG. Dan says he struggles with JPG because it is pre-flattened and says you have to import it to cover up or make any changes and that he prefers getting something else.
Venkatesh also mentions formal or professional producers versus more casual creators and picked up pictures from the web and tried to put it into a document and they will take whatever there is and being able to accommodate that kind of use case. Dan also asks about proprietary file types. What do you do with those?
Michal asks about JPG, PDF, SVG, are we talking only about graphics that are made of dots? Or are we talking lines? He wants to make sure we don't forget about dots. Dan thinks any of these file formats are all in standard lines if you want to hand place the dots, the lower level tools are more likely and lower level file formats. Only TactileView lets you go down to the dot level depending on what file type you are using.
William mentions that we generally agree on the goals.
Dan asks do we foresee having the tactile graphics bundled with the eBraille format? William says yes. And so Dan says that we then need to make sure that the graphic file needs to fit into that file type. George says yes but all the other file formats are already supported but he's not sure about PDF. Dan mentions how PDF is typically a full page and the braille file has blank space.
The meeting then concludes with an agreement to continue the discussion on the mailing list.
- Understand what features we would like to see in the eBraille specification when it comes to tactile graphics.
- Recommend a minimum of two file types for inclusion in eBraille based on the highest priority features and what is technically feasible. Be informed about what authoring tools are already available and being used and use the information in our recommendation.
- Recommend how those file types could be included in eBraille and what metadata and features should be considered for the initial eBraille specification.
- Collect and create samples of tactile graphics in the recommended file types and, if we’re technically capable of it, include examples of the features we are recommending.
Next meeting will be on April 4th, 2023.
- There is a need to have labels on graphics
- Metadata would be helpful, either as part of a graphic file or the EBRF (information about a specific country on a map, etc.). This would also be useful with tactile graphics being paired with audio
- If the device doesn’t support metadata activity, it would be on the device to process that correctly
- We are likely to have students with little or no access to digital braille; metadata and interactive elements need to be able to be disabled to emboss to hard copy. This responsibility falls on the braille transcription software to ignore the nonapplicable features. We could, for example, have this show as embossing alt text or not.
- The file type will need to be created with enough care for developers to use features correctly. Alt text will need to be consistently and accurately labeled, as an example.
- References to other resources and the ability to embed tags and specific element descriptions would be best modeled in SVG file types, but we haven’t yet discussed file types.
- Specifying interactive graphics representation is important. It also needs to expand to the entirety of EBRF
- Tactile graphics task force could meet, make initial suggestions, then disband before reconvening as problems arise
- Recommend two graphics file types to be included in an EBRF: one being used now and an ideal for the future
- Create and collect samples that could be used for testing
- Establish methodology around creating tactile graphics: framework for how they are made, etc.
- Interactivity is featuring strongly here, both for graphics and EBRF files. We will need to figure out how interactivity works in graphics specifically and as graphics work as part of the EBRF discussion.
- Prioritize working prototype. Specifically, build onto simpler concepts as first steps
- Figure out which file types allow for levels of interactivity being discussed
Deadline for use cases is February 14
- Interactive graphics
- Multiple dot heights
- Labels on graphics
- Alt text and extended descriptions
- Keys for graphics
- Distance marks
- Non-embossed media: PIAF/microcapsule paper, Cricut machines, etc.
Discuss the following on the email list:
- Determine timeline and goals with a deadline of before the March meeting
- Continue interactivity discussion
- What metadata should be included in the file?
Attendees: George Kerscher, Steve Landau, Ashley Nashleanas, Avneesh Singh, Dan Gardener, Danielle Montour, Ka, Mike Paciello, Nicole Gaines, and Susan Osterhaus
- Housekeeping:
- Remember to say name before speaking
- Co-chairs, Mike Paciello and Danielle Montour
- Review Problem Statement
- Use Cases
- Next meeting
William reads the draft problem statement and there are no major points but discussion does start on the idea of 3D models and how those might be included in the draft.
Two points from George, should we make a statement developing it so it works with new generation of tactile graphic devices. Even though we mention the old ones. That would eliminate 3D models, you can't emboss a 3D model. Wondering if that scope, that we're targeting those is something important to state here.
Danielle asks about if it's implied already that 3D models aren't included.
George says we might want to reference a 3D model for external printing. Here's a tactile graphic of this molecule and a reference of a 3D model.
Dan agrees it. One tactile graphic could have 4 or 5 different options. Having a 3D model too could be reasonable.
George mentions the Diagrammer project and folks should check that out. And what we have is an XML method of identifying a tactile graphic in all of its various incarnations. Whether 2D, 3D, descriptions, audio, 2 1/2D and then those graphics are produced and put in a database like ImageShare project. We need to identify what is most appropriate for
Ka thinks 3D models would be out of scope for the moment but could be worth thinking about it. Could be useful to display the CAD file in a viewer and all of its parts from different angles.
Mike mentions 3D modeling and braille and how Pearson has thought about them. Wants to acknowledge the ideas that have been brought out are useful, but thinks there is a preference for 3D models on refreshable devices in the future. Not just as 2D but maintained as 3D models.
Ka and Danielle thinks that this ability to view graphics from multiple angles is useful.
William mentions that while he doesn't want to focus too much on just the refreshable devices and wants to make sure we include embossers. Thinks embossers will continue to be useful in the future and the file type should work with them.
Steve Landau talks about the work he has done with Chancey Fleet and they are trying to create a more iterative tool that allows people to design their own graphics and use the SVG description tag and have the ability to emboss multiple copies iteratively and place it on a T3 tactile tablet, which is their audio tactile graphic platform. A way to use this new file type for that purpose, so that we can editing code in a text editor but with this system to very quickly iterate and throw away the intermeditate versions.
Steve mentions they are making an open source tool and business model is to sell devices and paper. Software is free.
Dan talks about how they are working on software that also does audio with tactile graphics and working with EPI on
ViewPlus is using SVG and they have a license key when generated on their authoring system, it's based on SVG and the new versions are open source.
George brings up topic of scope. Would a touch screen with a print overlay be one of the representations that we should support here.
William mentions that we're not as concerned with how the file is created but we do need to be aware of what features are being used and how those features are included in the file. That way we can include a means to make the most of that in our file type.
Dan asks about DRM. Will that be included in eBraille? William mentions that we talked very little about that in the main group but it was a weak argument for braille encoding first. Dan wonders what other publishers think about this question. Often they don't own the copyright to their own graphics.
George talks about his experience here and thinks we should produce content that is DRM-free, there's authoring tools, reading systems, and if somebody needs to apply protection then there's more than one way for them to do that. Bookshare and NLS are good examples of this. NLS uses strong encryption while Bookshare does fingerprinting, watermarking.
From the use cases, we then decide on the MVP. Don't start with the file type, start with what is needed and then we'll decide how to solve that problem.
William mentions putting in a use case for handling traditional image types that are already covered by xHTML and also a use case for file types that aren't covered by xHTML already (like PDF).
George mentions the need to make sure that folks are following through so that real work can get done in between meetings. William mentions he's been pretty lax about requiring anything from anyone since everyone is volunteering. Right now has been a slow period because of so many people being on holiday and is hoping that work will pick up as folks are coming back. Mike volunteers to review the notes and send out action items after the meeting.
The next meeting is scheduled for February 7th at the same time and it is agreed that we will meet again on March 7th at the same time.
- William will email notes to the group and post on GitHub. He will also send the problem statement to the email list so that folks can review it there if not on GitHub.
- Mike will review the notes and look for action items and send to list.
- George will make a use case for 3D renderings.
- Dan and Steve will work on a use case for the audio portion
- Danielle and Ka will work on a use for CAD files as it relates to 2D renderings.
- Andrew Flatres, Braille Product Manager, HumanWare
- Venkatesh Chari, President and CEO, Orbit Research
- Ka Li, Accessibility Analyst, NNELS
- Danielle Montour, APH Customer Service
- Leona Holloway, PHD Student in Graphics and Accessibility and Braille Transcriber
- Svetlana Vasilyeva, Lead Assistive Technology Specialist, Elita Group
- Tina Herzberg, professor and coordinator University of South Carolina Upstate
- Mike Paciello, Director, Accessibility Implementation Pearson
- Avneesh Singh, COO DAISY
- Tkáčik Michal, coordinator for Braille Authority of Slovakia
- Susan Osterhaus, statewide mathematics consultant for TSBVI, also on BANA tactile graphics committee
- George Kerscher, Chief Innovations Officer, DAISY
- Dan Gardener, CEO, ViewPlus
- William Freeman, APH Tactile Technology Product Manager
What files type(s) will we support? How will we support them?
William and Mike agree to be co-chairs. After the meeting, Danielle also volunteers to co-chair with William and Mike.
File types have to support a certain number of features- metadata, ability to link to audio and to other documents, embossing and display on a tactile display, and other features to be determined
Mike- all of that is in the context of what file types to support.
Avneesh- two main pieces, MVP, should get MVP in one year or 1 1/2 year. Support all various files types or can the first file type be simpler and be converted SVG? A Matrix of dots, then a low powered device can handle it in an easy way
Which are the formats that these devices can use directly? What we are doing in this taskforce is dependent on the reading devices. We need to know what capabilities are being developed and then work to include that in our efforts.
Important to define the use cases and features that we want.
How do existing standards fit into the picture? Avneesh recommends examining those standards. George thinks we inherit some principles from the larger ebraille group and that problem statement, talks about using existing standards. Do we need a stated goal that says we will stick to existing standards?
Tina, looking at the technology that exists and which ones will support this new file type. What kind of work must be done to work with what people already have. Also, there needs to be training.
William mentions how APH is already working on making sure people are aware of our efforts and will help with training. We'll also need to work with developers and manufacturers to ensure they are trained to implement the new file and able to communicate with their customers about it. It would be a waste if we develop a standard and no one is able to use it and/or doesn't know how to use it.
Use cases will be labeled using the tactile graphics label created in GitHub. Folks can start putting in use cases after the meeting. William offers to meet with anyone that needs training on using GitHub.
William will create a rough draft of a tactile graphics problem statement and post it on GitHub for review. It will need to be reviewed and edited by members of the taskforce and will serve as a starting point. He'll share it with co-chairs for their review before posting.
Next meeting will be 3 January at 15:00 UTC. Meeting after that will be 7 February at 15:00 UTC and then we'll schedule future meetings similarly to the main group (two at a time with option to change regular date/time and add more monthly meetings as needed)