Thoughts on latest properties changes and examples

[Anastasia Cheetham]

I think everything is looking really good. I just have a few comments:


Regarding the addition of the 'accessibility' prefix to some of the properties; not 'accessibility' vs. 'a11y,' but rather the use of the prefix at all. I wondered about focusing on the accessibility aspect of the information, thus making it seem to be all about disability. My thinking was that we should be focusing on metadata, not on accessibility.

Then I saw this comment in Charles' email, which echoes my thinking:

On 2013-03-28, at 6:15 PM, Charles Myers wrote:

> Chatting with TV Raman reinforced my sense that we ought to avoid
> framing the 'accessibility' work in a way that lets mainstream Web
> developers think of it as "stuff I ought to get around to doing to
> help out blind people".

It seems to me that adding the 'accessibility' prefix accomplishes this framing we're trying to avoid.

----

Regarding adding 'iPhoneAccessibilty' to the aapiCompatible vocabulary: I fully support the addition, but I'd suggest using 'iOSAccessibility' instead. The API is not specific to iPhones, but also includes iPod Touch, iPad and Apple TV.


----
Regarding the examples:

First, a very small point: I'd suggest spelling out the acronyms APH and NSDL.

Second: The first APH examples don't actually include any of our proposed properties? (unless I just missed them) If this is intentional, e.g. to give the reader the idea of schema.org micro data in general, then I'd suggest we add some text explaining that, for clarity.


--
Anastasia Cheetham a...@anastasiacheetham.ca
Inclusive Design Research Centre OCAD University

[Matt Garrish]

1) I agree about pigeonholing the properties, but the issue that was raised
was that schema.org doesn't have a structured hierarchy of terms, so if we
use a term like 'hazard' we've defined it for all uses. You can't change
meanings from one class type to another.

2) I'll add the expanded names.

3) No, none of the examples are live. They are all proposed ways of
enhancing existing web content at this time. Not a problem to update to
indicate that.

Matt

--
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.

[Gerardo Capiel]

A suggested alternative property name to not "pigeonhole" the properties within accessibility are adaptationFeature instead of accessibilityFeature and visualHazard instead of accessibilityHazard.

Gerardo

On Apr 8, 2013, at 10:55 AM, "Matt  Garrish" <matt.g...@bell.net>

 wrote:

[Liddy Nevile]

yes, these are better but not all the hazards are visual - sound is
also a problem, isn't it? could it just be accessHazard??

Liddy

[Anastasia Cheetham]

On 2013-04-08, at 2:01 PM, Gerardo Capiel wrote:

> A suggested alternative property name to not "pigeonhole" the properties within accessibility are adaptationFeature instead of accessibilityFeature and visualHazard instead of accessibilityHazard.

I like 'adaptationFeature,' that seems pretty accurate to me.

'visualHazard,' unfortunately, doesn't quite cut it, since one of the hazards is "sound" :-) I wonder if 'modalityHazard' might work? Or is 'modality' a bit too cryptic?

[Chuck Myers]

I wrestled with iOS vs. iPhone Accessibility, trying to make Apple's naming and Branding fit our needs (and AfA).  It isn't easy, so I'll explain why I chose the way that I did. I'll then point this out to an apple accessibility resource and let them chime in.

I did three Google searches and found the following:

"Mac OS X accessibility" yielded what was expected

"iphone accessibility" got back results that were analogous to the MACOSX response (Apple equated iPhone and MACOSX)

But then the "iOS accessibility" only appears in the developer documentation, and, even there, refers only to the iphone.

So, I agree that iOSAccessibility is the technically correct answer, since iOS and MacOS are peer systems.  But Apple has consistently branded accessibility on iOS as iPhone Accessibility.  My take is that it was more important to be consistent with the supplier terms for the technology than technical correctness.

Note that I'll be finding the accessibility contact at Apple (does anybody know who that might be?  10 minutes on the phone with support today turned up nothing) and pointing them to this thread.  Apple should be the one to sort technical direction from branding.  My guess is that this may be the first time this came up.

[Marie Bienkowski]

So this would read as "resource has adaptationFeature of"

• alternativeText 
• audioDescription 
• captions 
• haptic 
• highContrast 
• longDescription 
• signLanguage 
• transcript 
• ChemML 
• MathML
• tactileGraphics

So if I use "hasAdaptation" which points to a URI, and that points to something with captions or signLanguage, then it makes sense to harmonize the two.

Marie

[Matt Garrish]

But adaptationFeature applies to the current resource, which could be confusing when the resource isn’t an adaptation. If a resource can exist in an accessible form, not derived from another, doesn’t it still have features?

 

Matt

[Gerardo Capiel]

Chuck and I discussed iOSAccessibility versus iPhoneAccessibility further and agreed upon iOSAccessibility based on further research of Apple.com pages.  

As for adaptationFeature, I think it's still ok even if the content was not an adaptation of something else.  An adaptationFeature can also mean it was "born accessible" and thus adaptable into other modalities, such as going from MathML to speech or nemeth braille.

Finally, I think accessibilityHazard should become accessHazard to be consistent with accessMode.  I think the "access" prefix does not "pigeonhole" us too much.

We would like to finalize the property names this Thursday during the working group call, so we can complete our submital to Schema.org, so please provide any feedback before the call.

[Madeleine Rothberg]

Hi all,

As for adaptationFeature, I think it's still ok even if the content was not an adaptation of something else.  An adaptationFeature can also mean it was "born accessible" and thus adaptable into other modalities, such as going from MathML to speech or nemeth braille.

I like "adaptationFeature" better than "accessibilityFeature." It is less pigeonholing, and it relates better to both the original AfA property names and the other properties in this proposal (hasAdaptation, isAdaptationOf).

We would like to finalize the property names this Thursday during the working group call, so we can complete our submital to Schema.org, so please provide any feedback before the call.

I am satisfied with the changes as discussed in the recent emails.

Should we write up, as part of the official submission, our list of additions to Book Format?

-Madeleine