Re: Help needed: EPUB 3.01 revision referencing a11y metadata spec

Hi George:

On Sat, Aug 31, 2013 at 11:14:59AM -0600, George Kerscher wrote:
> Dear folks,
> We need some help here. The proposal at:
> Is under consideration by  the International Digital Publishing Forum
> (IDPF)'s working group for inclusion in the EPUB 3.01 revision that is
> quickly working towards ISO approval as a Technical Specification.
> It would be terrific if this could reach a status in the next few weeks to
> make it into this spec. EPUB 3 references HTML5 and other specifications
> that are not full W3C recommendations, but a status of accepted public draft
> or better is necessary for inclusion in the spec.
> If somehow we could get the accessibility metadata spec to this state, I
> would appreciate it.
> >From my POV, having this type of metadata in the package file for each EPUB
> 3 publication  would go a long, long way in promoting digital publications
> that are accessible to persons with disabilities.

Thanks for this! I do have a few suggestions for the draft proposal as
it currently stands that I believe would improve its usability and the
ease of maintenance over the long term.

Change "Text" to new Enumerations
In general, those properties with an expected type of "Text" that
have a list of expected values (such as accessMode, mediaFeature,
accessHazard, accessAPI, and controlFlexibility) should be redefined to have
new enumerations as their expected type. And, ideally, the valid values
for those new enumerations would be maintained externally (perhaps by
the IMS Global Learning Consortium itself). I'm not the first to mention
a concern over how these values will be maintained going forward, but I
firmly believe that delegating this responsibility to an external entity
with expertise in the area is the best plan for long-term success.

For an existing example in, the type
has the property, which in turn has
an expected value of - an enumeration
that points to the Good Relations vocabulary for its valid set of values.

Rename "ATCompatible"
Whether it continues to be defined as a Boolean or it evolves into an
enumeration, "ATCompatible" is an extremely opaque property name.
Despite the additional length, I think it would be helpful to spell
it out as assistiveTechnologyCompatible (or accessTechnologyCompatible,
or accessTechnology if it evolves into an enumeration).

Adopt standard "access" prefix
I believe that implementers of would benefit from having
the accessibility properties co-located as much as possible in the documentation, and therefore would recommend that the new
primarily accessibility-oriented properties be renamed with "access" as
a standard prefix; for example:

* accessMode
* mediaFeature -> accessMediaFeature (or just accessFeature?)
* ATCompatible -> accessTechnologyCompatible (or just accessTechnology?)
* accessHazard
* accessAPI
* controlFlexibility -> accessControlFlexibility (or just accessControl?)

Dan Scott

Received on Friday, 6 September 2013 13:41:55 UTC