W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2013

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

From: Dan Scott <dan@coffeecode.net>
Date: Fri, 6 Sep 2013 09:41:24 -0400
To: George Kerscher <kerscher@montana.com>
Cc: public-vocabs@w3.org, Gerardo Capiel <gerardoc@benetech.org>, Matt Garrish <matt.garrish@bell.net>
Message-ID: <20130906134122.GA15551@denials>
Hi George:

On Sat, Aug 31, 2013 at 11:14:59AM -0600, George Kerscher wrote:
> Dear schema.org folks,
> 
> We need some help here. The proposal at:
> http://www.w3.org/wiki/WebSchemas/Accessibility
> 
> 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 schema.org, the http://schema.org/Offer type
has the http://schema.org/businessFunction property, which in turn has
an expected value of http://schema.org/BusinessFunction - 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 schema.org would benefit from having
the accessibility properties co-located as much as possible in the
schema.org 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?)

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:30 UTC