- From: John Foliot <jfoliot@stanford.edu>
- Date: Sat, 30 Oct 2010 15:58:20 -0700 (PDT)
- To: "'Henri Sivonen'" <hsivonen@iki.fi>, "'HTML WG'" <public-html@w3.org>
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