Re: Adopting the media accessibility requirements

On Oct 31, 2010, at 01:58, John Foliot wrote:

> Henri Sivonen wrote:
>> Who is a "user"? Are you using the word "user" more broadly than is
>> customary in this WG? That is, does "user" here mean people with
>> disabilities or are you using it more broadly?
> 
> A user is a user. A person.

Typically in this WG, a "user" isn't just any person but a person in a particular role in contrast to "authors", "implementors" and "specifiers".

>> I have an *extremely* hard time believing that e.g. copyright metadata
>> is a *user* *accessibility* requirement if "user" means a person with a
>> disability accessing an HTML5 site/app.
> 
> What I am hearing is that you are disproportionately caught up on the 
> mention of Copyright.

It's the most glaring example of something that is not a user accessibility concern (when "authors" are not "users").

> It is important when purchasing or commissioning media, that captioning and 
> described video is taken into account and made equal priority in terms of 
> ownership, rights of use, etc., as the video and audio itself.
> 
> This is primarily an authoring requirement."

Well then, it's not a requirement for disabled users to be able to access anything.

> Here we have explained why content creators will need the ability to 
> indicate copyright information, usage rights, etc. in support (alt-format) 
> content, and further this has been noted as primarily an authoring 
> requirement.

For some level of "need" that's, in any case, not really an *accessibility* matter. Non-accessibility translation subtitles and non-accessibility audio books usually contain authorship legends in-band as data rather than metadata, so metadata obviously isn't a make-or-break requirement. (For example, when the credits roll in a foreign TV show, the subtitles typically show the name of the translator and the name of the subtitling company.)

> Are you saying that this is not a requirement?

I'm saying that it's not an accessibility requirement. Even further, I think it's not a hard requirement of any kind. That is, I think HTML5 shouldn't be blocked from advancing on the REC track if it didn't support copyright metadata for captions or description tracks.

> Or are you suggesting that supplemental alternative content should not be 
> allowed to contain metadata (which could include, but is not limited to, 
> Copyright)? Could you explain why not?

I'm not saying that HTML5 shouldn't support this feature. I'm saying that it's not an accessibility requirement. Thus, it would be wrong to e.g. invoke the Human Rights of disabled users when discussing it, which tends to be done for accessibility features. I'm also saying that it's not a must-level requirement. Thus, HTML5 shouldn't be blocked if the requirement isn't satisfied.

> The sub-team has not yet completed its evaluation of possible time-stamp 
> formats (TTML, WebSRT, etc.) but at this time we are working from the 
> assumption that any format chosen will require the ability to support some 
> form of metadata (and we have not specified how or what form that metadata 
> will take).
> 
> Are you saying we are wrong here?

Yes, I am. Copyright metadata should not be a criterion when evaluating the ability of a proposed format to enable accessibility.

When evaluating accessibility, it seem to me that it should be a no-brainer that if failure to satisfy a requirement doesn't deny access to people with a disability, then it's not an accessibility *requirement*. If failure to satisfy the "requirement" made access less smooth to people with a disability while not affecting people without that disability (compared to satisfying the requirement), then the "requirement" is an accessibility-enhancing feature, but not a *requirement*. If the failure to address the "requirement" doesn't materially change the experience of users with any disability any more than it'd change the experience of users without disabilities, then the item is neither an accessibility requirement nor an accessibility feature and shouldn't be represented to be an accessibility feature or requirement.

I suggest evaluating each proposes requirement and asking the question: "If this requirement were removed, people with which disability would be denied access?" If the answer is "None", don't call it a requirement and ask the follow-up question: "If this requirement were removed, people with which disability would have the convenience of their user experience degraded significantly more than users without disabilities?" If the answer is "None", get rid of the "requirement".

I believe that subjecting "copyright metadata" (or codec optimization) to this two-step litmus test would lead to the conclusion of taking it off the requirement list.

> Please elaborate so that we can understand 
> why this is.

See above.

>> 
>> It's very hard to believe that all requirements and, more to the point,
>> *nothing but* serious, carefully considered *accessibility*
>> requirements have been captured, when the document looks like
>> requirements have been copied and pasted from elsewhere without enough
>> attention to detail to bother to make sure the requirements read as up-
>> to-date ("Unicode 3.2") and as Web-relevant ("user switches to a
>> different program or channel").
> 
> I find it quite unfortunate that you have read this document with such a 
> myopic view.

I'm surprised at your use of the metaphor. (I actually have myopia.)

Wow, just, wow. ;-)

> You quibble about 
> which version of Unicode we mention, yet miss the larger issue: Unicode 
> support is required. If we replace "user switches to a different program or 
> channel" with "user switches to a different media stream or digital asset" 
> does it really change the problem description/needs requirement?

It sends a signal about the level of attention to detail paid in the drafting process.

>> I am suggesting that the WAI has a history of writing a binding
>> document
> 
> Binding to whom? And how? It would seem to me that outside of the W3C, any 
> Recommendation, Guideline or Note is completely non-binding. There is no 
> enforcement mechanism attached to any Standard that emerges from the W3C.

WCAG is binding to whoever is threatened with legal action appealing to either WCAG or to legislation that adopts parts of WCAG. The Media Accessibility Requirement, if adopted, would presumably be binding to the HTML WG such that a failure to meet some of the requirements would result in OFFICIAL PROTESTs, Format Objections, stalled transitions along the REC track, etc.

> Within the W3C, yes, we should eat our own dog food. Do you see this as a 
> problem?

If the requirements require too much, yes.

>> and another non-binding companion document and titling the
>> binding document in less committal terms than how the document will be
>> used. (E.g. WCAG comes with a separate non-normative "Understanding"
>> doc and is called "Guidelines" instead of e.g "legislation template".)
> 
> I'm not really sure where you are going here, or how this pertains to the 
> topic at hand: We have collected what we consider to be a complete list of 
> User Requirements, with the intent of using this list to evaluate how 
> successful we are in ensuring Accessible media in HTML5. At this time we are 
> asking the Working Group if they agree with this list: is it complete? Is 
> there any confusion in understanding any of the requirements that we need to 
> better explain? If that is the case, please say so.

It pertains to the topic like this:
In both cases there are documents A and B. Document A will potentially be treated as binding. Document A has a title that's less strict than the how the content is likely to be applied. Thus, readers should read the content of document A to form their opinion about it. They shouldn't form their opinion based on the title, and they shouldn't form their opinion by reading document B.

>> Thus, when reviewing the Media Accessibility Requirements, participants
>> of the HTML WG would be well advised not to base their review of the
>> would-be binding document on the companion non-binding document or on
>> how things are titled or introduced.
> 
> You really seem to be focused on the term of 'binding' - so let's cut to the 
> chase. At this time the only thing we are "bound to", committed to, is to 
> ensure that the accessibility of media in HTML5 is done right: that it is 
> complete, effective, achievable and inclusive. Are you suggesting that this 
> is wrong?

I am suggesting that it's wrong to commit to requirements that either aren't accessibility requirements (e.g. coded optimizations, copyright metadata) or that merely enhance accessibility but wouldn't deny access to anyone if unsupported on the grounds that they are purported to be accessibility requirements.

We might end up satisfying non-accessibility requirements or delivering accessibility enhancements, but I think the WG shouldn't commit to those features ahead of time by posing the as accessibility requirements that, presumably, if unsatisfied would block/stall HTML5.

>> I could go all "Wow... just, Wow." on copyright metadata and RDFa
>> showing up in an accessibility requirement doc.
> 
> RDFa? There is exactly one mention of RDFa in the document, and it is 
> provided as an "example" along with the possibility that Microdata could 
> also serve the purpose:
> 
> "(ECC-1) Support metadata markup for (sections of) timed text cues. NOTE: 
> Such "metadata" markup can be realised through a @title attribute on a of 
> the text, or a hyperlink to another location where a term is explained, an 
> <abbr> element, an <acronym> element, a <dfn> element, or through RDFa or 
> microdata."
> 
> I see lots of potential choices there, and nothing is "binding" at this 
> time. *My* question would be should we continue to offer multiple choices, 
> or is it better for interoperability that we settle on one means and simply 
> support that? And if it is the latter, which choice is best?

The whole requirement ECC-1 looks suspicious to me, RDFa or no RDFa.

>>> Do you agree or disagree that users with the following
>>> disabilities/impairments require accessible alternatives to media:
>>> 
>>> * Users who are Blind
>>> * Users with Low vision
>>> * Users with Atypical color perception
>>> * Users who are Deaf
>>> * Users who are Hard of hearing
>>> * Users who are Deaf-blind
>>> * Users with Dexterity/mobility impairments
>>> * Users with Cognitive and neurological disabilities
>> 
>> I agree that users who are blind (or have low vision) or deaf (or are
>> hard of hearing) require alternatives to media. It's not obvious to me
>> that the best way to make media accessible to users with atypical color
>> perception or dexterity/mobility impairments is alternatives to media,
>> so tentatively I don't agree but I'm not sure to disagree, either. I'm
>> not competent to comment on cognitive or neurological disabilities.
> 
> As a "non-binding" explanation, users with atypical color perception might 
> need to apply alternative styling to caption or sub-title text (for 
> example), so when we are assessing time-stamp formats, the ability to modify 
> that text with user-supplied style sheets is an important (required!) 
> functionality. We have not suggested how this should be accomplished at this 
> time (and the feedback from engineers on possible means is welcome), but is 
> the basic principle and needs description wrong?

Isn't it simpler to pick one caption style that works for various types of atypical color perception? Is the usual white text with black outline a problem for people with atypical color perception?

> We have also identified the need for users to be able to navigate within a 
> larger media asset using semantic (hierarchal) mark-up (for example, 
> possibly being able to navigate 'chapters' using heading mark-up). If we 
> apply Universal Design principles to this requirement, then a mobility 
> impaired user could also navigate this 'tree' in a fashion similar to a 
> non-sighted user (i.e possibly by tabbing).

Why would you make that an alternative instead of making the main media asset support that?

>> Now, in this thread, the HTML WG is like the recruit, the accessibility
>> requirements are like the contract, Karl and Silvia seem to be acting
>> at least a bit like the recruiter explaining that it's not as strict as
>> it looks and you seem to be like a lawyer ready to treat every last bit
>> as binding as possible.
> 
> I'm sorry you see this that way. You seem almost to be afraid to commit to 
> Universal Access as being a 'contract' that you cannot live up to. I don't 
> know how to respond to that.

No, my point is that I believe that some purported requirements aren't actually required for achieving Universal Access.

>> I'm not suggesting a conspiracy. I'm suggesting that when e.g. Karl
>> says I'm misunderstanding, clearly I'm not misunderstanding given you
>> response. Thus, I think it would be advisable for all WG participants
>> to read the doc with the assumption that if it is "adopted", you will
>> very likely treat every requirement as something that can't be subject
>> to a tradeoff.
> 
> Henri, the goal of Universal Access is not something that can be traded 
> away.

Here's an example of a technical design decision that involves a tradeoff:
For described video, so you send the original soundtrack and a description track to the client or do you send the client one soundtrack that's an alternative to the main soundtrack and that contains an author-specified mix-down of the original soundtrack and the description. In the latter case, the UA can't change the volume of the description or relocate the describing voice in the stereophonic field independently of voice frequencies in the main soundtrack. On the other hand, when the author provides the mix-down, the author has the ability do deliver an optimized experience by selectively removing music or sound effects that would compete or conflict with the description.

Furthermore, allowing the user to adjust the volume or the stereophonic balance of the description and the main soundtrack independently translates to more UI surface/complexity, which may degrade the overall usability.

> there is no expectation that these illustrations be 
> adopted as the definitive "how to" if better or more efficient methods can 
> be developed.

In that case, I suggest rephrasing the requirements so that they don't look like precise, must-level implementation requirements to any reasonable or unreasonable person.

>>> In other words, do you have a problem with the language, or do you
>>> disagree
>>> that we need to support Described video?
>> 
>> I agree that described video needs to be supported. However, e.g. this
>> feature looks like a "nice to have" feature and not like an essential
>> requirement for making content accessible to users with a certain
>> disability: "(DV-13) Allow the user to relocate the description track
>> within the audio field, with the user setting overriding the author
>> setting. The setting should be re-adjustable as the media plays." And
>> the copyright and usage rights part of this "requirement" doesn't look
>> like an accessibility thing at all: "(DV-14) Support metadata, such as
>> copyright information, usage rights, language, etc."
> 
> Your questions regarding (DV-13) are fair, and warrant further discussion. I 
> commit to ensuring that a fuller response outside of this particular thread 
> is provided.

Thanks. I suggest subjecting every requirement to the two-step litmus test I suggested above.

> Regarding the need to support metadata: Are you suggesting that there is no 
> link between the need for metadata and the creation of alternative format 
> content that supports accessibility?

I'm suggesting that the link isn't strong enough to have a material effect on users getting accessible content. If we started treating any author wish as a user requirement because of a fear that authors would author less if they didn't get everything they ask for, we'd be on a slippery slope that'd next lead to e.g. saying that DRM is an accessibility requirement.

> 	"The above copyright notice and this permission notice shall be included in 
> all copies or substantial portions of the Software." (from the MIT License)

When that notice appears in Java files (and it often does), it appears in comments that have no copyright notice semantics on the Java programming language spec level--not as metadata (such as Java 5 Annotations). E.g. C files don't even have a metadata mechanism like Annotations, and the notice appears in comments there, too. In HTML, it can even occur in a part of the file that's content and not even comment from the file format perspective. The notion that a metadata mechanism is required seem, thus, nonsense.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 1 November 2010 13:33:27 UTC