value issues recap

[Matt Garrish]

Hi folks,

 

I’ve added a recap of the recent issues I’ve been sending to the list to the tracker at [1].

 

If anyone objects to the proposed naming changes and moves, could I ask you to please respond to this email. Confirmation of agreement is also most welcome. I’m blocked on the best practices guide until I can get these sorted out.

 

Also, if you have an opinion on which of the proposed resolutions to the transformability issue you’d prefer (or if you have another), please also indicate. After writing them out in the wiki, I think my preference now is for the third option I put in, which is to keep highContrastDisplay as a value that indicates the initial state of the content and use displayTransformability to indicate that the display is user configurable

 

[1] http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#Value_Issues

 

Matt

[Anastasia Cheetham]

On 2013-12-14, at 10:18 PM, Matt Garrish wrote:

I’ve added a recap of the recent issues I’ve been sending to the list to the tracker at [1].

 

If anyone objects to the proposed naming changes and moves, could I ask you to please respond to this email. Confirmation of agreement is also most welcome. I’m blocked on the best practices guide until I can get these sorted out.

Regarding "enhancedAudio" -> "highContrastAudio"

I like the renaming, and it's consistency with "highContrastDisplay, " but: I'm not fully familiar with this form of audio, in terms of what 'reduced background' and 'switchable background' mean, exactly, so I'm not sure whether or not "high contrast" is an accurate description. If it is, then excellent, let's go for it.

Regarding deleting terms from "accessibilityControl"

+1, except that there might be a case for including "fullVoiceControl"

Regarding adding "audioControl," "videoControl" and "timing Control" to "accessibilityFeature"

+1 for "timingControl"

I'm not sure exactly what "audioControl" and "videoControl" would mean?

 Also, if you have an opinion on which of the proposed resolutions to the transformability issue you’d prefer (or if you have another), please also indicate. After writing them out in the wiki, I think my preference now is for the third option I put in, which is to keep highContrastDisplay as a value that indicates the initial state of the content and use displayTransformability to indicate that the display is user configurable

+1 for Proposal Three, I think, so long as the meanings of these two terms are clearly explained. I'm assuming, Matt, that "displayTransformability" will cover both CSS and non-CSS forms of transformation, right?

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

[Matt Garrish]

Thanks, Anastasia! I agree completely with leaving fullVoiceControl; taking that out when I was thinking of shifting audio/video/timing was an oversight.

 

For audio and video control, my assumption is that these were put in to handle, for example, that native controls for the multimedia elements are not enabled by default in HTML5. Having full control over playback, sound control independent of the operating system, etc. seems like a useful thing to note, or at least that’s how I’m interpreting the original inclusion. You might argue that fullKeyboardControl, for example, implies full control over the audio and video, but I was working on the assumption that that might not be the case (e.g., you can access the content fully by keyboard but potentially not be able disable mood music).

 

For highContrastAudio, I’m relying on the descriptions in WCAG 1.4.7 both for the inclusion and the subclassifications, where <20db would be low background noise and switchable I’m taking to mean you can turn off the background.

 

And yes, displayTransformability would not be tied to any one formatting technology. But, you could indicate css customizability generally by setting displayTransformability/css.

 

[1] http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-noaudio.html

 

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.

[Matt Garrish]

Oops, just noticed that should be >20db difference means reduced background noise.

 

Matt

[Gerardo Capiel]

Matt & Anastasia,

I'm not sure led to "timing" being included in accessibilityControl, but I assumed that it was related to switch control for people with motor impairments that use switch devices.  We should make sure that use case is covered.

Thanks,

Gerardo

Gerardo Capiel

VP of Engineering

benetech

650-644-3405 - Twitter: @gcapiel - GPG: 0x859F11C4

Fork, Code, Do Social Good: http://benetech.github.com/

[Matt Garrish]

Good point. I’ll add fullSwitchControl in addition to voice to the tracker.

 

We seem to have all made various assumptions, so it will be good to get these cleared up. I didn’t spot anything else that seemed out of place in the current values, so hopefully with the few small proposed changes we’ll be back on track.

 

Matt

 

---

From: a11y-metad...@googlegroups.com [mailto:a11y-metad...@googlegroups.com] On Behalf Of Gerardo Capiel
Sent: December-16-13 13:39
To: Anastasia Cheetham; Matt Garrish
Cc: a11y-metad...@googlegroups.com
Subject: Re: [a11y-metadata-project] value issues recap

 

Matt & Anastasia,

[matt.g...@bell.net]

Sorry, I spoke too soon, again.
 
I've got one last additional concern about what is being grouped under "structuralNavigation". That terms typically applies to content whose full structure is reflected in the hierarchy of section/headings, allowing navigation by AT.
 
Looking at the refinements, there's a bit of a mix of other things that aren't specifically about the document outline: pagination, indexes, tags and bookmarks. There's also the complementary table of contents, which can go either way.
 
My suggestion here is that structuralNavigation be limited to the outline aspect, and pagination, tables of contents and indexes be broken out. This approach would also keep us in line with ONIX code list 196.
 
I'm not sure if bookmarks is an accessibility feature or not. That seems subjective, as it depends on whose and what use they are. Annotations would seem worth adding, though.
 
I'm assuming "tags" here is related to tagged PDF? Tags is loaded with markup connotations, so perhaps taggedPDF would be a better feature name? I think this would be useful independent of structure navigation, although the two are probably tied to some degree.
 
Matt
 

---

From: matt.g...@bell.net
To: gera...@benetech.org; a...@anastasiacheetham.ca
CC: a11y-metad...@googlegroups.com
Subject: RE: [a11y-metadata-project] value issues recap
Date: Mon, 16 Dec 2013 14:57:50 -0500