RE: [a11y-metadata-project] RE: Schema.org accessibility proposal Review...

Karen made a comment earlier that showed up only on the W3C list.  Since we're running this on both the W3C list and the a11y-metadata-project google group, I'm going to repeat her comments here and then give a reply from our developer who implemented the Bookshare data load.

Martin's answer:
The long and short of it is that these are not mere re-encodings; DAISY Audio and BRF for example offer entirely different access modes, so it's not just old wine in new wineskins, they're fundamentally different in mode of interaction.

Also, I think that Andy Heath's summary of the two use cases for is/has adaptation summarize the rationale even a bit more clearly than I did.  I repeat that after Karen's comments.



Karen comments:

Gerardo, I really appreciate seeing this example, and I will say
something about that in a moment. But to begin, I looked at the various
codings of media types in library data and see no conflicts with
accessmode and mediafeature. In fact, I think that these could add some
very useful information that library data does not contain in a terribly
usable way.

I noted, however, the "adaptation" data, which looks like:

hasadaptation:
https://www.bookshare.org/download/book?titleInstanceId=18041&downloadFormat=DAISY_AUDIO
hasadaptation:
https://www.bookshare.org/download/book?titleInstanceId=18041&downloadFormat=BRF
hasadaptation:
https://www.bookshare.org/download/book?titleInstanceId=18041&downloadFormat=EPUB3

The "adaptations" here are what I would think of as alternate digital
formats, and would fit into http://schema.org/encodingFormat. I agree
with Chaals that directionality between these alternate formats is often
difficult to determine. I am thinking of this in terms of eBooks, where
many different formats are generated simultaneously. But what I don't
know is whether there is significance to the directionality in the
accessibility environment, so perhaps you can address that.

I also would prefer that the term "adaptation" not be used for changes
in format/encoding, since in the academic and bibliographic world that
term refers to changes in the *content* not the physical or digital format.


Repeat of Andy Heath's comments on is/has are:


Two use cases:

1. Content producer commissions or produces in-house adaptation for a resource - use hasAdaptation

2. Organisation external to the resource producer produces adaptation for a resource. The resource producer is not informed, gives no permission, does not even know about it. Would use isAdaptationOf.
It is arguable that the adaptation producer might embed the original resource in some tagging structure (html) that uses hasAdaptation instead but just a little of the meaning is lost in doing that. Originally we designed this without thoughts that this Metadata might eventually become universally accepted (as seems likely in your work - yippee!) and it had to deal with the notion that metadata might have to be discovered from the content and that it wasn't always possible to associate Metadata with a resource in a robust way (e.g. DRM, content without Metadata, external metadata repositories are a weak link etc.) so this was provided to support that scenario.  If *everything* that might be referenced can have associated Metadata (and I'm pretty sure we are saying that here because as I understand it we're only talking html 5 bindings) then I think it wouldn't be a problem to only have hasAdaptation. But hang on a moment - think Internet of Things - are we completely sure that we are going to *always* be able to associate Metatadata with every "original" resource we might want to have an adaptation for. I'm not completely sure - hence I think there is a case for both right now even if one of the two becomes the recommended practice.

________________________________
From: a11y-metadata-project@googlegroups.com <a11y-metadata-project@googlegroups.com> on behalf of Madeleine Rothberg <madeleine_rothberg@wgbh.org>
Sent: Friday, September 06, 2013 8:22 AM
To: Richard Schwerdtfeger; Jason Johnson (BING)
Cc: a11y-metadata-project@googlegroups.com; Alexander Shubin; Charles McCathie Nevile; Charles Myers; Dan Brickley; Egor Antonov; Gerardo Capiel; Ian Niles; George Kerscher; Liddy Nevile; Matt Garrish; <public-vocabs@w3.org>
Subject: Re: [a11y-metadata-project] RE: Schema.org accessibility proposal Review...

Minor corrections and additions to Rich's email:

From: Rich Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>>
Date: Friday, September 6, 2013 10:21 AM

Hi Jason,

To your 3 points:

1. I think Charles addressed this.

Charles Myers, that is! We have two Charles (at least) in this conversation.


2. ATCompatible: The user is not going to recognize a list of checkpoint numbers and recognize what is useful to them. They really need to know that the author believes that the content is compatible.

To underline this point, our goal is some reasonable set of info on a user's search results. The vocab should be as straightforward and user-comprehensible as possible.


3. iOS does indicate an accessible solution on that platform. The same goes for Java.

I think Rich meant "does NOT indicate." The concern with using general terms suitable for use anywhere in schema.org is that metadata authors think they are filling out what OS their app is used for, while we are asking specifically, "Did you follow the accessibility API for that platform?" Elsewhere Andy said we might not need this when there is only one API per OS, but there are cases where there is more than one, notably Windows, and there is always the possibility for more splintering. As Charles Myers commented, these APIs are named specifications or documents from OS developers, and we are referencing those specific documents.

-Madeleine

--
Madeleine Rothberg
Co-Chair, IMS Access for All Working Group
Project Director
Carl and Ruth Shapiro Family National Center for Accessible Media at WGBH
http://ncam.wgbh.org
madeleine_rothberg@wgbh.org


[Inactive hide details for "Jason Johnson (BING)" ---09/05/2013 10:55:35 PM---Adding Ian Niles from the Microsoft Bing team and]"Jason Johnson (BING)" ---09/05/2013 10:55:35 PM---Adding Ian Niles from the Microsoft Bing team and sharing his feedback. 1.        I'm not sure we ne

From: "Jason Johnson (BING)" <jasjoh@microsoft.com<mailto:jasjoh@microsoft.com>>
To: Charles Myers <charlesm@benetech.org<mailto:charlesm@benetech.org>>, Richard Schwerdtfeger/Austin/IBM@IBMUS, Gerardo Capiel <gerardoc@benetech.org<mailto:gerardoc@benetech.org>>,
Cc: "a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com>" <a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com>>, Alexander Shubin <ajax@yandex-team.ru<mailto:ajax@yandex-team.ru>>, Charles McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>, "Dan Brickley" <danbri@google.com<mailto:danbri@google.com>>, Egor Antonov <elderos@yandex-team.ru<mailto:elderos@yandex-team.ru>>, "George Kerscher" <kerscher@montana.com<mailto:kerscher@montana.com>>, Liddy Nevile <liddy@sunriseresearch.org<mailto:liddy@sunriseresearch.org>>, Matt Garrish <matt.garrish@bell.net<mailto:matt.garrish@bell.net>>, "<public-vocabs@w3.org<mailto:public-vocabs@w3.org>>" <public-vocabs@w3.org<mailto:public-vocabs@w3.org>>, Ian Niles <ianiles@microsoft.com<mailto:ianiles@microsoft.com>>
Date: 09/05/2013 10:55 PM
Subject: RE: Schema.org accessibility proposal Review...

________________________________



Adding Ian Niles from the Microsoft Bing team and sharing his feedback.


1.        I’m not sure we need both properties hasAdaptation and isAdaptationOf (each is just an inverse of the other).
2.       ATCompatible is defined as a Boolean property.  It would be more informative if it were defined as a property with an enumeration of values relating to WCAG 2.0 checkpoints or to some other means of qualifying the nature of the compatibility with assistive technologies.
3.       The values of accessAPI and controlFlexibility are needlessly special-purpose, I think.  It would be better if these values were named/defined in a way that is reusable across Schema.org, e.g. iOS (instead of iOSAccessibility), Java (instead of JavaAccessibility), etc.



From: Charles Myers [mailto:charlesm@benetech.org]
Sent: Thursday, September 5, 2013 4:21 PM
To: Richard Schwerdtfeger; Gerardo Capiel
Cc: a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com>; Alexander Shubin; Charles McCathie Nevile; Dan Brickley; Egor Antonov; Jason Johnson (BING); George Kerscher; Liddy Nevile; Matt Garrish; <public-vocabs@w3.org<mailto:public-vocabs@w3.org>>
Subject: RE: Schema.org accessibility proposal Review...

My last email seems to have been eaten by the email gods. Here is the second try. I apologize if there are duplicates.

Thanks for the comment, Richard,

Let me give a bit of background on the choice of the name ATCompatible, as opposed to the ATinteroperable.
But, before I do this, let me point out hat we do have a crosswalk that relates all of the properties between a11ymetadata, AFA v3 (which was in development as we worked on this, with joint members), AFA ISO, Onix and DC.  This useful document can be found at http://www.a11ymetadata.org/the-specification/metadata-crosswalk/ and may make the  crossreferences easier. Gerardo had not noted that in his earlier response.

There was a great debate in the working group on two property names, apiInteroperable and at atInteroperable. Here is a short summary

* Especially in the context of schema.org where the properties would not be in standalone areas for accessibility, but would be intermingled with all the other properties, property names had to have the least ambiguity.
* With that, atInteroperable became ATCompatible, meaning that it is intended to work with accessible technologies. This suggestion was to have been suggested back to AFAv3, as it was just being added in this version (it was not in the ISO version) and was in draft mode.
* Also apiInteroperable, which was ambiguous outside the accessibility context (which API?) became accessAPI, which made clear that the API in question was for accessibility.

The good news is that we're talking about the exact same thing. But the adience for schema.org is much larger than the set of people who might look at AfA: we needed them to be able to stand alone without the accessibility context.

One bit of background Interoperable is generally viewed as being an attribute between two systems or to use parts from another system: the word's meaning is one of a peer relationship. In our case, we're talking about content, and the interaction is with the media display tool.

Sorry for the long answer, but I wanted to make sure that you understood why we deviated from AfA v3 and were hoping that that effort would move to the new terminology with us. You'll find a number of these, such as the "colorDependent" access mode, which was one of Dan's earlier comments, which was much more clear than just "color."  I hope this helps.  Thanks for asking for the clarification. They key is that we subsetted the AfA work to the minimum set (looking for adoption) and improved names, with feedback to AfA, for many values.
________________________________
From: Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>>
Sent: Thursday, September 05, 2013 1:08 PM
To: Gerardo Capiel
Cc: a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com>; Alexander Shubin; Charles McCathie Nevile; Charles Myers; Dan Brickley; Egor Antonov; Jason Johnson; George Kerscher; Liddy Nevile; Matt Garrish; <public-vocabs@w3.org<mailto:public-vocabs@w3.org>>
Subject: Re: Schema.org accessibility proposal Review...


Rich Schwerdtfeger

Gerardo Capiel <gerardoc@benetech.org<mailto:gerardoc@benetech.org>> wrote on 09/05/2013 12:52:21 PM:

> From: Gerardo Capiel <gerardoc@benetech.org<mailto:gerardoc@benetech.org>>
> To: Charles McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>, "a11y-metadata-
> project@googlegroups.com<mailto:project@googlegroups.com>" <a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com>>,
> "<public-vocabs@w3.org<mailto:public-vocabs@w3.org>>" <public-vocabs@w3.org<mailto:public-vocabs@w3.org>>,
> Cc: Dan Brickley <danbri@google.com<mailto:danbri@google.com>>, Alexander Shubin <ajax@yandex-
> team.ru>, Egor Antonov <elderos@yandex-team.ru<mailto:elderos@yandex-team.ru>>, Liddy Nevile
> <liddy@sunriseresearch.org<mailto:liddy@sunriseresearch.org>>, Charles Myers <charlesm@benetech.org<mailto:charlesm@benetech.org>>,
> Richard Schwerdtfeger/Austin/IBM@IBMUS, George Kerscher
> <kerscher@montana.com<mailto:kerscher@montana.com>>, Jason Johnson <jasjoh@microsoft.com<mailto:jasjoh@microsoft.com>>, Matt
> Garrish <matt.garrish@bell.net<mailto:matt.garrish@bell.net>>
> Date: 09/05/2013 12:53 PM
> Subject: Re: Schema.org accessibility proposal Review...
>
> Chaals,
>
> Thank you for taking the time to think through these issues.  Responses below:
>
> Gerardo Capiel
> VP of Engineering, benetech
> Twitter: @gcapiel  Fork, Code, Do Social Good: http://benetech.github.com/
>
> On Sep 4, 2013, at 5:57 PM, Charles McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>
>  wrote:
>
> Hi,
>
> I'm really sorry this has taken me so long to pin down. I appreciate
> that Epub are looking for some fast movement from schema.org at the
> moment, but I am wondering if we can provide that (I actually
> believe it is possible to fix the things I talk about here without
> busting that timeline, but I can't guarantee that).
>
> I'd like to discuss this on a publicly archived email list. I'm not
> sure if ti should be public-vocabs, or an accessibility-oriented one, or what.
>
> I've added the public accessibility metadata project email list and
> public-vocabs list to this thread.
>
>
> I finally figured out what made me uneasy about the proposal - until
> now I just felt like the dodgy examples I had seen were a symptom
> rather than just one-off mistakes. I've described the issues below as follows:
> - AccessMode (and as a sub-issue, levels of detail). I think this is
> a serious thing that should be fixed more or less immediately
> - AccessFeature. This is important enough to look at immediately and
> figure out what it really does.
> - adaptations. We should let others define this. We really only need
> "anotherVersion" pointers in most cases

> - ATCompatible. I think this is broken, but not critically
> important. We should fix it when we've done the above stuff
Actually, it was supposed to be ATInteroperable (from Access For All). It means that the web content was designed to be interoperable with an assistive technology and the original spec. states which WCAG checkpoints are applicable. This is extremely important. By interoperable it means that the content is capable of enabling a browser to support the native platform accessibility APIs. For HTML5 this would mean through the use of content with strong native semantics and/or ARIA support. ATInteroperable does not mean fully WCAG compliant but it adheres to a subset of the requirements. For example, A Screen Reader, Screen Magnifier, or accessibility test tool user would ask for ATInteroperable content. This type of vocabulary is also sucha that it does not declare the users medical disability.

ATCompatible is the wrong choice as it could mean that your keyboard keys don't conflict by looking at the name.

> - evolution. We need to have some idea about how to handle this, but
> a formal specification isn't required IMHO.
>
> = accessMode =
>
> It should be possible for a "single resource" to be available with
> more than one *set* of accessModes.
>
Yes, we should have a unique set of access modes. Access For All defined those. I suspect they made it to schema.org.

> I agree and this is the design.  A single resource can require one
> or more accessMode(s).
>
> Per IMS documentation at the links below, the accessMode property
> describes "Human sensory perceptual system or cognitive faculty
> through which a person may process or perceive information."  The
> links below also provide example use cases:
>
> http://www.imsglobal.org/accessibility/afav3p0pd/
> AfA3p0_DESinfoModel_v1p0pd.html#_Toc323719827
> http://www.imsglobal.org/accessibility/afav3p0pd/
> AfA3p0_BestPractice_v1p0pd.html#_Toc324315328
>
> We have also published a best practices and an implementation guide
> on the use of accessMode at:
> http://www.a11ymetadata.org/wp-content/uploads/2013/04/
> A11yMetadataProjectBestPracticesGuide_V.6.pdf
> https://wiki.benetech.org/display/a11ymetadata/Practical+Properties+Guide .
>
> All of our resources for assistance and guidance can be found at
> http://www.a11ymetadata.org/resources/ .
>
> accessMode is derived from the Access For All (AfA) specification by
> IMS Global and the associated ISO 24751 (Individualized adaptability
> and accessibility in e-learning, education and training) Part 3
> (digital resource description) specification. WGBH’s NCAM and the
> Inclusive Design Research Center (IDRC) who were both involved in
> ISO 24751 and AfA were also involved in the crafting of this Schema.org
> accessibility metadata proposal.  IMS who is the copyright holder on
> AfA released this proposal under a CC-BY-SA license per Schema.org terms.
>
> We chose to leverage this prior work because Schema.org is meant to
> address search use cases, which have strong overlap with the AfA use
> cases related to matching the appropriate resource to a learner
> based on on their needs and preferences.  AfA/ISO 24751 work is
> being synchronized with and leveraged by other current projects,
> such as Indie UI and GPII.  Rich Schwerdtfeger can probably talk to
> this much more than I can.
>
>
> Essentially, it is unclear what accessMode really means. At least
> for the search use case where a user needs to find a suitable
> resource, I think the only way this can really work is if an
> accessMode is a set of one or more *required user capabilities*.
>
> Yes, I think that is what we are saying too.  In fact, it seems like
> what others have understood on the public vocabs list as evidenced by:
> http://lists.w3.org/Archives/Public/public-vocabs/2013May/0092.html
> http://lists.w3.org/Archives/Public/public-schemabibex/2013Aug/0049.html

>
> To pick some examples:
>
> Alice In Wonderland is available as a resource which only *requires*
> the ability to read text.
>
> We happen to have a few versions of Alice in Wonderland in Bookshare
> that have been indexed by Google's Custom Search Engine, so let's
> first search for a pure text version of it with no visual components:
> http://www.google.com/cse?
> cx=001043429226464649088:WMX1711548652&q=more:p:book-
> accessmode:textual%20-more:p:book-accessmode:visual%20more:p:book-
> name:alice%20in%20wonderland
>
> If you inspect one of those titles using Yandex's webmaster tools or
> Google's rich snippets tool that lets me just plug in a URL
> parameter, we can see the accessibility microdata on that page:
> http://www.google.com/webmasters/tools/richsnippets?q=https%3A%2F%<http://www.google.com/webmasters/tools/richsnippets?q=https%3A%2F%25>
> 2Fwww.bookshare.org%2Fbrowse%2Fbook%2F18041
>
> As you can see we offer 4 different adaptations of that title, which
> we originally adapted from a physical book that we scanned.  For
> each adaptation we describe the accessModes that are used.
>
> If I wanted to search for Alice in Wonderland as an audio book in
> Bookshare we can do that and find that same title, since we offer
> audio only adaptations on that page, such as DAISY Audio and MP3:
> http://www.google.com/cse?
> cx=001043429226464649088:WMX1711548652&q=more:p:book-
> accessmode:auditory%20more:p:book-name:alice%20in%20wonderland
>
> Here’s another example that searches for books about history in
> Bookshare where the images are either described with short (i.e.,
> alt) or long descriptions (i.e., longdesc or DAISY prodnote):
> http://www.google.com/cse?
> cx=001043429226464649088:WMX1711548652&q=history%20more:p:book-
> mediafeature:alternativetext,longdescription

>
> This applies to several versions available from Project Gutenberg -
> some of them have images, some don't, but in any case it is possible
> to understand Alice in Wonderland without the pictures.
>
> This is arguably not the case with kipling's "Just So Stories"
> (likewise freely available), since there are intrinsic references to
> the images - although it might be the case that the references are
> sufficiently descriptive
>
> If there is a movie of Alice In Wonderland available with captions,
> then there are two sets of requirements. One is to be able to watch
> a movie and listen to the audio, and the second set is to be able to
> watch a movie and read the captions. (If it had descriptive audio, a
> third would be being able to hear the descriptive audio and the main audio…)
>
> That is the purpose of mediaFeature.  A movie typically has
> accessModes of visual and auditory.  If it has captions, we simply
> add a mediaFeature of captions and/or a mediaFeature of
> audioDescription.  You can find an example in our Practical Properties Guide:
>
> https://wiki.benetech.org/display/a11ymetadata/Practical+Properties
> +Guide#PracticalPropertiesGuide-Video
>
> Khan Academy has been collaborating with us on implementing this for
> their videos and Gooru Learning’s search engine will be indexing
> this metadata to offer their users the ability to filter search
> results to only videos that are captioned.  We hope that Google will
> fix a “bug” with their current video search, which is demonstrated
> by the below search on Wikimedia Commons for captioned videos of the
> moon landing:
>
> http://goo.gl/7PTmI
>
> Though I checked and found moon landing videos on the Commons site
> that are captioned, Google only displays results for videos that are
> captioned from their own YouTube property for which they have that
> information.

>
> It might be that this assumption is already made in the proposal,
> but it is not explicit, and the proposal doesn't explain how to deal
> with a single version that can be used with different sets of
> capabilities (whereasit includes a way to point to other versions)
>
> Schema.org allows for multiple values for the same property.  For
> example, take a look at the example properties for ingredients at
> the bottom of this page: http://schema.org/Recipe

>
> == details in accessMode ==
>
> the top-level accessMode is only useful for "most" cases. Knowing
> that I am physically capable of watching and listening to a video is
> great, unless it is only available in a format I cannot use such as
> "flash for my iPhone 3", "ogg theora/vorbis"….
>
> Schema.org already has a properties for formats (e.g., http://<http:///>
> schema.org/encodingFormat , http://schema.org/BookFormatType )

>
> Similarly if I have more detailed requirements. For example although
> I can watch and hear a video tutorial, being red-green colourblind
> or requiring very high contrast may mean I can't actually understand
> it in practice.
>
> For those use cases, we have accessMode = colorDependent and mediaFeature =
>
>
> = accessFeature =
>
> It isn't clear what the requirements and use cases are for accessFeature.
>
> Are these just cataloguing information, similar to noting that a
> physical book has 5 pages of color photographs, or a guarantee that
> e.g. each image has alternative text, or a longer description is
> provided as necessary?
>
> We thought that implementing AfA or ISO 24751 verbatim for the
> purposes of web search and for use by web masters would be too
> complicated: it needed to be a small set of properties that a user
> could deal with. We decided to combine various ideas into
> mediaFeature.  mediaFeature simply states that the author/publisher
> or someone who modified that book, tried to take advantage the
> stated accessibility features.  For example we make no promise that
> every image was described appropriately, since it is hard to define
> that by a single person and actually different consumers of the
> information may have different opinions about the quality and
> coverage of the image descriptions.

>
> It seems that they are the former - interesting information that
> might lead to expectations of the resource described. They don't
> seem well-enough specified to know if I can rely on them. And the
> list seems somewhat arbitrary.
>
> It isn't clear, for example, how to classify a resource that assumes
> the ability to touch several points of a screen at once, which is
> now a common feature on devices but poses an obvious potential
> problem to some users such as those who don't have very many fingers.
>
> In this use case, the resource that needs to be described is an
> application, not the content.  If the accessibility API of this
> application supports multi-touch with the user’s AT, then the
> proposed ATCompatible and accessAPI properties should be relevant.
> Furthermore, we also have a property called controlFlexibility,
> which also should provide information about whether the application
> can be fully controlled either via audio, mouse, keyboard, touch or
> video/gestures.
>
> = adaptations, other versions, ... =
>
> Liddy has pointed out that the concept of "the original" is only
> sometimes interesting, and that it isn't an accessibility concept
> but a more general one related to creative works.
>
> Actually to a teacher, the “original” is important if they are
> trying to find a resource for a disabled student that is an
> adaptation of the “original” resource used by the rest of the
> students in the classroom who don’t have a disability.  Similarly a
> publisher or book seller wants to make it easy for consumers with
> specialized needs to find resources that have been adapted or “made
> accessible.”  These adaptations properties are also derived from AfA
> and ISO 24751 and I think it’s worthwhile reading their
> specifications to understand  their reasoning. We did simplify the
> terms (removing partial adaptation and the like) to simplify this
> for search purposes.
>

> I think it sometimes matters and sometimes doesn't ("born-digital"
> works don't necessarily have a canonical original form, but may be
> served in very different forms to different users).
>
> I think we should generally not try to coin accessibility-specific
> ways of talking about different versions of acreative work. FRBR and
> its many analogous efforts already deal with this issue, and we
> should just use whatever schema.org adopts where we need it. A
> generic "anotherVersion" relation is probably the most commonly
> required thing anyway.
>
> This isn't high priority, except that I think we should quickly
> decide we want to avoid dealing with defining stuff that others have
> spent decades on, and instead try to use their work...
>
> = ATCompatible =
>
> being a boolean seems a bit naive. I can think of lots of resources
> that work with specific assistive technologies, but fail with others
> (my instant example is http://cookiecrook.com/longdesc/iframe/ which
> works great on VoiceOver but as far as I can tell does nothing to
> work effectively with the built-in MacOS magnifier - two assistive
> technologies I have readily available…).
>
> In the case of content, we once again, we tried to simplify the work
> for web masters and searchers.  Since we can always expand the
> vocabulary, we decided to err on simplicity, and to just have the
> focus on whether accessible technology was considered; enumerating
> WCAG sections would be overly daunting in a search. In the case of
> applications, we did provide greater granularity with the accessAPI
> property, which would differentiate what accessibility API, such as
> VoiceOver, the application is compatible with.

>
> I don't think ATCompatible is the first priority for fixing. But I
> do think it should be replaced with something because I don't think
> it is very useful.
>
> = Evolution =
>
> Who looks after the terms, and how do they get extended?
>
> This is probably the problem with any Schema.org proposal.  By
> basing this proposal on existing standards, such as AfA and ISO
> 24751, it will be easier to evolve these terms as more people and
> organizations (e.g., IMS, GPII, IDPF) will be invested in keeping
> these terms synchronized with other standards and technologies. We
> believe that there are some efforts with 24751 to have a registry to
> assist in this process.

>
> Some things are pretty basic and could be reliably laid down - the
> ability to see or hear is something that we more or less understand.
> But others, such as interacting with new types of device, will
> probably change. Pointer and especially touch interfaces have
> changed a lot in this century, voice interfaces are starting to do
> so, and gestural things like Wii and Kinect are beginning to appear
> more often too.
>
> That's enough comment for now. Hopefully I've clarified the main
> threads that I think need action (some more urgently than others).
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>      chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>         Find more at http://yandex.com<http://yandex.com/>

--
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-project+unsubscribe@googlegroups.com<mailto:a11y-metadata-project+unsubscribe@googlegroups.com>.
To post to this group, send email to a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.

--
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-project+unsubscribe@googlegroups.com.
To post to this group, send email to a11y-metadata-project@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.