Attendance: Put a "*" next to you name when you join
Andy Heath (M,T)
Madeleine Rothberg (M,T)
Liddy Nevile (M,T)
Charles Myers (M,T)
Anastasia Cheetham (M,T)
Chaals Nevile (M, T)
We had a full hour-long session on both days, and we discussed accessHazard on the first day with conclusions and a more diffuse discussion on mediaFeature which was inconclusive and will continue the nest week.
- AccessHazard should have a way to assert that an item does not have the access hazards present. The decision was to create three negative assertions to match the positive assertion. All three of the negative properties should be set if there are not any of the hazards known to date. If not properties are set, the state of accessHazards is unknown, rather than no hazard. The details of this can be found in the issue tracker.
- Currently, accessHazard defines positively. The resolution is that we have negative assertions that match the positive assertions. and not a "none"
- The reasoning is that the maths works out better: 10% of content marked correctly as having hazard if it does means there is a 90% chance of hitting a hazard.
- We had a brief discussion on whether making assertions on the quality of the accessible content was in scope. We concluded that it was not.
- We briefly discussed having a visualTransformFeature of "simplifyFormatting" and gave it some consideration. As I went to edit the content, I could not see a good place to put this in (it seemed to be more an attribute of the reading system rather than the content).
- The following information was suggested to people before participating in the call. I've left it here in the minutes for future reference.
- For this discussion, I recommend that people watch http://www.a11ymetadata.org/accessibility-metadata-in-action-at-teachers-domain/ beforehand
- Two examples of the google custom search engine at http://www.a11ymetadata.org/bookshare-tags-over-195000-titles-with-accessibility-metadata/ and for tactile graphics at http://www.a11ymetadata.org/the-specification/live-examples/rnib-tactile-graphic-library/
- mediaFeature was viewed as being a large confusing set of properties. After the Monday call, we created a set of properties and values that broke these down by accessMode and the type of adpatation/feature, whether
- a transform (the ability to change the appearance or presentation of content without intellectual effort and without changing the accessMode)
- a content adapatation, which requires intellectual effort to make content in one access mode available in another (captions are a good example of this)
- Charles McN observed that some properties that we had, such as displayTransformability, may be technically correct, but are not in the terms that normal users understand. Anastasia added onto this that many users, especially the elderly, specifically look for things like largePrint, with a page that is set this way it is CSS. The fact that they can tailor their CSS to achieve this same end is beyond their reach.
- With this set of proposals, see the w3C wiki issue tracker, we had a long discussion on visualTransformFeatures, which also rolled into a discussion of textualTransformFeatures, as they are closely aligned (the former is for printed books and rendered content, the latter is for electronic content that is more malleable).
While I was reading up on largePrint, I found some good resources for the definition. I'm copying these below for the record. I'll note that the National Association for the Visually Handicapped has clear guidelines for large print. These are (going from wikipedia)
- Maximum limits on size, thickness, and weight
- Minimum limits on margins
- Type size at least 16 point, preferably 18 point (California education standards are 20 point for K-8)
- Sans serif or modified serif font recommended
We discussed three use cases as the basic types (the sensory modes change the story, but the story is the same)
There are three use cases below
- a person looking for a specific media type (video) with a mediaFeature (caption) - media type+mediaFeature does the job well
- a person driving in a car who can only work with audio content or content that can be expressed in audio - needs accessMode to easily determine useful content
- a teacher who is leading a class, where some of the students have disabilities. They would like to find resources for the class, finding, if possible, the best resources that can be used by the most students - another case for accessMode
- are there more?
- When a book is made available, it may be available with different accessModes and mediaFeatures (the current bookshare is a very good example... a book can be available in braille (brf), Daisy with images, Daisy w/o images and Daisy Audio, all as adaptations of the source book
- When a book is available on O'Reilly or Amazon, it may be available in a few formats from the offering page (paper, epub, mobi, pdf), hardbound, paperback, audioCD or AudioService (Audible). Sometimes these are available for access directly from the page (O'Reilly). Other cases (Amazon), has links over to that page.