- From: Charles Myers <charlesm@benetech.org>
- Date: Tue, 8 Oct 2013 06:29:48 -0700
- To: "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
The accessibility metadata group met yesterday. A few things took place that are worth reviewing before our call on 10/8: 1) We decided that accessHazard should have both positive and negative assertions of the hazards. This change has been made in the spec and in the issue tracker http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#accessHazard_-_Ok_as_is.2C_or_should_it_be_negated_in_sense_or_allow_a_.22none.22.3F 2) We had a long discussion on the utility and complexity of mediaFeature, as we'd like to pin down one part of the accessMode, mediaFeature, is/hasAdaptation set of concepts. To make this discussion simpler, I have rewritten (just a proposal) the mediafeatures into the four sensory modes (visual, auditory, tactile, textual) and two types (transform and content). With this more finely grained structure, it should be easier to have a discussion on these features. See http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#What_is_the_goal_of_mediaFeature.3F_.28conforming_or_informational.29_Do_we_have_this_right.3F and the table near the bottom of that item. Let's be ready to discuss #2 in more detail, and then moving to something closely aligned to mediaFeatures, which is the accessAPI and controlFlexibility for applications. This is #10 on the list http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#softwareApplication_properties:_accessAPI_and_controlFlexibility.2C_ok_or_not.3F
Received on Tuesday, 8 October 2013 13:30:44 UTC