RE: Adopting the media accessibility requirements

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.

>
> 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.  The User Requirements documents uses the term 
Copyright 3 times, repeated below:

"In general captioners use a proprietary workstation to prepare caption 
files; these can often export to various standard broadcast ingest formats, 
but in general files are not inter-convertible. Most video editing suites 
are not set up to preserve captioning, and so this has typically to be added 
after the final edit is decided on; furthermore since this work is often 
outsourced, the copyright holder may not hold the final editable version of 
the captions. Thus when programming is later re-purposed, e.g. a shorter 
edit is made, or a ‘directors cut’ produced, the captioning may have to be 
redone in its entirety. Similarly, and particularly for news footage, parts 
of the media may go to web before the final TV edit is made, and thus the 
captions that are produced for the final TV edit are not available for the 
web version.

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

"Systems supporting accessibility needs for media must:
...
(PP-2) Support the association of authoring and rights metadata with 
alternative content resources, including copyright and usage information."
---

"Systems supporting described video that are not open descriptions must:
...
(DV-14) Support metadata, such as copyright information, usage rights, 
language, etc."
---

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.

Are you saying that this is not a requirement?
Have we not been clear enough in explaining the need?
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?

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? Please elaborate so that we can understand 
why this is.


>
> > But do not expect the W3C to start
> > suggesting that
> > certain users with specific disabilities are "more important" than
> > others,
>
> Fair enough, but surely you could sort requirements that pertain to a
> given disability by importance.

"Importance" is a conditional situation that is dependent on any given user, 
so this is a very slippery slope - even in this dialog what is "important" 
to you is less important to me, and seemingly vice-versa. The 
Must/Should/May notations is a first-pass attempt however in doing just 
that, and moving forward each of those assessments is open to further 
discussion should it be warranted. But do not confuse prioritization with 
need: those are very different concepts. Further it is extremely likely that 
some "May" requirements will be very easy to accommodate, while some "Must" 
requirements are going to be tricky to do - and this is both acknowledged 
and understood.

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

A lot of really hard work by serious and committed people (accessibility 
advocates and engineers both) went into the creation of this User 
Requirements document. Is it perfect? Probably not, it is the combined work 
effort of many people with varying degrees of engineering background. Does 
that then negate the spirit or intent of what we are trying to explain and 
outline?

None of this is intended to be "The Specification", it is a reference piece 
that is intended to capture all of the needs and requirements, and it 
sometimes uses language and prior technologies as illustrations of 
need/functionality in an effort to communicate intent. 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?


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

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

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

>
> 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? That getting it only partially right is acceptable?

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


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

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

>
> > Are there any unanswered questions?
>
> For instance, why is "(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." a "must" *requirement* as opposed to being in a "nice
> to have" category? For whom would media be inaccessible to if this
> requirement weren't satisfied?

(Addressed below)


> > Alternative Content Technologies:
> >
> > Do you disagree with any of these alternative content types and
> > technologies?
> > If so, which and why?
>
> I disagree about the essentiality of "extended" and "enhanced". If you
> believed that those features were absolutely essential for achieving
> accessibility, you wouldn't call then "enhanced" or "extended".

Geoff Freed has responded to this question on the list. Did his explanation 
answer your question?

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

>
> 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. That fundamental concept is not open for negotiation. If this 
principle is not something that you can embrace, then we truly are at an 
impasse. However, based on the responses from both Karl and Silvia to this 
thread, it appears that this concept is understood and supported by many if 
not most.

*How* we achieve those goals is very much open to discussion at this time, 
and to date we have taken pains to be as technology agnostic as possible 
when explaining the needs of users. The User Requirements document might 
reference existing or dated technologies, but those references are there to 
serve as illustrations: there is no expectation that these illustrations be 
adopted as the definitive "how to" if better or more efficient methods can 
be developed. The goals and required functionality are not negotiable, the 
means and methods of achieving them are.

If what I have just stated is somehow unclear or requires better 
articulation in the User Requirements document than that is a fair 
observation/statement, and I will confer with the Task Force sub-team on how 
to better provide that.

>
> > 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. Overall however we have already stated that the Must/Should/May 
classifications are still open to discussion.


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?

Regarding copyright: Licensing and rights-usage management affects all 
aspects of content creation, including the creation of alternative content. 
Even some of the most liberal licenses usually contain a clause that states 
that the inclusion of the license with the work effort is a 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)

As we continue to evaluate technologies and solutions then, we need to keep 
in mind that support for some form of metadata is a requirement. Do you 
disagree with this? If so, why?

>
> > NINE WEEKS AGO, when the User Requirements document was released to
> > the HTML
> > WG, we heard not 1 single comment, not one!
>
> Sorry about that. I've been busy implementing HTML5, and from #whatwg
> IRC, it seemed that is was too early to review to requirement doc.

My only comment here is that the #whatwg IRC is not (as far as I am aware) a 
recognized W3C information stream. What you hear or don't hear there is 
likely incomplete or inaccurate. Further, while those involved in the 
evolution of HTML5 are free to congregate and discuss issues wherever they 
choose, I can state that I neither feel personally welcome on the #whatwg 
IRC channel (or mailing list), nor does it appear to be a place that is very 
supportive of W3C goals or process: 
http://krijnhoetmer.nl/irc-logs/whatwg/20101026#l-259

>
> Chances are that some of them will be "deferred to the next release",
> so it would be nice to have data from the experts to support the
> prioritization decisions.

You are welcome to believe what you wish; I do not share your opinion or 
belief.

JF

Received on Saturday, 30 October 2010 22:58:55 UTC