Minutes from the Novermebr 5, 2013 Accessibility Metadata Working Group call

[Charles Myers]

We had another action-packed working group call yesterday, with a set of tweaks and name changes applied to the properties and values. We also have taken greater advantage of the extension mechanism on property values to keep the vocabulary smaller and more manageable.

 

I've copied the notes below, and they are available on our wiki.  See https://wiki.benetech.org/display/a11ymetadata/Minutes+11-05-2013

Note that these minutes are the union of October 29 and November 5, as we reviewed and refined October 29 minutes in this meeting.

 

The next steps are that I'll be editing this into the next version of the specification in the next few days. Be on the lookout for more announcements.

 

November 05, 2013 9:00 AM PDT

Minutes

Andy Heath
Liddy Nevile
Charles Myers
Anastasia Cheetham
Madeleine Rothberg
Gerardo Capiel

Review of Conclusions from previous October 29 call

We reviewed the conclusions from the last call (since we added Gerardo and Madeliene to the call), all revolving around coming to a conclusion and consensus on mediaFeature. There was great backing for this from eduPub, as there was a serious desire to add this metadata into the epub specification. Also, Gerardo and Markus Gylling will be meeting with Charles McN at the W3C Tech Plenary in hopes of making some significant progress on this.

I am copying the status from the last call (so that there is one place where all the changes are listed), but adding the new conclusions or changes in bold. These minutes supercede those from the October 29 call. The topics were

• displayTransformability: we agreed to let this stand, with the value of at least CSS. However, most of the user-understandable names are broken out seperately (largePrint, highContract, resizeText). displayTransformability stands alone; specifiying it does not imply any of these three more specific properties.
• largePrint, highContrast, resizeableText: besides specific pointsizes for large print (e.g., mediaFeature="largePrint/16") and specific color combinations for highContrast, the extension /CSSEnabled can be used to say that the document has been set up for flexibility in those areas through CSS. If other flexibility schemes are found in the future and used, there can be other /XYZEnabled.  But since we don't know what those others are, we decided to be explicit with how this flexibility was enabled now.
• Andy suggested that the most important thing was to agree on a common data model such that if the Metadata were to include suggested usage relationships between modalities that could be used accessibly in the view of the metadata author then that usage information should be presented separately from the access modalities physically present in the resources. This would enable information both approaches to be used entirely separately without making description of the accessModes present more complex than it need be.
• We had a long discussion about mediaFeature and the names of the divisions of this attribute. We considered four different choices, with an overall view that the names would be short if the design of the metadata structure was right. The choices were
  1. mediaFeature (within access mode), mediaAugmentation (cross access mode)
  2. mediaFeature (within access mode), accessFeature (cross access mode)
  3. accessFeature as the new name for all three classes, and we describe them in sets
  4. mediaFeature as the old name for all three classes, and we describe them in sets
• On November 5, we decided to rename the property to be accessFeature. The dominant reason for this is that it puts it closer to accessMode and accessHazard in schema.org, which is a great boon. Choice #3 won out. We did, however, all seem to have some degree of affinity to accessFeature, which may have been its original name before the change to mediaFeature. I'll add this to the agenda for the next meeting, but it's going to be a simple up/down discussion (I'll note that we started as "hasFeature," then moved to "adaptationFeature" and then settled on "mediaFeature"). The good news is that the suggestion of accessFeature IS a new one, but I'd be willing to say that this will be the last time we ever change.
• We concluded that haptic, as an access mode, was actually a refinement of tactile, and was not a mediaFeature. It's being moved up to this new place as an extension, e.g., tactile/haptic
• We discussed enhancedAudio and decided that it, and the three attributes were good and should be adopted. Note that the basic concepts come from WCAG 2.0 section 1.4
  • /noBackground
  • /reducedBackground (the WCAG concept 20 dB)
  • /switchableBackground (the WCAG concept "turn off")

Note that the issue tracker on the w3c wiki has been updated with the Simplified View of mediaFeature.  On November 5, we decided that these changes have reached a point where we should declare the next version (V.6) of the specification and make it known publicly. That editorial work will happen over the next few days and will be published before the weekend.

There is NO call scheduled for November 12. We may have open calls on Wednesday and Thursday this week to prepare/refine our content for the meetings in China next week. The schedule is open at this point.

New issues on mediaFeature/ accessmode refinements and other properties

• The proposal floated in the last meeting of /alternativeImage was decided against. In its place, we're going back to
  • signLanguage as a property value, which can be followed by the language code. This is always, of course, a visual property
  • The concept that had been floated for treating an open caption as alternative Image was nixed, as it was a bit too esoteric. Instead, we decided that there would always be the property value of captions, which could have two extensions, /text (for ones that were done as plaintext that could be presented in multiple forms and processed in a variety of ways) and /visual (for ones that were burned into the video visual presentation). If no extension was present, it is assumed that it would be captions/visual, as this is how most people think of captions.
• We reviewed Liddy's contributions in the spreadsheet and the proposed new properties that could be added under accessFeature. These were discussed, but not acted upon, as there were open items on all of them
  • imageSize (fixed or variable) - Charles N (screen size, reflowable, interaction) certain resources can't really be scaled... would like a reference). Gerardo will talk to Charles N in China. This can be added, but it would be great to have a WCAG or WAI-ARIA reference to base this on.
  • A number of enhancedAudio features were discussed. Our conclusion was that we did not have an audio/auditory expert on the team and nobody has stepped up yet. Many of these new proposed property values seem closer to being attributes of the audio itself (which may lend to more or less accessibility for different users) that enhancements for accessibility). (Note that we did decided that the enhancedAudio attribute proposed last week, based on WCAG 2.0 section 1.4 did make sense to move forward with)
    • tone: musicAlternative or toneDiscriminationAlternative as extensions
    • voice: voiceDiscriminationAlternative, selectedVoice or contrast as extensions
    • volume: loud or quiet as extensions, with the possibility of variable as a second level extension.
    • pitch: high, low or contrast as an extension
• Liddy also suggested a new property value for controlFlexibillity
  • timing is the new property value, which means that the timing is variable and can be altered/ stretched for interactive pages, which fall under softwareApplication.
  • We also discussed better names for controlFlexibility.
    • controlFlexibility - pro: more explicit: it's about how the control is flexible, not just how it can be controlled
    • control: pro: shorter, less verbose
    • accessControl: fits with other access properties
  • Gerardo will discuss this further with Charles McN in China, but we will be changing the name to accessControl and adding timing as a value now.
• We completed the discussion on whether whether the refinements of visual in accessMode should be "OnImage" or "OnVisual," referring to the access mode. We concluded that the change to OnVisual made more sense, so the specification will be updated for this.
• We also concluded that we could add new refinements as well, primarily to incoprprate the properties used in the DAPP project.
  • /diagramOnVisual
  • /chartOnVisual

Next items on the overall agenda

• ATCompatible
• accessControl and accessAPI 
• accessMode and the three proposals for the available access modes (this is a topic for a future call)
• is/hasAdaptation

Agreement on the basic use cases, for the record

While this was not discussed in this meeting (it was on 10/7&8), I have left this here so that we can continue the focus on this. 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.

[Dan Brickley]

+Cc: TV Raman

On 6 November 2013 14:41, Charles Myers <char...@benetech.org> wrote:
> We had another action-packed working group call yesterday, with a set of
> tweaks and name changes applied to the properties and values. We also have
> taken greater advantage of the extension mechanism on property values to
> keep the vocabulary smaller and more manageable.
>
> I've copied the notes below, and they are available on our wiki. See
> https://wiki.benetech.org/display/a11ymetadata/Minutes+11-05-2013
>
> Note that these minutes are the union of October 29 and November 5, as we
> reviewed and refined October 29 minutes in this meeting.
>
> The next steps are that I'll be editing this into the next version of the
> specification in the next few days. Be on the lookout for more
> announcements.

Sounds like you've been very busy! Will someone who is following this
closely be in a position to produce an updated version of the draft
RDFS configuration file we'll need for schema.org? If not, let me know
if you need help (presumably once the revised spec is out). The
current version I've drafted is at
https://dvcs.w3.org/hg/webschema/file/default/schema.org/ext/accessibility.html

Dan

[Liddy Nevile]

Danbri,

we are proposing a neat list of the properties we think are the best
and a graph of how they are related - both should be ready in the next
few days - and then, I guess, it'll be easy to write it up as
suggested...

Is this the right approach?

Liddy

[Liddy Nevile]

Dan,

your write-up is slightly outdated because we have decided that
accessFeature is a better name for the property than
mediaFeature...this aligns better with accessMode, we think... and we
have also accessHazard and accessControl, I think.

We have refinements of these, and for some we have controlled vocab
values - but I am assuming that these are not what you need now???
(below I have given the write-up a go...)

Liddy

On 07/11/2013, at 3:46 AM, Dan Brickley wrote:

>

> Sounds like you've been very busy! Will someone who is following this
> closely be in a position to produce an updated version of the draft
> RDFS configuration file we'll need for schema.org? If not, let me know
> if you need help (presumably once the revised spec is out). The
> current version I've drafted is at
> https://dvcs.w3.org/hg/webschema/file/default/schema.org/ext/accessibility.html
>
> Dan
>

1 <html>
2 <head>
3 <title>Accessibility vocab</title>
4 </head>
5 <body>
6
7 <div>
8 <h1>Accessibility Vocabulary</h1>
9 <p>See <a href="http://www.w3.org/wiki/WebSchemas/
Accessibility">wiki</a> and <a href="http://
a11ymetadata.org/">a11ymetadata.org</a> for details.</p>

10 <div typeof="rdf:Property" resource="http://schema.org/accessHazard">
11 <span property="rdfs:label">accessHazard</span>
12 <span property="rdfs:comment">A characteristic of the described
resource that is physiologically dangerous to some users.</span>
13 <span>Domain: <a href="http://schema.org/CreativeWork"
property="schema:domain">CreativeWork</a></span>
14 <span>Range: <a href="http://schema.org/Text"
property="schema:range">Text</a></span>
15 </div>

16 <div typeof="rdf:Property" resource="http://schema.org/
accessFeature">
17 <span property="rdfs:label">accessFeature</span>
18 <span property="rdfs:comment">Access features of the resource
commonly used as accessible alternatives, such as signLanguage (used
in visual assessMode).</span>
19 <span>Domain: <a href="http://schema.org/CreativeWork"
property="schema:domain">CreativeWork</a></span>
20 <span>Range: <a href="http://schema.org/Text"
property="schema:range">Text</a></span>
21 </div>

16 <div typeof="rdf:Property" resource="http://schema.org/accessMode">
17 <span property="rdfs:label">accessMode</span>
18 <span property="rdfs:comment">A set of sensory modalities through
which all the intellectual content of a described
resource or component is communicated, such as visual + auditory;
text; etc. </span>
19 <span>Domain: <a href="http://schema.org/CreativeWork"
property="schema:domain">CreativeWork</a></span>
20 <span>Range: <a href="http://schema.org/Text"
property="schema:range">Text</a></span>
21 </div>

16 <div typeof="rdf:Property" resource="http://schema.org/
accessControl">
17 <span property="rdfs:label">accessControl</span>
18 <span property="rdfs:comment">Content features of the resource,
such as fully controllable using only keyboard.</span>
19 <span>Domain: <a href="http://schema.org/CreativeWork"
property="schema:domain">CreativeWork</a></span>
20 <span>Range: <a href="http://schema.org/Text"
property="schema:range">Text</a></span>
21 </div>
22 </div>
23
24 </body></html>

[Madeleine Rothberg]

The group has not agreed to the changes in the definition of access mode
included here.

-Madeleine

>--
>You received this message because you are subscribed to the Google Groups
>"Accessibility Metadata Project" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to a11y-metadata-pr...@googlegroups.com.
>To post to this group, send email to
>a11y-metad...@googlegroups.com.
>For more options, visit https://groups.google.com/groups/opt_out.

[Liddy Nevile]

correct!

I have put in what Charles Nevile and I understand to be what is
wanted - and what he thinks will work (as far as I can tell) -

but didn't we discuss this and agree in a meeting last week? I do
remember checking it ...because I was not sure ...

I said something about it being a repeatable property but we had to
know that we could stop the sets being concatenated and Charles N said
that could be done with a 'blank node' .... and this was in email too...

Liddy

[Madeleine Rothberg]

I think (and I believe others agree) that this is a new field, computed from accessMode plus accessFeatures. The previous definition of accessMode should remain in place, and the new field you have suggested needs a more specific name.

Madeleine

[Matt Garrish]

I agree with Madeleine. This alteration makes it difficult to
understand/parse when an access mode has been inferred, or when it reflects
the actual nature of the content. For optimized discovery and rendition
selection from metadata in the epub package document, we were looking for
the unambiguous representation of the nature of the content that accessMode
was designed to give.

It also directly changes an IMS property without changing its name, which is
worrisome. Where we have changed properties previously (accessFeature
combining properties), we've used different names to avoid confusion.

The whole +'ing of access modes is also lacking any explanation in the given
definition, which doesn't seem helpful for someone trying to implement the
property.

Matt

[Liddy Nevile]

Now I understand what is causing the problem.

I am NOT inventing a new property --- I was simply organising the
accessFeatures so that by stating an accessFeature of interest, it
could quickly be seen what accessMode might be affected - ie doing
what Chuck was doing but not having so much text in order to do it. I
have changed the headings etc on the spreadhseets and think it might
be better now - please have a look at this new version of the
spreadsheets...

Liddy

[Andy Heath]

I agree with Madeleine and Matt. I can't type long arguments on this but they have been made many times and at this point are probably in my view a distraction of focus. There is certainly in my opinion a majority of the IMS AfA 3 contributors/editors in favour of maintaining the status quo on AccessMode, and knowing the views that Jutta has expressed I believe there is a majority of 24751 editors also. I propose we close the issue on changing AccessMode. That does not prevent discussion of additional fields for computed values or author-intended-uses at this or any later point.

Andy

Sent from my iPad

[Liddy Nevile]

Andy,

as I have not made a new property, I am not sure what you are agreeing
with - I also agree that there should not be a new one???? Did you
manage to look at what I have worked on?

Liddy

[Andy Heath]

On 07/11/2013 08:58, Liddy Nevile wrote:
> Andy,
>
> as I have not made a new property, I am not sure what you are agreeing
> with - I also agree that there should not be a new one???? Did you
> manage to look at what I have worked on?

Yes I have read your AccessMode proposal and made detailed arguments
about it explaining why I think AccessMode should remain as it is now
and represent modalities physically present without any calculus
relating those modalities in that field (but that such a calculus could
be in some other field with some other name).
I am agreeing with all of the detail in Madeleine's post in the quoted
text below and all of the detail in Matt's response to that, which is
also in the text below.
I agree with their arguments on this and have made very similar
arguments myself. I don't know how to make this point clearer without
again visiting the detailed proposal of yours and my belief is we did
that until the cows come home (in your case that's literally, being in
Oz in the night ) and I can't see a reason to do so again. I'm saying I
think its decision time and I believe there is a consensus about this
around keeping AccessMode as it is and not need for further debate which
will only muddy the waters more.

Hope that clarifies my position. The arguments I have put on it are in
earlier emails on this group.

andy

andy
andy...@axelrod.plus.com
--
__________________
Andy Heath
http://axelafa.com

[Dan Brickley]

On 7 November 2013 12:25, Andy Heath <andy...@axelrod.plus.com> wrote:
> On 07/11/2013 08:58, Liddy Nevile wrote:
>>
>> Andy,
>>
>> as I have not made a new property, I am not sure what you are agreeing
>> with - I also agree that there should not be a new one???? Did you
>> manage to look at what I have worked on?
>
>
> Yes I have read your AccessMode proposal and made detailed arguments about
> it explaining why I think AccessMode should remain as it is now and
> represent modalities physically present without any calculus relating those
> modalities in that field (but that such a calculus could be in some other
> field with some other name).
> I am agreeing with all of the detail in Madeleine's post in the quoted text
> below and all of the detail in Matt's response to that, which is also in the
> text below.
> I agree with their arguments on this and have made very similar arguments
> myself. I don't know how to make this point clearer without again visiting
> the detailed proposal of yours and my belief is we did that until the cows
> come home (in your case that's literally, being in Oz in the night ) and I
> can't see a reason to do so again. I'm saying I think its decision time and
> I believe there is a consensus about this around keeping AccessMode as it is
> and not need for further debate which will only muddy the waters more.

+1 on it being decision time. We don't need to put everything into
schema.org in one go, but it would be good to have a
roughly-consensual proposal for us to review next week. It's hard to
tell from this latest thread how close you are to agreeing...

Dan

[Madeleine Rothberg]

Liddy,

I am not disagreeing with your work on accessFeature. I agree that it would be useful to have a technical encoding of which accessModes each accessFeature contains and replaces. That is a separate topic. I do not think we will create that encoding in Schema, but we should create it somewhere.

I am disagreeing with the new definition you have written for accessMode. I, and the rest of the group, do not think it makes sense to re-define accessMode to require the metadata author to do the computation of the combinations of access modes possible for a resource and its alternatives. We all feel that accessMode should continue to be defined as it has been. I suggest that a new field could be added called "accessModeCombinations" (or some much better name) that has the definition you have given.

Some metadata authors may be capable of filling out the new field, but others will not. If authors correctly fill out accessMode and accessFeatures, an algorithm can deduce the values for the new field. As new resources are discovered that explicitly or serendipitously augment a resource, the number of ways to use it will grow, but the characteristics of the base resource will not change. 

-Madeleine

From: Liddy Nevile <li...@sunriseresearch.org>
Date: Thursday, November 7, 2013 12:16 AM
To: Matt Garrish <matt.g...@bell.net>
Cc: Madeleine Rothberg <madeleine...@wgbh.org>, Dan Brickley <dan...@google.com>, Charles Myers <char...@benetech.org>, "a11y-metad...@googlegroups.com" <a11y-metad...@googlegroups.com>, "public...@w3.org" <public...@w3.org>
Subject: Re: [a11y-metadata-project] Re: accessibility RDFS write-up

[Charles Myers]

Thanks for doing this content for Dan, Liddy.  It'd be great if you took on the other ones as well, especially accessAPI and the others.  We ought to have one RDFS source that reflects our current complete thought...  we can edit this as properties make it or not.  But I am truly grateful for this, as it was an editing task that I was looking at taking on myself.  Anything that goes off my list is goodness. 

As editor of the specification, I'd like to say a few things:

1. The  draft of the specification is at http://www.w3.org/wiki/WebSchemas/Accessibility (I'm proofreading it at the moment, but I have updated all the names, and added a section that explains accessFeature in more depth.  This is my first attempt at explaining the accessFeatures in a more cogent but still terse fashion.  Send me comments (or, better yet, editted text) and I'd be glad to have impromptu group calls if they are needed.
2. There seem to be multiple opinions on access mode, which are
1. It's the access mode of the non-augmented content (the traditional AfA method, and what we believe is called for in in epub3)
   
2. It's the set of access modes of the augmented content (what search engines would like to work from)
3. That we might want to specify which search engine access modes are NOT needed in the augmented content (this was a discussion off the list and did not pass muster from the off-the-list group to bring it forward)
   
4. That accessMode is a third rail.  Whether it causes electrocution or derailment is unclear, but neither of these are ends to aspire to.
   
3. I believe that the path on access mode is to keep it in here (the augmentation access features only make sense in that context, as well as the extensions for the access mode refinements)
4. Once we have agreement on 1-4 on the list below, we can tackle 5 and 6. But, as I've said on the calls before, we have to pin down one of these (accessFeature) before the other two (accessMode and is/has adaptation) can proceed.
   

We may not get all of these properties adopted into schema.org at once, although I would love to see that happen. There is still a concrete order for properties and their adoption that we're going for, which was set by Charles and I in calls back in early October and have been posted in the agenda since early October.

1. AccessHazard (done)
   
2. mediaFeature (now accessFeature) (done as far as we're concerned, but there is no confirmation of that from Charles McN and schema.org)
   
3. ATCompatible
4. accessControl (was controlFlexibility) and accessAPI
   

1. accessMode and the three proposals for the available access modes

1. is/hasAdaptation

Let's keep with that original order, or have a discussion on the order rather than changing the meaning of a property (my personal opinion is that use cases will reveal that both the source and augmented access modes are needed and that we need a way to represent them as unique concepts... see the issue tracker for detail on the proposals).

And we need to agree to one specification, and to have the RDFS describe that specification. We'll get into serious trouble if we diverge from a methodical process.

So, review the specification (I think I will bring over a definition of accessMode from the best practices guide) and let's make concrete use cases and proposals for the "other type of access mode desired."

[Liddy Nevile]

Colleagues,

I have no intention of changing anything but how does it help a user
or search engine to know that there are some accessModes that can be
combined to provide the complete resource but it is not stated which
ones.

For example, if the accessModes are video, text, auditory, how would
we know what is required to get all the content and how would I know
if I will be OK with just video and text or even just text? I
discussed this with Charles Nevile because I was curious about it and
heard little from the group.

I am pleased that at last there is a focus on this issue and suggest
that I am not doing anything new. Given the table as I have it, I
believe we are getting close to a minimal version of what we all talk
about, respect the principles, and have something implementable.

I believe some are anxious about asking the metadata authors for the
resource to do some work in defining the combinations. I think that
most of the metadata on resources will either be written by experts or
derived and so this is not such a big problem as not providing the
user with a clear way of saying what they want.

It is very important to have accessMode as a useful property; to have
accessFeatures so that users can think in terms of what they need; to
be able to make metadata-writing wizards that are easy to use; to have
clear rules for search/matching systems, etc and that all the time we
respect the user's individual choices.

I have spent a lot of time trying to finess the tables - I was
surprised, for example, that if we have 'text' as I have it now, we
don't have to worry about the size or colour of the text, whereas for
captions printed on video etc, that is important.

I really do welcome comments - so I am not being defensive but rather
wanting to know how to make this the best we can make it ...after so
many years of work.

Liddy

>> > send an email to a11y-metadata-project
>> +unsub...@googlegroups.com.

[Charles Myers]

Liddy,
The issue of the searchable access modes is recorded as an open issue
in the issue tracker, and there have been two proposals made. See
http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#accessMode_and_accessibilityMode_subtype.2C_proposal_1
(the second follows it).
As we've been spending our time to close on mediaFeature/accessFeature,
we have not taken to this part yet. It is the logical next step in the
process described and agreed to.

I would like to finalize the .7 draft, even with these known issues. We
have solidly addressed issues 1, 2, 3 and 8 from the issue tracker
http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker at this
point and we need to state that we're at a stable point with the items
proposed, even if there are other issues still pending. I do not
diminish the import of those issues... we need to get this next stable
point and move on and not revisit issues. I don't want us to change
property names again after this, for example.

With two days of editorial work on the .7 specification behind me, I'll
just reflect that the changes that we have made are actually somewhat
cosmetic, simplifying and putting some terms, like largePrint into the
vernacular. Most of the rest of this has been better explanations and
groupings for what we've done.

So, let's make sure that we have the draft .7 of the specification as
right as it can be, and then we can open it up for public comment once
we have it in a steady state.
http://www.w3.org/wiki/WebSchemas/Accessibility I have the goal of
having this available at the end of the day tomorrow, Friday, 11/8/13.

And then let's take up issues 6 and 7 on the list with passion after
that. What is clear to me is that we different users need different sets
of access modes, both the source and augmented, and our challenge is to
find a way to represent both of them easily.

[Cheetham, Anastasia]

On 2013-11-07, at 5:21 PM, Charles Myers wrote:

> So, let's make sure that we have the draft .7 of the specification as right as it can be, and then we can open it up for public comment once we have it in a steady state.
> http://www.w3.org/wiki/WebSchemas/Accessibility
>

> And then let's take up issues 6 and 7 on the list with passion after that

+1 for getting what we've got so far out there for feedback as soon as possible.

Point of interest: We're actually starting to look into designing metadata authoring supports based on this proposed data model, and one of the things we're considering is how much of the metadata can be "computed" automatically, and how much of it requires human consideration (our goal is to automate as much as possible, to reduce the burden on the author). The list of possible combinations of access modes that could be considered sufficient is something that will be computed, not something that the author will have to provide.

Chuck, thanks for coalescing all of our discussions into the resulting draft, it's helpful to see it all pulled together.

--
Anastasia Cheetham Inclusive Design Research Centre
ache...@ocadu.ca Inclusive Design Institute
OCAD University

[Liddy Nevile]

Can someone please tell me why such as chemML would be a value for
accessibilityMedia rather than an accessibilityFeature? It does not
yet make sense to me that mathML, chemML, etc are sensory classes - so
I'd like help with this.

I'd also like to know if anyone has found out what people with hearing
disabilities are likely to want in terms of accessibilityFeatures??

Hope you can help -

Liddy

[Madeleine Rothberg]

Hi Liddy,

On 11/21/13 4:07 PM, "Liddy Nevile" <li...@sunriseresearch.org> wrote:

>Can someone please tell me why such as chemML would be a value for
>accessibilityMedia rather than an accessibilityFeature? It does not
>yet make sense to me that mathML, chemML, etc are sensory classes - so
>I'd like help with this.

I don't understand your question. There is no property called
accessibilityMedia in either of the two documents I checked --- the W3C
wiki has the current proposal for adopting the first four agreed
properties into Schema.org:
http://www.w3.org/wiki/WebSchemas/Accessibility


And the other project site has a wider proposal including additional
properties:
http://www.a11ymetadata.org/the-specification/


Were you possibly asking about the "chemOnVisual" term for the accessMode
property on the a11y site? This was proposed as a refinement on visual in
the same spirit as textOnVisual, but giving specificity about the type of
notation that is included in the image.

>I'd also like to know if anyone has found out what people with hearing
>disabilities are likely to want in terms of accessibilityFeatures??

There are several accessibilityFeatures expected to be useful for people
with hearing disabilities. What do you think is missing? We currently have
caption, signLanguage, transcript, and enhancedAudio.

-Madeleine

[Liddy Nevile]

Madeleine,
thanks for your response ...I had too many things on my mind -

accessMode has become accessibilityMode - and that is what I meant...

>
>> Can someone please tell me why such as chemML would be a value for
>> accessibilityMedia rather than an accessibilityFeature? It does not
>> yet make sense to me that mathML, chemML, etc are sensory classes -
>> so
>> I'd like help with this.
>
>

> Were you possibly asking about the "chemOnVisual" term for the
> accessMode
> property on the a11y site? This was proposed as a refinement on
> visual in
> the same spirit as textOnVisual, but giving specificity about the
> type of
> notation that is included in the image.
>
>

yes - my question is perhaps just - why more than visual, auditory etc
- not that I object, just that I don't understand...

>
>> I'd also like to know if anyone has found out what people with
>> hearing
>> disabilities are likely to want in terms of accessibilityFeatures??
>
> There are several accessibilityFeatures expected to be useful for
> people
> with hearing disabilities. What do you think is missing? We
> currently have
> caption, signLanguage, transcript, and enhancedAudio.

I thought Anastasia was going to check - I am no expert but if these
are enough, OK! good :-)

Thanks again

Liddy

>
> -Madeleine

[Liddy Nevile]

Madeleine

more questions. You said:

>
> There are several accessibilityFeatures expected to be useful for
> people
> with hearing disabilities. What do you think is missing? We
> currently have
> caption, signLanguage, transcript, and enhancedAudio.
>

I was interested in what characteristics of auditory resources cause
problems that people would like dealt with as features -
I suspect that we have volume, tone, pitch, and backGroundSound. Are
there others?

Liddy