HTML WG Wiki - New pages [en]

ExtensionHowTo

Rberjon — Fri, 22 Feb 2013 08:53:13 GMT

Rberjon: /* How do I write the actual specification? */

Has someone marked one of your bugs <tt>RESOLVED NEEDSINFO</tt> and suggested you should write an extension specification? Don't panic!

Are you interested in writing an extension specification but don't know where to start? Don't panic!

Extension specifications are what the HTML WG uses to review new features or modifications that are too large to be adequately captured in a single bug or to sit comfortably in a single email. The basic idea is that the proponent(s) for this new feature will write up a standalone document that can then be reviewed and improved easily on its own, based on discussions on the public-html mailing list and in the HTML WG's bug tracker.

== What is the goal of an extension specification? ==

The primary goal of an extension specification (ES from now on) is to facilitate contributions from a larger community without requiring anyone to jump through the hoops involved in editing the monolithic source of the HTML specification which can prove a daunting exercise.

Once an ES is proposed to the HTML WG a period of review and discussion follows. There is no duration for this, it will end when it feels that the discussion has been sufficient to move on. At that point, multiple things can happen.

'''The ES might get dropped'''. We'd be lying to you if we told you that everything gets accepted, sometimes it might just not work out. We'd rather be upfront about that so that you're not surprised down the line if it happens to you. An ES is no guarantee of integration. Most importantly, see our discussion of use case throughout the rest of this document.

'''The ES may get published on its own'''. Releasing a standalone document with the group's imprimatur is typically used as a way of obtaining further feedback. This doesn't mean that the ES will always remain standalone (it may eventually get folded into the core specification) nor that it will necessarily succeed: it could be that the additional feedback is negative, or it might never gain traction with implementers.

That being said, some ESs will remain standalone documents that will proceed on their own towards Recommendation status without ever being integrated into the core HTML specification. It should be very clear that this is not at all a failure. Your goal in producing an ES should be to improve the Web Platform by getting implementers to support the great feature you have in mind. Which document it sits in at the end of the day really doesn't matter. The decision to fold an ES in or maintain it separately will largely be based on how strongly it interacts with the core specification (if it monkey-patches parts of it then it probably shouldn't stay separate), on implementation schedules, and on editorial convenience.

'''The ES may get folded into the core HTML 5.1 specification'''. If it proves popular and the group wants it, and we generally agree that it would be better off integrated rather than in a document of its own, then it will be integrated into the core specification. Note that if it is broadly implemented and enjoys wide support fast enough, then it can also be folded into the HTML 5.0 specification. This, however, is likely to be exceptional.

== What should be in my extension specification? ==

There are several forms that an ES may take. Please don't jump to conclusions as to the form you should use before reading this section in its entirety.

'''A use cases document'''. Your ES may very well only contain use cases and possibly some code examples showing the sort of code you would like to see becoming possible if your use cases are addressed.

Do '''not''' dismiss this option. First, you will have to do it anyway since the alternatives require use cases anyway. Second, if you have great use cases and a poor solution, you run the risk of your proposal being disliked because of the latter. A great example of this is the [http://usecases.responsiveimages.org/ Use Cases and Requirements for Standardizing Responsive Images].

Before you move on, please take the time to look at the following picture:

[[File:Grumpy-old-maciej.jpg|Grumpy Old Maciej wants use cases]]

'''A standalone extension'''. If you do decide to write up a technical solution in addition to the use cases, then we recommend you do so as a standalone document. This does not in any way constrain whether it may be folded into the core specification later or not, it is simply a description of the way in which you edit your specification.

There are plenty of examples of this in the wiki: [[ExtensionSpecifications]].

'''A modification of the main specification'''. If you are feeling particularly brave (or foolish) you may fork [https://github.com/w3c/html the primary specification] and make the edits you plan on making in a dedicated branch of your fork. This is not recommended. You can, really, if you want to. But make sure that you have overwhelmingly strong reasons to do so before you do so. This will make it harder to write, harder to maintain, and harder to review. For this, you will want to have the [https://github.com/w3c/html-tools html-tools] repository checked out too.

== How do I write the actual specification? ==

If you don't already have an idea of how a specification is written, it is probably better to stick to use cases since getting the solution parts wrong will likely prove detrimental to your case (even if your use cases are great they risk being tainted by association). For that we recommend looking at the [http://usecases.responsiveimages.org/ example cited above].

If you do know how to write a specification already, you might nevertheless benefit from reading [http://www.w3.org/TR/test-methodology/ A Method for Writing Testable Conformance Requirements].

For the rest, do not worry about writing things in such a way that they integrate well with the HTML specification. If your ES gets integrated, someone from the editorial team will go through it to clean it up anyway. If it does not get integrated, then trying to conform will have wasted your time. Focus on awesome use cases and (if you want to) a great technical solution. Don't go off shaving editorial yaks.

If you haven't already, you also will want to read the [http://www.w3.org/TR/html-design-principles/ HTML Design Principles].

== Have you thought about testing? ==

Testing matters. It really does. Keep in mind that your goal is to convince implementers that they want to support this, and the group that it is a good idea. Tests will help the former implement, and the latter review (since code speaks loud). The process to produce a test suite is as follows:

# Fork the [https://github.com/w3c/html-testsuite/ html-testsuite repository].
# Create a new branch for your tests.
# Create a new directory at the root of the test suite, the name of which should be <tt>ext-$yourSpecShortName</tt>. If your specification is a clear addition or change to a section in the HTML specification, then reproduce the directory structure matching that section under the new directory. If not (or if you can't figure that out) then just lay it out in whichever way feels logical.
# Make them, commit, etc.
# Push that branch to your fork, and make a pull request.

You can see an [https://github.com/w3c/html-testsuite/tree/master/ext-xhtml-pubid example of this].

== How do I propose an extension specification to the group? ==

First, make sure that you are properly covered by the Royalty Free policy. The simplest way to do so is to join the HTML WG. If your company is not a W3C member, you're welcome to join as an invited expert.

Second, have you read everything we wrote about use cases? Are you sure? Are you confident you've done a good job there? Have you properly understood how important this is? Okay, read on then.

Just make sure your ES is online somewhere (using GitHub's gh-pages is a popular choice) and email the group with a pointer to your specification, not forgetting to place the use cases well up front (you remember those, right?). The appropriate mailing list for this is public-html.

== What tool should I use for specification writing? ==

Use whatever you are most comfortable with. The two most popular tools for this are [https://bitbucket.org/ms2ger/anolis/ Anolis] and [http://dev.w3.org/2009/dap/ReSpec.js/documentation.html ReSpec]. Since the author of this page wrote ReSpec, he declines to go into a discussion of which is best.

Note that whichever tool you chose, we strongly recommend that you use the "Unofficial Draft" style ([http://darobin.github.com/html-ruby/?specStatus=unofficial example]). With ReSpec, this is done by setting the specStatus configuration variable to "unofficial". With Anolis the simplest is probably to find an existing such document and copy from it.

CR

Plehegar — Wed, 02 Jan 2013 20:13:17 GMT

Plehegar: oops. s/2001/2011/

This is a FAQ for questions related to the HTML5 Candidate Recommendation (CR) specification.

=== When did the documents move to CR? ===

The Working Group decided to move the documents to CR on
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0226.html November 27, 2012]. The W3C Director approved the transition on
December 17, 2012.

=== What is CR? ===

Candidate Recommendation (CR) indicates that the W3C believes the
technical report is stable and appropriate for implementation. The
technical report MAY still change based on implementation
experience. ([http://www.w3.org/2005/10/Process-20051014/tr.html#cfi W3C Process, 7.4.3 Call for Implementations])

=== Which documents were transitioned to CR? ===

The HTML Working Group publishes
[http://www.w3.org/wiki/HTML/Publications several documents]. Only two
of them were approved as CR on December 17:

# [http://www.w3.org/TR/2012/CR-html5-20121217/ HTML5];
# [http://www.w3.org/TR/2012/CR-2dcontext-20121217/ HTML Canvas 2D Context].

=== When will CR end? ===

The HTML5 specification is expected to advance to Proposed
Recommendation no earlier than '''September 1st, 2014'''.

The timeline for HTML5 was outlined in the [http://dev.w3.org/html5/decision-policy/html5-2014-plan.html plan 2014]:

{| style="background-color:#ffffcc;" border="1" cellpadding="10" cellspacing="0"
|-
| CR
| 2012 Q4
|-
| LCf
| 2014 Q3
|-
| PR
| 2014 Q4
|-
| Rec
| 2014 Q4
|}

The HTML Canvas 2D Context specification is expected to advance to
Proposed Recommendation no earlier than June 17th, 2013.

=== What are the criteria to move beyond CR? ===

The HTML Working Group established
[http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html CR exit criteria]. There must be at least two independent,
interoperable implementations of each feature. Each feature may be
implemented by a different set of products, there is no requirement
that all features be implemented by a single product. Qualitatively
interoperable are at a judgment level, not necessarily for every spec
assertion. A test suite may be used as guidance for the qualitative
decision.

=== Where is the test suite? ===

This is still work in progress but the test suite is available via [https://github.com/w3c/html-testsuite/ github]. We encourage everyone to contribute to it!

The '''CR''' branch is limited to features that are found in the Candidate Recommendation version of the relevant specifications.

Please make your pull requests either to the '''master''' branch or a feature branch.

=== Where are the bugs opened against the CR documents? ===

Those can be found in the W3C bugzilla for [https://www.w3.org/Bugs/Public/buglist.cgi?order=Importance&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=CR%20HTML5%20spec&product=HTML%20WG&list_id=3726 HTML5] and [https://www.w3.org/Bugs/Public/buglist.cgi?order=Importance&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=CR%20HTML%20Canvas%202D%20Context&product=HTML%20WG&list_id=3727 HTML Canvas 2D Context].

=== What is this LCf in 2014 Q3? ===

[http://dev.w3.org/html5/decision-policy/html5-2014-plan.html Plan 2014] mentions a LCf in the third quarter of 2014, just before the transition to Proposed Recommendation (2014 Q4).

The [http://www.w3.org/2005/10/Process-20051014/tr.html#cfi W3C Process] indicates that the Working Group '''MAY''' remove features from the technical report that were identified as being "at risk" and, if other substantive changes to the technical report are made to the document, the Director '''MUST''' return it to the Working Group.

The HTML Working Group Chairs are anticipating that the specification will have other substantive changes over the next 18 months and will be returned to the Working Group for a short period. As such, it is anticipated that the Working Group will republish HTML5 as a new Last Call document in 2014 Q3, with a short review period, before moving directly to Proposed Recommendation.

=== Can you add more features in HTML5? ===

At this stage, the Working Group welcome the option of extension specifications that don't merge back at all and instead proceed at different paces and possibly even with different Candidate Recommendation exit criteria. There is however a mechanism to integrate extensions during the CR phase, as outlined in the [http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#cr-integration decision policy]. Among the conditions, one must satisfy CR exit criteria of the base specification and get approval from the Working Group using a Call for Consensus.

=== Were there objections to move to CR? ===

There were three objections to move the HTML5 specification to CR:

# ''[http://lists.w3.org/Archives/Public/public-html/2011Feb/0188.html Decentralized extensibility]'' related to a Working Group decision for the specification to not provide any explicit means for defining custom elements and attributes. The objection was reviewed and considered in discussion with the Director, and the determination was made that it need not prevent transition of the specification to Candidate Recommendation.

# ''[https://www.w3.org/Bugs/Public/show_bug.cgi?id=11204#c54 References]'' related to a working-group decision to make a change to the References section of the HTML5 specification. The objection was based on the fact that the change made did not exactly match the text given in the change proposal from which the decision originated. The objection was reviewed and considered in discussion with the Director, but the change was ultimately found to be reasonable and appropriate, and the determination was made that it need not prevent transition of the specification to Candidate Recommendation.

# ''[http://lists.w3.org/Archives/Public/public-html/2012Nov/0188.html URLs and Web Architecture]'' related to material in the HTML5 specification that defines the term "URL" and related terms, as well as defining parsing of URLs. The objection asserted that the terminology and definitions in those parts of specification were arbitrarily inconsistent with other specifications, and stated that the material should be removed and replaced with forward-looking definitions to be defined by other specifications. The objection was reviewed and considered in discussion with the Director, and the determination was made that it need not prevent transition of the specification to Candidate Recommendation. The group is encouraged to continue work on the material during the Candidate Recommendation period, and it seems likely that specific replacements or refinements of the material will be proposed and adopted by the group, ultimately leading to significant improvements to those parts of the specification.

There were no objections to move the HTML Canvas 2D Context specification to CR.

=== Were all issues closed before moving to CR? ===

The [http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs W3C Process] indicates that the Working Group '''MUST''' formally address all issues raised about the document since the previous step. In addition, the [http://www.w3.org/2005/10/Process-20051014/tr.html#doc-reviews W3C Process] also indicates that reviewers '''SHOULD NOT''' raise substantive technical issues about a technical report after the end of a Last Call review period. However, this does occur, and as stated above, a Working Group's requirement to formally address those issues extends until the start of a Proposed Recommendation review period. The Working Group '''MAY''' decline to make substantive changes to address issues raised between the end of a Last Call review period and publication of a Recommendation.

Around 130 bugs were still opened when the Working Group requested the move to CR. All those bugs were sent after the deadline for comments, August 3rd, 2011.

The HTML Working Group Chairs addressed that point back in May 2011 in the [http://lists.w3.org/Archives/Public/public-html/2011May/0162.html Last Call timeline announcement]: ''The key aspect of this timeline is that there will be a cutoff date for bugs to be considered during Last Call; any bugs after that date will instead be treated during a subsequent Last Call, possibly during Candidate Recommendation or for a subsequent version of HTML.'' The [http://dev.w3.org/html5/decision-policy/html5-2014-plan.html plan 2014] indicated that it presented ''a significant risk of infinite regress if we simply proceed to yet another Last Call in response to the previous Last Call, particularly if we remain open to allowing new issues to continue to be raised.''

As such, only interoperability issues and non-substantive changes will
be addressed in HTML5 CR. Others will be addressed in HTML 5.1 or
beyond.

10 issues were also opened at the time of the CR transition. [http://dev.w3.org/html5/decision-policy/html5-2014-plan.html plan 2014] required actual specification text to be published in the form of extension specifications first, and only after said text meets the exit criteria for CR, consider folding the result into the core specification. To prevent unnecessary confusion, the HTML5 specification will drop explicit indications that any given extension is obsolete once an extension specification exists that has been published as a first public Working Draft (FPWD).

There were no open bugs or issues related to the HTML Canvas 2D Context specification when the transition to CR was requested.

=== Were the documents changed between May 2011 and December 2012? ===

Both HTML5 and HTML Canvas 2D Context were modified between the publication of the Last Call documents in May 2011 and the publication of the Candidate Recommendation in December 2012. The Working Group published updates in March and October 2012, as allowed by the [http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance W3C Process]: ''Between any two steps after a Last Call announcement, the Working Group '''MAY''' publish a new draft of the technical report at the same maturity level provided there are no substantive changes since the earlier step.'' During the transition to CR, the Working Group noted significant changes but indicated that none of those changes were substantive since we didn't believe the changes were invalidating an individual's review or implementation experience. As such, the documents were never returned to the Working Group by the Director and were allowed to move to Candidate Recommendation.

PolyglotRecommendationRationale

Abateman2 — Thu, 06 Dec 2012 16:13:58 GMT

Lsilli: /* Why no C */ Added a refererence to David Carlisle’s named entities extension

=Rationale for Polyglot Markup on the Recommendation track=
'''Summary:''' The specification [http://www.w3.org/TR/html-polyglot/ Polyglot Markup: HTML-Compatible XHTML Documents] (aka Polyglot spec) should be considered for the Recommendation track.
__toc__
==Why recommendation==
<span id="recommendation">On the topic of making Polyglot Markup a ''recommendation'': </span>
# While we might not recommend that ''all'' authors (or in fact that many authors) should create Polyglot documents, we should Recommend that when authors want to create polyglot markup they do so by following the authoring requirements outlined in this specification. In fact, the [http://www.w3.org/TR/html-polyglot/#introduction introduction] of the Polyglot spec does state that <blockquote>All web content '''need not''' be authored in polyglot markup."</blockquote>
# The Polyglot spec does include [[#normative|normative language]] that can be followed precisely and a document can be measured objectively against those requirements to see if it successfully adheres to the polyglot markup rules. It is possible to build a validator that checks a document to see if it is a valid polyglot document according to the polyglot spec and to identify the normative requirements that have been violated should the validation fail.
# There is precedent for guidance documents including authoring guidance to be published as Recommendations. For example:
#* [http://www.w3.org/TR/WCAG20/ Web Content Accessibility Guidelines (WCAG) 2.0]
#* [http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]
#* [http://www.w3.org/TR/wsc-ui/ Web Security Context: User Interface Guidelines]
#* Though much critisized, [http://www.w3.org/TR/xhtml1/#issues XHTML 1.0 Section 5] declared [http://www.w3.org/TR/xhtml1/#guidelines Appendix C] as a profile of what its own syntax that ''“may be labeled with the Internet Media Type "text/html"”''.
# <span id="MeaningOfWorkingGroupNote">To publish as a Working Group Note</span> would send the signal that “[http://www.w3.org/2005/10/Process-20051014/tr.html#q75 work has ended]“ on this particular topic (see [http://lists.w3.org/Archives/Public/public-html/2012Dec/0066 comment by Mike]). Such a signal would be wrong, for example because bugs continue to be filed.

==<span id="normative">Why normative language</span>==
On the topic of using ''normative language'' in the specification:
# The purpose for using normative language in the specification is to make it clear which parts are necessary to conform to the specification and which parts provide advisory or informative content. The polyglot spec is intended to make it possible to objectively determine if a document adheres to its requirements and therefore it is appropriate to differentiate between normative and informative parts.
# It seems [[#Why_no_C|evident from an evaluation of Appendix C]] that C’s lack of normative language and exact rules had bad effects. A document that operates with normative language has a greater chance of becoming coherent than one that does not operate with normative language. For instance, if a section of the document operates with ''MUST''-level requirement for a particular syntax, then the chance that another section would contradict, is quite small simply because normative statements are likely to be checked for coherence. However, exactly that kind of inconsistency [[#CWasNotConservative|is found in Appendix C]], and probably because the section did not define anything normative. Normative language should and will often [http://www.w3.org/TR/qaframe-spec/#reference take the form of a list], akin to a recipe. XHTML 1.0’s [http://www.w3.org/TR/xhtml1/#issues section 5] made clear that [[#appendix-c|Appendix C]] was informative, only. Thus, strikingly, the informative status of Appendix C may have made it less informative. And hence, making sure the spec uses normative language seems like a relevant strategy as long as the goal is to produce a spec that is coherent and of practical value.
# Authors ''are'' going to use XHTML5 syntax for text/html, hence it is of benefit that there is a normative spec for how to do it. And there is no other specification that takes care of defining an HTML-compatible XHTML profile. For instance, Appendix C took the attitude that [[#UserAgentsHadToChange |User agents had to change]], rather than authors and authoring tools.

==<span id="value">Why good value</span>==
On the topic of the value of promoting polyglot markup:
# ''Subsetting is a well known method for emphasizing on, and benefitting from, the good parts of a computer language.'' ''Example:'' From the [http://javascript.crockford.com author of “JavaScript. The Good Parts.”] comes as well [http://www.adsafe.org ADsafe], a ''Safe for Advertising'' subset of JavaScript that intends to remove its security risks via restrictions on the permitted syntax. Polyglot Markup can be viewed from a similiar angle.
# ''Conservative markup may help authors as well as the language itself.'' Currently, markup best-practises are defined outside the HTMLwg. Example: The above mentioned [http://www.adsafe.org ADsafe] JavaScript profile has rules not only for JavaScript but for HTML as well, including a restriction to use UTF-8, which happens to be a Polyglot Markup requirement as well. ADsafe also forbids <code>document.write</code> — which is also not used by Polyglot Markup. Not only does this example show that there can be real value in a conservative spec, but it also shows that there is a market for such spec, for which the HTMLwg should offer real value. And ''— by the way –'' the effect of this does not need to be that XML gets more attetion — it could just as well lead to an attetion to the secure subset of the <code>text/html</code> serialization.
# ''One syntax, two serialization is a feature.'' A tool vendor could serve two usergroups via one syntax. And this, in turn, has the potential of simplfying the tool for its users, as it ought to allow the vendor to skip poking the user to make choices about character encoding or markup format.
# ''It keeps the XHTML simple.'' While Polyglot Markup also adds requirements (like <code><!DOCTYPE html></code>) to XHTML5, overall, the HTML-compatibility requirements holds XHTML in the ears and keeps it simple. E.g. it forbids non-UTF-8, it forbids the XML declaration and so on. And best of all: This is not an artificial extra but an effect of HTML5’s design — Polyglot Markup is merly picking the fruit.
# ''It adds pedagogical value.'' While perhaps not being something that ''alone'' makes it worth sending Polyglot Markup for Recommendation, the single syntax pedagogically highlights on one side, how HTML5 ''itself'' is designed to be XML-compatible and often permits the XML syntax within HTML documents and, on the other side, it can be an educating piece regarding how XML and HTML differ with regard to the DOM and in light of [[#UserAgentsHadToChange|Appendix C’s different approach]] to whether it is XML or HTML that should adapt.
# ''It places HTML5 and its syntaxes in a balanced perspective.'' The HTML5 process has given pure HTML syntax much attention and respect, and circumstantial evidence (e.g. consider the widely used [http://html5boilerplate.com HTML5 Boilerplate] [of which there ''today'' isn’t any polyglot version]) tells us that pure HTML syntax has grown in popularity. The HTML5 spec also emphasizes XHTML5 as a serialization of its own — which is also justified both in principle and as a reacton towards history (Appendix C) and future (XHTML is today well supported by all UAs of the vendors of the HTML working group). But this new attention to the different natures of HTML and XHTML including the ''justified'' critique towards e.g. XHTML (version 1.0) served as HTML, means that many authors probably are unaware of what HTML5 does with regard to XHTML5, and even more unaware that HTML5 contains enough data to define HTML-compatible XHTML5-profiles. Polyglot Markup thus sets a valuable light on this third way — or ''“the both ways”'' as we could call it, helping potential users (authors/tool vendors) to discover that the HTML5 spec also contains '''this''' opportunity and thereby also bringing a balanced perspective on the issue of the HTML5 vocabulary and its two syntaxes.

==Why no C==
<span id="appendix-c">On [http://lists.w3.org/Archives/Public/public-html/2012Dec/0023.html the topic of ''Appendix C'']</span>

''If there is “[http://www.w3.org/2010/html-xml/snapshot/#conclusions little consensus]” around polyglot'' then, on the flip side, this could prevent a history repeat. But more seriously and though one cannot really predict perception, it is the background and goals of Polyglot Markup compared with those of Appendix C, that are the ''real'' reasons why history won’t repeat.

# ''C-mantics vs real, new semantics.'' XHTML 1.0’s offer was an XML replica of HTML4. Thus, to the extent that XHTML 1.0 was perceived and [http://www.w3.org/TR/html/ touted] (note that the URL ends with the acronym “html” — and not “xhtml”) as the latest and greates version of HTML, the syntax naturally had to attract. For HTML5, by contrast, it is the new vocabulary that is the attraction.
# ''C’s different context.'' The scope of Appendix C’s “parent spec” — XHTML 1.0, was very different from that of Polyglot Markup’s parent spec. Which is one reason why Appendix C and Polyglot Markup end up with different answers for the same questions. Take the question of the character encoding, which Polyglot Markup limits to ''UTF-8'' and put restrictions on with regard to how it can be declared. Appendix C [http://www.w3.org/TR/xhtml1/#C_1 section 1] and [http://www.w3.org/TR/xhtml1/#C_9 section 9] '''could''', together, have lead up to a similar conclusion as that of Polyglot Markup. But it did not happen. XHTML 1.0 as well [http://www.w3.org/TR/xhtml1/#issues took the stance] that ''“there is no requirement for XHTML 1.0 documents to be compatible with existing user agents”'', whereas the HTML5 spec follows several strategies to keep HTML and XHTML in sync.
# ''C’s melting pot perspective on the format question.'' Subsection [http://www.w3.org/TR/html/#media 5.1 on the media type] tellingly talks about <code>text/html</code> before it talks about <code>application/xhtml+xml</code>. And also, XHTML 1.0 several places speaks of HTML-compatibility as a [http://www.w3.org/TR/xhtml1/#h-4.10 legacy issue rather than a format issue]: ''“backward compatible when serving XHTML documents as media type text/html”.'' The spirit very much seems to be that the two languages will — and should — melt together on the parser level as soon as parsers ''“[http://www.w3.org/TR/html/#C_11 adapt]”'' to behaviors of the other serialization, or stop being ''“[http://www.w3.org/TR/html/#C_1 legacy browsers]”'' by starting to ignore certain constructs from the ''parallel'' syntax. For Polyglot Markup, in contrast, the acceptance of the two formats are reflected in its title — “'''Polyglot''' Markup”, but also rooted in HTML5 proper — whose subtitle is “A '''vocabulary''' and associated APIs '''for HTML and XHTML'''“.
# ''<span id="CWasNotConservative">C was not conservative</span>.'' [http://www.w3.org/TR/xhtml1/#C_1 Appendix C.1.] ''warns'' against processing instructions – for HTML-compatibility, and [http://www.w3.org/TR/xhtml1/#C_14 yet C.14.] reccommends them – for XML-compatibility. The result is not a single ''robust'' and ''conservative'' syntax but instead a syntax whose requirements vary according to choice of [http://www.w3.org/TR/xhtml1/#C_1 character encoding] and [http://www.w3.org/TR/xhtml1/#C_14 stylesheet] etc.
# <span id="AppendixCWantedXMLParsersToAdaptToHTML4">''C’s DOM from the future.''</span> Polyglot Markup perhaps most important expression of the ''robustness'' principle is its ''identical DOM-principle'', which in practise means that the XML has to adapt to HTML. (To be “[http://lists.w3.org/Archives/Public/public-html/2012Dec/0071.html flagging implied tags]” is considered useful even by Henri, but note that Henri is wrong in assuming that XHTML 1.0 Appendix C caused any such flagging, see below.) For contrast, by ruling that authors were ''not'' required to represent by markup all elements that HTML parsers auto-generate in the DOM, Appendix C took the opposite view — that authors do ''not'' have to achieve identical DOMs! See [http://www.w3.org/TR/xhtml1/#C_11 C.11:] <span id="UserAgentsHadToChange">''“Rather than require document authors to insert extraneous elements, XHTML has made the elements optional. User agents need to adapt to this accordingly”.''</span> By contrast, Polyglot Markup requires authors to be ''conservative in what you send'' and does thus not ask anything extra from the XML parser but requires that XML-compatibility is achieved by representing ''all'' elements in the markup. (For example, it does not rely on [http://www.w3.org/mid/50F832CD.2030006@nag.co.uk extending XHTML5 to handle named entities].)
# ''C’s low concern for conformance.'' Some syntax rules relate to well-formedness while others just makes sense but has (in theory/principle) no effect on parsing. For example, it does not make sense to place <code><meta http-equiv="'''Content-Type'''" Content="'''text/html''';charset=UTF-8" /></code> inside an XHTML document . But to use it in XHTML anyhow, does in principle ''(read: in a conforming parser!)'' not break anything other than the formal conformance rules themselves. Appendix C could thus be said to — in practice — have used the pure conformance rules of HTML as an extension oportunity. By contrast, Polyglot Markup (and HTML5 proper for XHTML5!) only allow <code><meta '''charset="UTF-8"''' /></code>. This is because Polyglot Markup adheres to the conformance rules for HTML5 as well as the conformance rules of XHTML5, and the resulting syntax is not only well-formed but does as well also ''makes sense'' in both serialization. Appendic C was a profile of a specific XHTML syntax but not a profile of a specific HTML syntax, whereas Polyglot Markup is a profile of both the specific syntax of XHTML5 and the specific syntax of HTML5.
# ''C’s unrealized potential.'' One motivation of Polyglot Markup is that the strict rules indirectly promotes best practise coding styles for both XML and HTML: external scripts, external stylesheets, UTF-8, simplicity, no valid XML – only well-formed XML, only no-quirks mode, no magical elements (such as <code><noscript></code>) and so on. When we look at to which extent Appendix C ''— for example in order to support other encodings than UTF-8 —'' opens up for XML-specific code in HTML and how it makes authors expect HTML-specific behavior in XML, then one must conclude that these side-effects were obviously ''not'' the motivation behind Appendix C.

TPAC2012

Plehegar — Tue, 09 Oct 2012 18:20:55 GMT

Abateman2: /* Day 2 Room 1 */

= HTML WG face-to-face TPAC 2012 =

== Topics ==

insert your topic in this section

* Email list organization [http://lists.w3.org/Archives/Public/public-html/2012Oct/0143.html Mailing lists]
* Bug 14689 [https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c18 xml-stylesheet with type=text/xsl needs to be handled explicitly]
* Alt Guidance and Alt text in the HTML5 Document [http://www.davidmacd.com/WCAG/WAI/buggy.html Part 1: Analysis of Guidance]
* Tracker [http://intertwingly.net/tmp/wgstatus.html#tracker-requests Requests]
* Bugs [http://www.w3.org/Bugs/Public/show_bug.cgi?id=15278 15278] & [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16965 16965] - Localization hints using BCP-47 for non-Gregorian calendars and other cultural\regional presentational conventions (Brief, NOT afternoon 2nd November)
* Bug [https://www.w3.org/Bugs/Public/show_bug.cgi?id=18971 18971] TextTrack should have an id attribute (MSE bug 17002 depends on this HTML5 bug)
* [http://www.w3.org/wiki/User:Cjones/ISSUE-195 Issue 195: Enhance HTTP request generation from forms] - Extension Spec & Vendor Implementation Interest (Brief, NOT afternoon 2nd November)
* [http://lists.w3.org/Archives/Public/public-html/2012Sep/0242.html MultilingualWeb-LT WG coord]: 30 min slot for this 1-2 November
** Proposal: 9:00-9:30am on Fri Nov 2
* I18n WG coord: 30 min slot on November 2. next to the MLW-LT topic if possible.
** additional values for dir attribute, like rli and lri (i stands for isolate)
** Concerns with the ruby model
** review of outstanding bugs
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16960 i18n-ISSUE-89: Time zones and local dates and times]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=19255 i18n-ISSUE-200: Position of ruby]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=19254 i18n-ISSUE-199: Examples of ruby rendered]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=19253 i18n-ISSUE-198: rt and rp elements]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=19252 i18n-ISSUE-197: Number of multiple rt elements]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=19251 i18n-ISSUE-196: Mono-ruby vs group ruby examples]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=19207 i18n-ISSUE-194: Multiple sequential rt elements]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16979 i18n-ISSUE-119: provide example of language detection fallback]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16978 i18n-ISSUE-118: explicitly undefined language]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16966 i18n-ISSUE-98: 13 month calendar support]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16965 i18n-ISSUE-97: Allowing a page to request a given locale (4.10.7.2 normativity)]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16963 i18n-ISSUE-94: Allowing culturally specific week rules]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16959 i18n-ISSUE-88: local/floating date terminology]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16957 i18n-ISSUE-85: Health warning about converting date to/from incremental time]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16955 i18n-ISSUE-83: add note about why Gregorian only used]
*** [https://www.w3.org/Bugs/Public/show_bug.cgi?id=16165 i18n-ISSUE-136: Recognition of number formats in Number state]
* [http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Encrypted Media Extensions] (Request 90-120 min slot on Day 1 afternoon)
** [http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0081.html Summary of EME bugs]
* [http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html Media Source Extensions] (Request 90-120 min slot on Day 1 afternoon)
** [http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0051.html Summary of updates to MSE bugs]
* Responsive image extension specs (Request for this session to be done on Day 1 (Thu))
** [http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html Responsive images]
** [http://dev.w3.org/html5/srcset/ The srcset attribute]
** [http://usecases.responsiveimages.org CG use cases]
** [http://picture.responsiveimages.org Thoughts on convergence of <picture> with img@srcset]
* [http://lists.w3.org/Archives/Public/public-html/2012Sep/0060.html Evolving Appcache discussions]
* [https://dvcs.w3.org/hg/html-extensions/raw-file/3acee7f50663/maincontent/index.html Maincontent element]
* [http://dev.w3.org/html5/status/formal-objection-status.html#ISSUE-204 Completing ISSUE-204]
* Testing: status, plan
** Status
** Repository organization:
*** HTML.next
*** http://dvcs.w3.org/resources/testharness.js
*** /support
** Plan
*** [http://lists.w3.org/Archives/Public/public-html/2012Oct/0137.html Publishing test results]
* WG Status
** WG Charter and revised schedule status [http://www.w3.org/html/wg/charter/2012/ Draft charter]
* Preparing for entry to CR
** [http://dev.w3.org/html5/status/formal-objection-status.html Formal Objections]
** [http://www.w3.org/html/wg/wiki/index.php?title=HTML5.0AtRiskFeatures Features at Risk]
** [http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html CR Exit Criteria]
** Status of CR Working Drafts
* [http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#html5.1-milestones HTML 5.1 planning]
** [http://www.w3.org/html/wg/next/markup/ Proposed Elements and Attributes]
** Status of HTML 5.1 Working Drafts
* [http://www.w3.org/WAI/GL/wiki/Meetings/TPAC2012 Accessibility techniques for HTML 5] - Salon VIP Presse room available for breakout

== Agenda ==

=== Day 1 Room: Rhone 3, Level 0 - Rhône-Pasteur ===

* 09:00-10:00: Organization
* 10:00-10:30: Evolving Appcache discussions
* 10:30-11:00: -- Break --
* 11:00-12:00: Responsive image extension specs (bug 18384)
* 12:00-12:30: Issue 195: Enhance HTTP request generation from forms
* 12:30-14:00: -- Lunch --
* 14:00-15:30: Bug 18971 TextTrack should have an id attribute and Media Source Extensions (including schedule)
* 15:30-16:00: -- Break --
* 16:00-17:30: Encrypted Media Extensions (including schedule)

Thursday, 1 Nov - Friday, 2 Nov 08:00-17:00 UTC (4:00am-1:00pm Boston local)

IRC chat (logged): #html-wg on irc.w3.org port 6665 or port 80

Zakim Bridge: +1.617.761.6200, conference 4865 ("HTML")

Minutes: http://www.w3.org/2012/11/01-html-wg-minutes.html

=== Day 1 Room: Rhone 2, Level 0 - Rhône-Pasteur ===

* 09:00-18:00: Not used

Thursday, 1 Nov - Friday, 2 Nov 08:00-17:00 UTC (4:00am-1:00pm Boston local)

IRC chat (logged): #html2-wg on irc.w3.org port 6665 or port 80

Zakim Bridge: +1.617.761.6200, conference 48652 ("HTML2")

Minutes: [To be supplied]

=== Day 2 Room 1 ===

* 09:00-09:30: MLW-LT
* 09:30-10:30: I18n Core (16 bugs!) and Bugs 15278 & 16965 - Localization hints
* 10:30-11:00: -- Break --
* 11:00-12:30: Preparing for entry to CR and WG status
** Formal Objections
** Features at Risk
*** scoped stylesheet
** CR Exit Criteria
** Status of CR Working Drafts
** HTML 5.1 planning
* 12:30-14:00: -- Lunch --
* 14:00-14:30: CR minimum
* 14:30-15:00: xml-stylesheet
** Bug 14689 xml-stylesheet with type=text/xsl needs to be handled explicitly (5-10 minutes with XML Core)
* 15:15-15:30:
** Maincontent element (FPWD request)
* 15:30-16:00: -- Break --
* 16:00-17:00: Testing: status, plan
* 17:00-17:30:
** Completing ISSUE-204 (10-15 minutes)
** Tracker Requests
*** Drag-and-drop processing model (might overflow?)
** Alt Guidance and Alt text in the HTML5 Document Part 1: Analysis of Guidance
** Other FPWDs

Minutes: http://www.w3.org/2012/11/02-html-wg-minutes.html

=== Day 2 Room 2 ===

* 09:00-18:00: Not used

Minutes: [To be supplied]

ExtensionSpecifications

Sruby — Thu, 27 Sep 2012 13:04:13 GMT

Rberjon: /* HTML WG */

The following are a list of [http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#extension-specs extension specifications] that are actively being developed. Some of these may be [http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#cr-integration integrated during the Candidate Recommdation] phase of HTML 5.0, others may integrate later, and some may proceed independently indefinitely.

Want to write one? Read [[ExtensionHowTo|How to Write an Extension Specification]].

== HTML WG ==

* [http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Encrypted Media Extensions]
* [http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html Media Source Extensions]
* [http://dev.w3.org/html5/srcset/ The srcset attribute] - [http://usecases.responsiveimages.org/ Use Cases]
* [http://picture.responsiveimages.org/ The picture Element] - [http://usecases.responsiveimages.org/ Use Cases]
* [https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/region.html#extension-of-the-html-texttrack-api TextTrackRegion API] - [http://lists.w3.org/Archives/Public/public-html/2013Feb/0210.html Use Cases]
* [http://www.w3.org/2003/entities/2007doc/xhtml-pubid.html Public Identifiers for entity resolution in XHTML]
* [http://cameronjones.github.com/form-http-extensions/index.html Form HTTP Extensions] - [http://www.w3.org/wiki/User:Cjones/ISSUE-195 Rationale]
* [http://darobin.github.com/html-ruby/ HTML Ruby Markup Extensions] - [https://www.w3.org/Bugs/Public/show_bug.cgi?id=21040 Rationale for double-sided] - [https://www.w3.org/Bugs/Public/show_bug.cgi?id=21041 Rationale for inlining] - [http://www.w3.org/TR/ruby-use-cases/ Use cases] - [http://fantasai.inkedblade.net/weblog/2011/ruby/ More use cases] - [http://www.amazon.co.jp/gp/feature.html?ie=UTF8&docId=1000173306 Double-sided in a common book] - [http://lists.w3.org/Archives/Public/public-i18n-cjk/2012JanMar/0067.html Murata-san's desiderata]

== A11y TF ==

* [http://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longdesc.html longdesc] - [http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0478.html discussion]

== Former Extensions ==

* [https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html <main>] - [http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction Rationale and use cases] was folded into the HTML specification.

HTML5.0AtRiskFeatures

Sruby — Tue, 25 Sep 2012 20:48:15 GMT

Sfaulkne: /* HTML 5.0 */ removed details/summary as its getting implemnted in firefox and is already implemented in webkit/chrome

The following in an unordered list of features identified to be at risk for inclusion in the HTML 5.0 set of specifications. Over time this list may be refactored into multiple pages, with this page remaining for navigation purposes.

== HTML 5.0 ==

* [http://dev.w3.org/html5/spec/the-hgroup-element.html#the-hgroup-element <hgroup>]
* [http://dev.w3.org/html5/spec/the-command-element.html#the-command-element <command>] and [http://dev.w3.org/html5/spec/commands.html#commands commands API]
* [http://dev.w3.org/html5/spec/the-menu-element.html#the-menu-element <menu>] and [http://dev.w3.org/html5/spec/the-menu-element.html#context-menus context menus feature (“contextmenu” attribute)]
* [http://dev.w3.org/html5/spec/commands.html#the-dialog-element <dialog>]
* [http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#color-state-(type=color) <input type=color>]
* [http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-and-time-state-type-datetime <input type=datetime>], [http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#month-state-(type=month) <input type=month>], [http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#week-state-(type=week) <input type=week>], [http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#time-state-(type=time) <input type=time>], [http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#local-date-and-time-state-(type=datetime-local) <input type=datetime-local>]
* [http://dev.w3.org/html5/spec/the-output-element.html#the-output-element <output>]
* [http://dev.w3.org/html5/spec/the-style-element.html#attr-style-scoped <style scoped>]
* [http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless <iframe seamless>]
* [http://dev.w3.org/html5/spec/system-state-and-capabilities.html#custom-handlers Custom scheme and content handlers (registerProtocolHandler and registerContentHandler)]
* [http://dev.w3.org/html5/spec/headings-and-sections.html#outlines Outline algorithm]
* [http://dev.w3.org/html5/spec/rendering.html#links,-forms,-and-navigation UA mechanism for navigating to resources linked to in cite=""], see [https://www.w3.org/Bugs/Public/show_bug.cgi?id=18915 Bug 18915] for more.
* appcache (cf HTML f2f November 1 discussion)
* [http://dev.w3.org/html5/spec/constraints.html#form-submission-0 Form Submission Process] - method-based switch algorithm and javascript/ftp schemes
* [http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-area-media <a media>] and [http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#dom-a-media <area media>] - these media queries are not used
* [http://www.w3.org/html/wg/drafts/html/CR/single-page.html#scriptingLanguages e4x] - remove JavaScript with ECMAScript for XML (e4x) support, since all browsers have removed it

== HTML Canvas 2D Context ==

* [http://dev.w3.org/html5/2dcontext/#path-objects Path object in Canvas]
* [http://dev.w3.org/html5/2dcontext/#hit-regions Hit regions]
* [http://dev.w3.org/html5/2dcontext/#dom-context-2d-setlinedash Dashes]
* [http://dev.w3.org/html5/2dcontext/#textmetrics Text metrics]
* [http://dev.w3.org/html5/2dcontext/#dom-context-2d-ellipse Ellipse]

FullSemantics

Lsilli — Sat, 04 Aug 2012 00:15:06 GMT

Lsilli: formatting once more ...

<p>Change Proposal by Leif Halvard Silli‚<br>for
[http://www.w3.org/html/wg/tracker/issues/206 ISSUE-206 meta-generator].<br>The location of this CP: [http://www.w3.org/html/wg/wiki/TitleKeyContentMark http://www.w3.org/html/wg/wiki/TitleKeyContentMark]<br></p>
<h1>Recognize no-<code>alt</code>
<code>img</code> elements with a <em>key-content mark</em> in the <code>title</code> attribute</h1>

<h2> Summary </h2>
<p> Where the <code>alt</code> attribute has been omitted, the presence of
a non-empty <code>title</code> attribute has a very positive effect on <code>img</code>
elements with regard to whether the images get presented to end users or not. Not only does HTML5 (and ARIA) tell UAs and ATs to <em>do</em> make
use of <code>title</code> in that situation, but testing shows that there
is also [http://malform.no/testing/html5/img-role-vs-alt/ a long and broad support] for this as well. In fact: A no-<code>alt</code> <code>img</code>
element with the <code>title</code> attribute set, has almost the same
level of AT support as <code>img </code>elements with a non-empty <code>alt</code>.</p>
<p>By contrast, when both <code>alt</code> and <code>title</code> are omitted, then ATs (in particular [http://malform.no/testing/html5/img-role-vs-alt/ JAWS, NVDA, VoiceOver+Firefox nighlty + VoiceOver when image don’t load]) treat the image as if it had the <code>alt</code> attribute set to the empty string.</p>
<p>Therefore, for the use case of a markup generator in lack of alternative
text for a <em>key-part-of-the-content</em> image, HTML5 should recommend
developers to make their markup generators check for presence of the <code>title</code>
attribute. When there is a no non-empty <code>title</code> present, the
generator should add one — and fill it with a <em>key-content mark</em>.</p>
<p>A <em>key-content mark</em> is a carefully selected white-space
character combination whose presence has the effect that <strong><em>— a
—</em></strong> it allows ATs and UAs to securely assume the image to
be key content and thus secures that the image presence is made known to the user and <strong><em>— b —</em></strong> makes the page formally
validate. (The carefulness with regard to the choice of white-space characters, relates to the <em>key-content mark’s</em> effect on ATs as
well as to whether it prevents or causes the <code>title</code> tooltip
from displaying on hover or not.)</p>

__TOC__

<h2> Rationale </h2>
<h3>Alternative text — ideals and reality</h3>
<p>The ideal alternative text is contextual — adapted for the particular image. For that reason, it is also often assumed that the ideal alternative text has to be unique. However, the uniqueness expectation might be somewhat unrealistic/exaggerated — e.g. consider a photo album where many of the motifs are similar .</p>
<p>But reality is that authors consider the uniqueness ideal as to difficult and too much work and thus often resort to dummy text and that the motivation for doing so is linked to HTML’s traditional syntactical requirement — that there <em>must</em> be some kind of alternative text, empty or non-empty, for validity. However, it would be wrong to say that it is <em>purely</em> linked to the validity question as authors know that the validity question in turn is linked to the accessibility question.</p>
<p>The use of dummy text does however result in problems. Let us evaluate its 3 variants:<br></p>
<ul></ul>
<ol>
<li>The empty string as dummmy text has the problem that HTML5 formally
attributes its semantics to be equivalent of <code><img
role=presentation></code>. Thus, this method silences both
validators and screenreaders.</li>
<li>The non-empty dummy string solution, may cause user confusion: Screenreaders — and at least some user agents (e.g. Opera when the <code>alt</code> is omitted) already make use of “dummy texts” (such
as “image” or “graphic”) when they present a loaded or (in particular) non-loaded image to their users. And it is therefore not useful to repeat
the same announcement as alternative text as wel. Another problem with non-empty dummy text is that it is (usually) tied to a single
language. In contrast, the announcements of an AT or UA typically changes with the locale.</li>
<li>A special — and language indpedendent! — variant of the non-empty dummy text would be a white space
filled <code>alt</code>. For instance, one could place the <em>key-content
mark</em> (aka “white-space”) directly in the <code>alt</code> attribute. This would have the advantage that it would silence the validator while not silencing screenreaders. Screenreaders would instead use their built-in announcement text to announce the image, and there would be no repetition. However, while
this would work OK in all the screenreaders tested while writing this proposal, it would interfere with ATs and UAs ability find a better way to present the image to the user. For instance, it would make Opera <em>not</em> render its <code>alt</code> repair text and instead render a white-space character as the image representation. Hence, the spec does understandably not endorse this method.<br></li></ol>
<ul>
<ul></ul></ul>
<p>As a conclusion, we could say that, fo<code><em></em><em></em></code>r <em>key-part-of-the-content</em> images, then none of the dummy alternative text methods are recommendable.<br></p>
<p>However, when one creates a markup generator for use by third parties, it becomes necessary to have a strategy for solving the use case of an <code>img</code> for which the third party failed to add alternative text. And the advice of the spec is that markup generators simply omit the <code>alt</code> attribute.<br></p>
<p> This advice has thus to be understood on the
background that the spec, for the condition that <em>“the src attribute
is set and the alt attribute is not“</em> (see the paragraphs on
“[http://dev.w3.org/html5/spec/the-img-element.html#img-good what an img element represents]”), describes what it represents and tells UAs and ATs to, in such cases, offer <em>“some
sort of indicator that there is an image that is not being rendered”</em>.</p>
<p>So in theory, the dropping of the <code>alt</code> does solve the
problems related to the non-empty dummy string, since the omission of the <code>alt</code>
attribute is supposed cause the image to be presented with the AT’s built-in dummy text — and nothing more. Thus, in theory, such an image would be handled by AT the same way they handle an image with a white-space filled <code>alt</code> (the third option above).<br></p>
<p>
</p><p>Reality is, however, that<strong> — on one side —</strong> UAs indicate the lack of image even for <code>img</code>
elements with the <code>alt</code> set to the empty string. And <strong>— on the other side —</strong> that many ATs treat no-<code>alt</code> images like they treat empty-<code>alt</code> images: They ignore them. (See [http://malform.no/testing/html5/img-role-vs-alt/ the test page mentioned in the summary].) Why do they ignore them? Is it because [https://developers.google.com/webmasters/state-of-the-web/2005/elements 25% of <code>img</code> elements are lacking the <code>alt</code> attribute]? Or is it <em>only</em> because they have not gotten around doing The Right Thing™ yet?<br></p>
<p>At any rate: The degree to
which the cited spec text can be taken to mean that no-<code>alt</code> <code>img</code> elements should be given special treatment, could be disputed. For example, it is not a particular strong statement when the spec says that a such image <em>“<strong>might be</strong> key
part of the content”</em> and that the lack of the <code>alt</code>
attribute <em>“<strong>indicates</strong> that the image is a key part of
the content”</em>. <br></p>
<p>Whatever the reason: A fundamental issue with the spec’s current advice to markup generators is that the lack of <code>alt</code>
does, generally, [http://malform.no/testing/html5/img-role-vs-alt/ <em>not</em> cause images to be presented]. Which in turn begs the question about whether it wouldn’t be better to evaluate the 3 dummy alternative text options above and pick the least bad method?<br></p>

<p></p>
<h3> The <em>key-content mark</em> advantage </h3>
<p>The spec does, however, say that when a no-<code>alt</code> image has a
non-empty <strong><code>title</code></strong> attribute, then the <code>title</code>
represents the image's textual content. And [http://malform.no/testing/html5/img-role-vs-alt the cited tests] show the
back-compatibility story of no-<code>alt</code> <code>img</code> elements <em><strong>with</strong></em> a non-empty <code>title</code> to be <em>almost on par with</em> <code>img</code>
elements with a non-empty <code>alt</code> attribute present!
[http://malform.no/testing/html5/img-role-vs-alt The cited testing] also showed that the discoverability of such images can be further improved by adding
<code>role=img</code> to them (hint: VoiceOver, when images fail to
load).</p>
<p> Which is why this CP proposes the spec to include the <code>title</code>
attribute in its microformat for no-<code>alt</code> <code>img</code>
elements: </p>
<ol>
<li>When a <code>title</code> with the <em>key-content mark</em> is
present, then ATs are triggered to announce the image using the AT’s built-in dummy text — and nothing more. Thus <code>title</code> plus <em>key-content
mark</em> causes what the spec suggests to actually become a working
reality.</li>
<li>To use the <code>title</code> rather than the <code>alt</code>,
means that we don’t interfere with the role of the <code>alt</code>
attribute. And neither do we meddle with the AT or UA’s strategy for repairing for lack of <code>alt</code>.</li>
<ul>
<li>For instance, the <em>key-content mark</em> ought to not interfere
with how text browsers tend to render the file name whenever the <code>alt</code>
is lacking. <br></li>
<li>And, in contrast to adding the <em>key-content mark</em> (aka
‘white-space characters’) in the <code>alt</code> attributite, adding
in the <code>title</code> attribute ought not cause the image’s
presence to become hidden the way it happens in textual browsers and GUI browsers if the <code>alt</code> attribute contains a space
character.</li></ul></ol>
<p>Thus, the main advantage of the markup generator advice of the <em>key-content mark</em> proposal is that it improves the way the spec’s current advice to drop the <code>alt</code> altogether — making it reliable for all (the tested) ATs.</p>
<h3> Important design details</h3>
<p> This CP takes into account several findings about AT and UAs and how they react to
the contet of the <code>title</code> attribute:</p>
<ol>
<li>For <code>alt</code> and <code>title</code>, when their content is a
single character, then VoiceOver — at least when used with Safari — supports a “microformat” where it, instead of <em>“reading”</em> the
single (white-space) character (thus: representing it with silence), presents it with its Unicode name (e.g. it may say “zero width space” if
the attribute’s sole content is a single ZERO WIDTH SPACE character). However, when there are more than a single white-space character present, <em>then</em>
it “reads”/represents it normally.

<ul>
<li>It thus makes sense ot say that the <em>key-content mark</em> should consist of <em>two</em> white-space characters.</li></ul> </li>
<li>[http://malform.no/testing/html5/img-role-vs-alt Testing also showed] that VoiceOver currently treat an image with a non-empty <code>title</code> as key content <strong>only</strong> if the element’s graphic did load and <strong>only</strong> if CSS generated content does not replace the graphical content. (This is evident from the above cited test page — but [http://malform.no/testing/html5/img-role-vs-alt/keycontentmarks another, shorter test page] perhaps makes it simpler to see.) Thus, if the graphic did not load or was replaced with non-graphic content via CSS, then VoiceOver fails to announce it as an image. However, if one adds <code>role=img</code> to the <code>img</code>, then VoiceOver will announce it as an image also when the image did not load/were replaced via CSS.

<ul>
<li>The CP thus<em> recommends</em> generators to add <code>role=img</code> as well. (I did consider a <em>must</em>, but some seems to be very opposed to requiring the role attribute. And also, strictly speaking, this is a VoiceOver bug. Plus that it might be relevant to use another role than <code>img</code> as well.)</li></ul> </li>
<li>It could seem quite natural to simply define an instance of two <em> SPACE</em> characters (U+0020) as the <em>key-content mark</em>. However, this turns out to have a back-compatibility story without a happy end: When used together with <strong>Firefox</strong>, then <strong>NVDA</strong> and <strong>JAWS</strong> treat <code>title="<SPACE>"</code> as equal to <code>title="<THE EMPTY STRING>"</code>. Meaning that the <code>title</code> presence would not have the desired effect of making them announce the presence of the image. <strong>Jaws</strong> does in fact have this problem even together with Internet Explorer. Finally, with the exception of Firefox <em>(which never display a tooltip whenever it perceives the content to be white-space!)</em>, the SPACE character <strong>always results in a visible tooltip</strong>. (In fact, quite a few of the other of the “normal” white-space chars, like the no break space, have similar issues.)<br></li>
<ul>
<li>The CP does thus <strong>not recommend</strong> to use the SPACE character as the <em>key-content mark</em> character.<br> </li></ul>

<li>Finally one has to consider whether the whitespace in the <code>title</code> attribute results in a visible tooltip that designers might react against. Extensive testing showed the MONGOLIAN VOWEL SEPARATOR character (U+180E) to be one of the few (perhaps the only) character to cause an invisble or near invisible tooltip in 4 current browsers: Firefox, IE9, Chrome and Safari. Alas, in the prerelease of IE10, any character causes a visible tooltip. And also, in Opera the tooltip was noticable. And also, while a SPACE character (which cannot be used for other reasons – see above) would have caused Lynx to render the file name, the Mongolian vowel separator causes Lynx to use the <code>title</code> — thus, a space character — as fallback text, which is not quite ideal. Fortunately, the story is a little better in the text browser W3M, Links, Elinks and netrik. Thus, the file name is not used as image indicator in Lynx when this character is used as <em>key-content mark</em>. However, both Lynx — Opera and IE10 — should arguably improve their performance if they would implement the semantics of the Mongolian vowel separator. Thus this character ought to be a “future safe” choice. And at any rate the problem is fixable via JavaScript. For example, the following script empties the title attribute on hover, if and when it contains two Mongolian vowel separators (also known as the <em>key-content mark</em>):<br>
<pre style="display:table;;margin:0.3em;padding:0.33em 1em;"><script>
function change_title(elem, attr) {
var elems = document.getElementsByTagName(elem);
for (var i = 0; i < elems.length; i++)
elems[i][attr] = elems[i][attr].replace(/^\u180E\u180E$/, ''); }
window.onmouseover = function() {
change_title('img', 'title');
}
</script></pre>
<ul>
<li>The CP thus proposes two MONGOLIAN VOWEL SEPARATOR characters
(U+180E) as the <em>key-content mark</em>.</li></ul></li>
<li>The Firefox behavior, where it doesn’t display a tooltip whenever it perceives the content to be solely white-space, seems worth keeping. If all UAs behaved that way, then we could eventually also pick a more easily typed <em>key-content mark</em>.<br></li>
<ul>
<li>The CP does thus propose that the editors, if they agree, requires browsers to not display a tooltip whenever the content is a white-space.<br></li></ul></ol>
<p><strong>NB!</strong> In case for instance the [http://www.w3.org/International/core/ Internationalization Working Group] would identify problems with using the MONGOLIAN VOWEL SEPARATOR character (U+180E) for the <em>key-content mark</em>, then, as long as the problems with choosing another character are evaluated and as long as the positive effect on ATs is not lost, this CP is by no means locked to this particular character. And, thus, just for the record, on [http://malform.no/testing/html5/img-role-vs-alt/keycontentmarks test page with some of the alternatives], there are some other “hot”, potential characters — none of which, however, seem to have quite as broad support as the proposed character.<br></p>
<h3>The alternative proposals</h3>
<h4> The spec’s current solution </h4>
<p> As told: When alternative text for a <em>key-part-of-the-content</em> image is lacking, the spec recommends markup generators to “[http://dev.w3.org/html5/spec/the-img-element.html#guidance-for-markup-generators omit the <code>alt</code> attribute altogether]”. If the [http://dev.w3.org/html5/spec/the-img-element.html#guidance-for-conformance-checkers a <code>meta</code> generator string in the <code>head</code> element] is present as well, then the possible validation errors resulting from the omitted <code>alt</code>, are suppressed too. Which is a solution with several problems:</p>
<ol>
<li>It adds a meaning for the <code>meta</code> generator string that has
nothing to do with the reasons for why generators inserts in the first place — the problems of which has caused ISSUE-206 to be reopened.</li>
<li>It does not discern between images that are the sole content of a link
and other key-part-of-the-content images. Thus, despite that the spec describes how to generate alternative text for sole-content-of-a-link
images, validators are forbidden from reporting failure to do so as an error.</li>
<li>And, most importantly: Because many ATs and UAs [http://malform.no/testing/html5/img-role-vs-alt in fact treat such images like they treat images with the <code>alt</code> set to the empty string], the spec’s solution is currently almost equivalent to inserting an empty <code>alt</code>. Thus, it is a solution that does
very little for endusers. This is the case for NVDA and JAWs. But also — if the image fails to load — for VoiceOver. Even Firefox has a tendency
to hide such images whenever th image doesn‘t load. (This is due to its bugs related to the broken image icon, which tends to not render unless
one adds a proprietary <code>img:-moz-broken{}</code> CSS rule for it.)</li></ol>
<p> Thus, the assumption of some, that there is a good back-compatibility
story if the <code>alt</code> attribute is omitted, is a truth with many
modificatiions.</p>
<h4> The relaxed/incomplete attribute proposal</h4>
<p> Two other change proposals suggest minting a new attribute — <code>incomplete</code>/<code>relaxed</code>
– for such images. These proposals have a number of problems: </p>
<ol>
<li>They go against the established practice of using dummy strings —empty
or non empty— to silence the validator. </li>
<li>Their solution purely affects validation — and thus does<em> not</em>
improve anyting for end users.</li>
<li>They build heavily on the <em>no <code>alt</code></em> pattern,
the semantics of which is not very well understood: ATs and UAs do often [http://malform.no/testing/html5/img-role-vs-alt/ treat such images as if the element had an empty <code>alt</code>]. But it is also quite difficult to author with no-alt. For example, the developer of the BlueGriffon editor has said that he does not intend to allow users to enter no-alt — they must enter empt or non-empty alt.</li></ol>
<p> In a summary: These proposals’s independence from the <code>meta</code>
generator string give them an important validation advantage. But they have no <em>direct</em> effect on endusers. And hence they are, in this
detail, equal to the spec’s current microformat.</p>
<h2> Details </h2>

<p>In §4.8.1.1.12 "Guidance for markup generators," <strong>replace</strong>
<em>“or omit the alt attribute altogether, under the assumption that the
image is a key part of the content”</em> with the following:</p>
<blockquote>
<p>or, unless a <code>title</code> attribute already is present, add a <code>title</code>
attribute with a <em>key-content mark</em><code></code> and omit the <code>alt</code>
attribute altogether, under the assumption that the image is a key part of the content. <br>
<br>
NOTE: For improved compatibility, it is recommend to add a <code>role</code>
attribute of value <code>img</code> as well.<br>
<br>
NOTE: The <em>key-content mark</em> is a white space character
combination that has as its only task to cause user agents and assitive technologies to perceive a non-empty <code>title</code> attribute to be
present, the reason being that some technologies are known to not present <code>img</code> elements whose <code>alt</code> attribute has
been omitted to the user unless there is a non-empty <code>title</code>
attribute as well. Currently, the <em>key-content mark</em> is
considered to consist of <em>two</em> MONGOLIAN VOWEL SEPARATOR
characters (U+180E) as this character in the majority of current user agents does not cause a visual <code>title</code> tooltip to be
produced. </p>
</blockquote>
<p>In §4.8.1.1.13 "Guidance for conformance checkers," replace the second
bullet (which starts with "The document has a meta element…") with the following text:</p>
<blockquote>
<p>Unless the image is
[http://dev.w3.org/html5/spec/the-img-element.html#guidance-for-markup-generators the sole content of a link], then a missing <code>alt</code> attribute
on an <code>img</code> element where there is a <code>title</code>
attribute whose content is the <em>key-content mark</em>, shall not
count as an error. However, except when other rules apply, then conformance checkers SHOULD make users aware that these elements are
likely to be in lack of alternative text.</p>
</blockquote>
<p>Depending on the outcome of [https://www.w3.org/Bugs/Public/show_bug.cgi?id=18555 bug 18555]</p>
<ul>
<li>Add spec text to require a Firefox inspired behavior from all browsers: If white-space is the sole content of the <code>title</code> attribute, then the tooltip should be suppressed.<br> </li></ul>

<h2>Impact </h2>
<h3> Positive Effects </h3>
<ul>
<li>We improve the situation a tiny bit for end users by making the no-<code>alt</code> situation work in more assistive technologies.</li>
<li>We no longer imbue <code><meta name=generator></code> with effects incompatible with its historical and deployed usage;</li>
<li>The rule applies also to non-generators. This is good because, just as there is no definition of handcoding, there is no definition of "generators". For example, if one uses an advanced text editor to create a large image site, then one may make heave use of a find and replace tool that bears strong resemblence of a generator. It is not intuitive that one shall have to add a meta generator before the <em>key-content mark</em> in the <code>title</code> attribute may make an <code>img</code> element valid.</li>
<li>We enable engineers of large Web applications to catch markup errors that they can do something about, without bothering them about markup errors they can't do anything about.</li>
<li>We build on the semantics of the attributes we have, instead of introducing new ones.</li>
<li>We build upon existing AT behavior: Screenreaders already treat images with a no <code>alt</code> as significant <em>provided</em> that there also is a non-empty <code>title</code> attribute.</li>
<li>We refine the img element's semantics.</li>
<li>A simpler rule for authors/developers: It is simpler to understand a rule which says that something good will happen if you <em>add</em> something — compared with a rule which says that something good happens if one omits something.</li>
<li>The solution may be perceived as a little bit complicated and involved givent that the character of the <em>key-content mark</em> is a seldomly used (outside the Mongolian context) used, non-spacing white-space character and also due the possible tooltip effects in some few browsers. But this can be a good thing as it increases the chance that it is done on purpose. Also confer the arguments in favor of a relaxed/incomplete attribute with an exceedingly long name just to make it inconvenient to use.</li>
<li>Except for when it contains the <em>key-content mark</em>, this CP does not touch the working group decision about the general non-conformance of <code>img</code> elements with no-<code>alt</code> but which has a non-empty <code>title</code> attribute instead. It seems defendable to deviate from that decision in this case since the <code>title</code> attribute with a <em>key-content mark</em> has a well defined semantics and good support (in fact, better support than what the spec and the alternative proposals have).<br></li>
<li>When present, then the authors do not need to think about it more: They can, later on, add an <code>alt</code> attribute, if they wish. Or they can add stuff to the <code>title</code> itself. It doesn’t disturb anyone.<br></li></ul>
<h3> Negative Effects </h3>
<ul>
<li>For assistive technologi users: <strong>no known negative effects</strong></li>
<li>For Firefox: <strong>no known negative tooltip effects</strong> (as the <em>key-content mark</em> causes no tool tip)<br> </li>
<li>For IE9, Chrome and Safari: <strong>a negligible negative tooltip effect</strong> (in the form of an extremely small (Chrome/Safari/IE9) and hidden (IE9) tooltip).</li>
<li>For Opera and IE10: A visible tooltip, which authors may feel they need to fix (with JavaScript), which should be OK to do.</li>
<ul>
<li>Given that the <em>key-content mark</em> (<code>&#x180e;&#x180e;</code>) is made up of <em>invisible</em>, non-spacing character, this has to be considered a bug.<code></code><code><br> </code></li></ul>
<li>For text browser users: When Lynx is set to render content as UTF-8, then it renders the MONGOLIAN VOWEL SEPARATOR as a space character rather than (as it does if the SPACE characer is used) falling back to the file name — which is slightly unexpected and confusing.</li>
<ul>
<li>(Though, actually, for Lynx, the behavior depends on whether it is set to use the ISO-8859-1 encoding - in which case the Mongolian vowel separator <em>does</em> cause the file name to be rendered, or the UTF-8 encoding — in which case it currently renders as a space.)</li></ul>
<li>For Webkit/Chromium browsers: These tend to render the <code>title</code> attribute as the alternative text whenever <code>alt</code> is omitted.</li>
<ul>
<li>Thus they would render the <em>key-content mark</em> as the textual content of the image. On the other side: These browsers also renders a broken image icon, thus sighted users will nevertheless see the image. <br> </li>
<li>Thus, if the <code>title</code> had been omitted, Webkit/Chromium users would have seen the very same thing. Which means that this CP should not affect Webkit/Chromium users.<br> </li></ul>
<li>If typed directly, then the <em>key-content mark</em> is, for the eye, inseparable from the empty string.</li>
<ul>
<li>Authors should use insert it using a numeric character reference: <code>&#x180e;&#x180e;</code><br> </li></ul>
<li>This CP does not solve the following use case: <code><img title="Advicory text" src="i">.</code> That is: For the use case of a no-<code>alt</code> <code>img</code> element with a <code>title</code> attribute whose content is something <em>other</em> than the <em>key-content mark</em>, then such elements remain invalid (unless other rules, such as presence inside the <code>figure</code> element, make them valid).</li>
<ul>
<li>This disadvantage cannot be said to important. (Further more, if validity is a concern, a markup generator could in such a case duplicate the <code>title</code> content in the <code>alt</code>.)<br></li></ul></ul>
<h3> Conformance Classes Changes </h3>
<ul>
<li>This change alters the following conformance classes:

<ul>
<li>Conforming documents,</li>
<li>Conformance checkers, and</li>
<li>Authoring tools and markup checkers.</li>
<li>Assistive Technology.</li></ul>
</li></ul>
<h3> Risks </h3>
<ul><li>That authors finds the resulting tooltips intolerable.</li></ul>
<h2> References </h2>
<p></p>
<ul>
<li>Extensive test page to see the effect of the <code>title</code>
attribute and other attributes on ATs and UAs: [http://malform.no/testing/html5/img-role-vs-alt http://malform.no/testing/html5/img-role-vs-alt]</li>
<li>Test page with <em>key-content mark</em> alternatives:
[http://malform.no/testing/html5/img-role-vs-alt/keycontentmarks http://malform.no/testing/html5/img-role-vs-alt/keycontentmarks]</li>
<li>For referenes to HTML5, see links inside the text.<br>
</li></ul>
<p></p>
<h2> Contributors </h2>
<ul>
<li>Leif Halvard Silli,<br>
with thanks for the input on my first CP, especialy from John Foliot and Benjamin Hawkes-Lewis.</li></ul>

ChangeProposals/hitregions

Sfaulkne — Thu, 12 Jul 2012 10:05:27 GMT

Sfaulkne: /* Additional rationale for addHitRegion and the Path object */

[[Category:ChangeProposal]]
[[Category:Issues]]

= Provide for canvas location and hit testing capability with an exposed Path object and related alterations to the 2d Context API =

== Revision of [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-201 Ted Oconnors proposal]==

'''Editor:''' Steve Faulkner

== Summary ==

As stated in [http://www.w3.org/wiki/Canvas_hit_testing the other Change Proposal for ISSUE-201]:

<blockquote cite="http://www.w3.org/wiki/Canvas_hit_testing"><p>A new hit testing method should be added to canvas elements to simplify hit testing and solve accessibility issues inherent to the fallback DOM concept.</p><p>Canvas authors are starting to create more complex user interface in canvas that can only could only <nowiki>[sic]</nowiki> map to several underlying elements (<nowiki>[a]</nowiki> spline editor, for example, would map to several range controls). To enable a better canvas+fallback DOM coding pattern, it seems prudent to enable easier canvas hit testing and event handling.</p><p>In the current HTML5 specification, authors are advised to create a fallback DOM under the canvas element to enable screen readers and screen magnifiers to interact with canvas user interfaces. The size and position of those elements are not defined, which causes problems for accessibility tools - what size/position should they report for these elements?</p><p>Because canvas elements usually respond to user input, it seems prudent to solve the hit testing and accessibility issues with the same mechanism.</p></blockquote>

This is for [http://www.w3.org/html/wg/tracker/issues/201 ISSUE-201 (canvas-fallback)].

__TOC__

== Rationale ==

=== Rationale common to both proposals ===

From [http://www.w3.org/wiki/Canvas_hit_testing the other Change Proposal for ISSUE-201]:

<blockquote cite="http://www.w3.org/wiki/Canvas_hit_testing">
Authors will create two kind of canvas user interfaces:

# Simple canvas user interfaces that map well to a single regular input element
A canvas checkbox (http://www.htmlstack.com/checkbox/ ) is the quintessential example here. A canvas bitmap is represented by a single checkbox in the DOM.
# Complex canvas user interfaces that maps to several regular input and static elements
Authors will create canvas UIs that contain multiple complex visual input controls that should map to several regular elements in the fallback dom.)
<br>
<br>
(Examples: See the customize-timing-function canvas UI in http://ie.microsoft.com/testdrive/Graphics/hands-on-css3/hands-on_transitions.htm.
<br>
<br>
These user interfaces don't match well to regular input controls - which might be why the author chose to use canvas.
<br>
<br>
Also, screen magnifiers must be able to determine the location of fallback elements rendered on the physical canvas in order to be able zoom to these elements whether or not they have focus. Also, screen readers need the location of these objects to assist in placing accessibility information such as text and role on a line in a refreshable Braille display.
<br>
<br>
The best approach to solving the accessibility issues in these complex canvas user interfaces would be to map the location of the individual user interface elements in the canvas bitmap to multiple tabbable/focusable/etc input elements in the fallback DOM. We should enable authors to easily define hit testing regions on the canvas and map events to the underlying elements in the fallback dom. This will reduce author burden, and also solve the issue of reporting meaningful position+size information to assistive technologies and accessibility test tools. It should be noted that this is not a new concept and the use of hit testing to bind location information to accessibility API has been and continues to be used on every desktop GUI today that supports accessibility services.
</blockquote>

=== Additional rationale for addHitRegion and the Path object ===

DOM elements are expensive and can negatively impact the performance of Web applications when created in large numbers. Relying on the fallback DOM for hit testing is problematic when <code><canvas></code> is being used to represent something that would require a very large number of DOM elements to acheive an equivalent representation. In such cases, it should be possible to hit test and provide location and size information to AT while not bearing the performance and memory costs of an excessive number of DOM elements. The proposed <code>addHitRegion()</code> method allows for tying hit regions to either elements ''or'' to lightweight objects which simply provide a label and a WAI-ARIA role. This helps authors to make their canvas content accessible without incurring an unacceptable performance penalty.

'''''ADDED start'''''

As the 'lightweight objects which simply provide a label and a WAI-ARIA role' are not focusable and cannot have author assigned states and properties, the allowed ARIA roles should be limited to a subset of the non interactive ARIA roles that do not require or benefit from the addition of states and properties.

For example, A region with role=button could not be considered accessible unless it is able to receive focus.
Or a role=checkbox has a required state of aria-checked, and must be able to recieve focus for device indepedent operation, so it makes no sense to allow authors to assign such roles on lightweight objects.

'''''ADDED end'''''

It should be easy for authors to hit test text drawn onto <code><canvas></code>, and also to provide location and size data to AT. A text and font metrics API allows designers to acheive many interesting effects on text while simultaneously enabling hit testing and other A11Y needs.

Having an exposed Path object and encouraging authors to use such Path objects for describing hit regions helps authors to write accessible and maintainable canvas applications. Authors use the 2d context object's current default path for drawing operations, and the 2d context API is designed around the assumption that the current default path is used solely for drawing. Using the current default path to create paths used not for drawing but only for hit testing is awkward; it would be a cleaner, more comprehensible API for authors to be able to explicitly create a hit testing path without pretending that it will be used for drawing.

== Details ==

Re-apply the changes which were reverted by a request of the Chairs, namely the changes in r7023, r7024, r7028, and r7029.

Additionally, apply to the W3C version of the spec the related changes in r7037, r7038, and r7039.

Define a new method <code>removeHitRegion(object)</code> which disassociates any pixels associated with the given object. When invoked, this method must run the following steps:

# For each hit region in the canvas' hit region list, run these substeps:
## If object is the hit region's control or unbacked region description, invoke the <b>clear regions that cover the pixels</b> algorithm on the hit region's <b>set of pixels</b>.
# Return true.

'''''ADDED start'''''

In addition define the ARIA roles that many be assigned to unbacked hit regions:

'''ARIA role restrictions for unbacked hit regions'''

Unbacked hit regions cannot be focusable and cannot have the necessary states and properties assigned to adequately convey the semantics of interactive controls. Therefor authors may only assign the following roles using the addHitRegion() > role() method. For all interactive controls associate a hit region with an HTML element using the addHitRegion() > control() method.

'''subset of document structure roles'''
*article
*group
*note
*region
*separator

'''landmark roles'''

*application
*banner
*complementary
*contentinfo
*form
*main
*navigation
*search

'''''ADDED end'''''

Finally, apply any revisions necessary for the clean application of the above changes. I believe r7037 depends on the canvas transform work in r7035 and 7036, but determining which other revisions are required to make the above list of revisions workable is left to the discretion of the editor.

== Impact ==

=== Positive Effects ===

* Authors can use the microsyntax from SVG's <code><path d></code> to easily create paths, for hit testing or other purposes.
* Authors can easily draw dashed lines and ellipses.
* New text metrics allow authors to reliably know where text is drawn onto the canvas, for better hit testing and many other use cases.

==== Postive effects common to both proposals ====

<blockquote cite="http://www.w3.org/wiki/Canvas_hit_testing">
* Authors will have a standard method to implement hit-testing in their applications.
* Authors will have a standard method to define regions of interest on a canvas bitmap, improving accessibility for users.
* Allows a screen magnifier user to locate and zoom to any element rendered on canvas
* Allows a screen reader user with a Braille better fill a refreshable Braille display by using the coordinates supplied to place rendered objects on the same line facilitating a determination of what goes on line of Braille text.
* Allows assistive reading tools to speak the appropriate content when the user points to items on canvas.
</blockquote>

=== Negative Effects ===

None.

=== Conformance Classes Changes ===

* Existing implementations of the 2d Context API need to be updated to implement the new objects, interfaces, and methods.

=== Risks ===

* As with all author-facing features, if mainstream User Agents do not implement these API enhancements, we would need to drop them in the future.

== References ==

Most references are inline. See also [http://wiki.whatwg.org/wiki/Canvas the Canvas page on the WHATWG's wiki].

__NOTOC__

�

Local Variables:
mode: text
mode: longlines
End:

ChangeProposal/ISSUE-194/TranscriptURL V2

Jfoliot — Fri, 29 Jun 2012 17:01:59 GMT

Jfoliot: Created page with "= Introduction of a @transcript=URL attribute = Author: Media Subgroup of HTML Accessibility Task Force Discussions by: John Foliot, Janina Sajka, Edward O'Connor, Eric Carlson…"

= Introduction of a @transcript=URL attribute =

Author: Media Subgroup of HTML Accessibility Task Force

Discussions by: John Foliot, Janina Sajka, Edward O'Connor, Eric Carlson, Charles McCathieNevile, Silvia Pfeiffer

Editors: Silvia Pfeiffer, John Foliot

== Rationale ==

This is a proposal to address the need for programmatically linked video and audio transcripts in HTML5 through introduction of a @transcript attribute on HTML5 media elements that contains a URL (preferably an absolute URL).

It is based on an analysis of use cases for video transcripts as provided by [http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement#The_use_cases the TranscriptElement CP]. An [http://lists.w3.org/Archives/Public/public-html-a11y/2012Jun/0018.html agreement was reached] to leave support for interactive transcripts (UC3) to HTML.Next. Further, UC4 can be solved in the way suggested by [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B the transcript-IDREFs CP].

The remaining use cases are proposed to be solved by a combination of aria attributes and a new @transcript attribute for media elements (particularly for the embedding case).

__TOC__

== Summary ==

[http://www.w3.org/html/wg/tracker/issues/194 Issue 194] asks for a mechanism for associating a full transcript with an audio or video element.

In this CP we analyze the different use cases for transcripts and the need for programmatic linkage to the media elements. We then provide markup examples that solve the use cases, thus identifying the gap that remains to solve with new markup.

== The use cases ==

=== UC1: A full text transcript is provided with the media resource in a ''separate but linked resource''. ===

Examples:
* [http://www.centrelink.gov.au/internet/internet.nsf/individuals/baby_bonus_video.htm Centerlink AU Gov site]
* [http://www.pm.gov.au/videos PM Australia videos]

=== UC2: A full text transcript is provided as ''text on the same page'' of the media resource. ===

Examples of non-timed transcripts published underneath the video on-page:
* [http://www.state.gov/secretary/rm/2012/05/189592.htm US State Department]
* [http://www.manythings.org/b/e/5000/ ESL Videos]
* [http://foxnewsinsider.com/2012/05/04/video-transcript-hannity-takes-on-ows-organizer-in-explosive-interview/ Fox News]
* [http://www.commoncraft.com/video/rss RSS explained]
* [http://dotsub.com/view/ef3d7b6c-eab5-478a-a51c-d27166d27dcc Kony 2012 on DotSub]

Further, these use cases need to satisfy the requirements listed in the [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B#Requirements_from_the_TranscriptElement_proposal transcript-IDREFs CP].

== The Need of programmatic linkage between the video and its transcript ==

Before addressing the two mentioned use cases, it is important to understand what kind of programmatic linkage is desirable.

=== What is not desirable: ===
* rendering of the transcript inside the boundaries of the video player (e.g. as an alternative to the video or an overlay within the video boundaries) - there is not sufficient space and it removes the possibility to watch the video while reading the transcript.
* having a button on the video player that links away from the video to a page that doesn't also contain the video - it removes the possibility to watch the video while reading the transcript.
Example: http://www.pm.gov.au/videos (poor experience when following the off-page link)
* having a button on the video element that scrolls down to where the transcript is displayed - it takes the eyes off the video.

=== What is desirable/acceptable: ===
* the transcript is rendered outside the video player, e.g. in a different region on the same page near the video player.
Example: http://www.state.gov/secretary/rm/2012/05/189592.htm
* having a link underneath the video player that allows to download the transcript and read it in parallel to watching the video.
Example: http://www.pm.gov.au/videos (note the download link)
* having a button underneath the video player that opens a section of the Web page that contains the transcript nearby.
Example: http://dotsub.com/view/ef3d7b6c-eab5-478a-a51c-d27166d27dcc
* having a button on the video player that links to a page that contains the video itself with the transcript.
Example: almost all embeddable players link back to their original page where transcripts reside (e.g. YouTube, DotSub)
* having a button on the video player that unhides a section on the page to reveal the transcript nearby. Note that this use case is typically identical to the button underneath the video player, since the video player in this instance is made up of more complex elements that just look like they are part of the video player.
Example: http://www.ted.com/talks/lang/mr/eli_pariser_beware_online_filter_bubbles.html

== Analysis ==

Some trends are revealed in the above examples that influence the required linkage between video and transcript.

=== The majority of use cases shows a visible transcript on the same page as the video player. ===

This is the preferred publishing means of transcripts. It makes it easy for the user to consume the transcript together with the video. This works for all users.

There are some different ways of rendering included in this case:
* text in plain view
<video poster="poster.jpg" controls aria-label="video with transcript" aria-describedby="transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<p>
This is where the full transcript goes.
</p>

'''COMMENTS: this is a misappropriation of aria-describedby and will result in a horrible user-experience for non-sighted users today and in the immediate future. Currently, in screen readers that support aria-describedby the 'description' is concatenated to the other accessible data (i.e. accessible-name as provided by the aria-label). Even if a switching mechanism is provided that allowed for the end-user to query or not query the aria-describedby 'description', a Transcript is not a description of the media resource, it is an alternative rendering/format of the media resource. The description should describe the movie (for example, accessible name/label: "Oceans 11" accessible-description: "Danny Ocean (George Clooney) wants to score the biggest heist in history. He combines an eleven member team, including Frank Catton, Rusty Ryan and Linus Caldwell. Their target? The Bellagio, the Mirage and the MGM Grand. All casinos owned by Terry Benedict. It's not going to be easy, as they plan to get in secretly and out with $150 million." - and not " Scene 1: Rusty Ryan is seen walking across the room. ['yada yada yada'])'''

* text in plain view, but rendered from a separate html document
<video poster="poster.jpg" controls aria-label="video with transcript" aria-describedby="transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<iframe src="transcript.html">
</iframe>

* button toggles the text in/out with JS
<video poster="poster.jpg" controls aria-label="video with transcript" aria-describedby="transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<button id="transcript">Click to view transcript</button>
<div id="unhide_on_click" hidden>
<h4>Transcript</h4>
<p>
This is where the full transcript goes.
</p>
</div>

* link to open the transcript in a separate window/tab
<video poster="poster.jpg" controls aria-label="video with transcript" aria-describedby="transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<a id="transcript" target="_blank" href="transcript.html">Transcript (HTML)</a>

* link to download the transcript
<video poster="poster.jpg" controls aria-label="video with transcript" aria-describedby="transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<a id="transcript" href="transcript.doc">Download Transcript (doc)</a>

'''COMMENTs: All of these other examples repeat the problem of using aria-describedby as the means of linking the Transcript to the media resource programmatically, and so do not meet the user-requirements of non-sighted users (or any user relying on ARIA-aware technologies)'''

For the sighted user, there is no programmatic linkage required, since they can immediately discover whether a transcript is available or not and consume it adequately.

For the vision-impaired user, the screen reader should make an announcement that a transcript is available. This can be done using @aria-label and other accessibility-only attributes.

COMMENT: There is currently no ARIA attribute that solves this use case, nor any other "accessibility-only" attribute, which is why the @transcript proposal

''No new attribute is required to solve this use case.''

=== The use case where a video has a transcript, but not on the same page: typically happens when embedding ===

When a publisher decides to publish a video transcript and a video, there is always a page that contains both. Sometimes the transcript is behind a (download) link, but there is always a Web page that connects the two. This is covered above.

However, when such videos can also be embedded on other sites (like YouTube videos or DotSub videos), the video player can end up being the only thing that moves to the new page, because the publisher wants to avoid the space requirements.

The DotSub player has a version where a richer HTML snippet than just the video player is embedded and this richer HTML snippet also embeds the transcript. However, there is a video-only embed player and that doesn't have a link or reference to the transcript. The YouTube player similarly doesn't have a link to the transcript.

Both the DotSub and the YouTube video player, however, have a link on their video player that links back to the video's home page, which contains (amongst other things) the transcript.

In order for transcripts to remain discoverable in this situation, we need a means to take the link to the transcript along with the video into the new site. This may or may not result in a visual representation of the link in the video controls. In either case, it is important that the transcript remains discoverable.

''A new attribute is suggested to solve this use case: @transcript=URL .''

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://example.com/video.html">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>

The URL should preferably be an absolute URL, such that it survives embedding. It should preferably link to a page that contains the video and the transcript together - linking to pages that only contain the transcript should be avoided.

'''Rendering'''

The introduction of a new transcript attribute on media elements should create a transcript link that all users can use, since blind users and sighted users are affected equally.

Different options for rendering are:
* Browsers can decide to include the URL in the controls bar rendered of a video or audio element when player controls are active. This could be a button or could be a menu entry in a settings menu.
* Web developers should similarly be encouraged to add a link in any custom media element controls that they create.
* Browsers can decide to include the URL in the context menu of the media element.
* Screen readers should announce the availability of the transcript URL and provide the user with a means to follow the link.

Preferably all these options will be made available.

== Details ==

N.B. The spec changes described below are intended to fully describe the sorts of changes necessary, but the exact form of the changes to be made are left to the discretion of the editor(s). (This is not a diff that can be blindly applied to the specification. Should the editor(s) find this description difficult to apply unambiguously, the author of this Change Proposal volunteers to work with them and the WG to resolve any such ambiguities identified.)

=== New section on transcripts ===

Add a section defining the @transcript attribute.

Transcripts for media elements may be provided, either directly in the text of the page, indirectly by linking to an external document with an <a> element, or by transclusion with an <iframe> element.

Where a transcript or transcript link is not visible on the page, but still available - e.g. in the case of embedded video - a @transcript attribute on the media element may be used.

The @transcript attribute may be specified to indicate a different Web location at which a transcript for the media element is available. This should preferably be a Web page that also contains the video for a better viewing experience.

If the attribute is specified, the attribute's value is a URL.

=== Modifications to the-video-element and the-audio-element ===

* In [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#media-elements the media elements IDL] add:

<code>
attribute DOMString transcript;
</code>

* Add "transcript" to the list of common media element attributes below the IDL:

<code>
The media element attributes, src, preload, autoplay, mediagroup, loop, muted, controls, '''and transcript''' apply to all media elements.
</code>

* After section [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#user-interface 4.8.10.13 User interface] insert a section "4.8.10.14 Transcript" roughly containing the following:

<code>
The transcript content attribute on media elements gives the address of a Web resource that contains a text transcript for the media element. The attribute, if present, must contain a valid non-empty URL potentially surrounded by spaces.

The transcript IDL attribute on media elements must reflect the content attribute of the same name.

media . transcript<br>
Returns the address of the resource containing the transcript.<br>
Returns the empty string when there is no transcript address.
</code>

* Further non-normative text should be added along the lines of:

<code>
The transcript content attribute should preferably contain an absolute URL to a Web page that contains both the media element and the transcript in plain text. This will ascertain that users can consume the transcript together with the media element's content. An absolute URL further reduces the risk of loosing the reference when embedding the media element's code.
</code>

* Further non-normative text should be added [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-media-controls in the controls section] that encourages means of rendering:

<code>
This user interface should include features to begin playback, pause playback, seek to an arbitrary position in the content (if the content supports arbitrary seeking), change the volume, change the display of closed captions or embedded sign-language tracks, select different audio tracks or turn on audio descriptions, '''link to transcripts''' and show the media content in manners more suitable to the user (e.g. full-screen video or in an independent resizable window). Other controls may also be made available.

Even when the attribute is absent, however, user agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), '''and to link to a transcript''' but such features should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu.
</code>

== Impact ==

=== Positive Effects ===

* By programmatically associating transcripts with media elements, we enable users, both assistive technology users and otherwise, to more reliably be made aware of existing transcripts for media resources.

* It's easy to update existing content to use this markup pattern, so it's easy for authors to adopt this technique.

* Where multiple transcripts in different languages are available, the linked Web page should contain a means to select between the different transcripts and allow watching the video while reading one of the transcripts. This proposal builds on existing HTML features to make this possible.

* For UAs that don't support the <video> or <audio> elements, transcripts should be linked to inside the media element. Thus this proposal makes use of existing fallback mechanisms.*

=== Negative Effects ===

* An additional attribute is added to media elements, which browser vendors have to support.

=== Conformance Class Changes ===

* The @transcript attribute is allowed on <audio> and <video> elements.

=== Risks ===

* UAs might not implement this mechanism, thus causing us to drop it from the specification in due course. However, since video and audio elements have controls and UAs are in the process of implementing menus to support captions, audio descriptions, and chapters, adding an additional menu entry may not be as objectionable.
* Authors might not adopt this mechanism. Since the technique is simple, this risk is low.

== Obsoleting Change Proposals ==

This Change Proposal obsoletes the following CPs:

* [http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement Introduction of a <transcript> element] (1st media subgroup proposal)
* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP Introduction of a <transcript> element] (Silvia Pfeiffer)
* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_v2 Introduction of a new @kind value: "transcript"] (John Foliot)
* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194 Introduce a new attribute: @transcript] (John Foliot)
* [http://www.w3.org/html/wg/wiki/ISSUE-194/Option3B Reuse the rel and for attributes to programmatically associate transcripts with media elements] (Edward O'Connor)

These CPs may remain (TBD):

* [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B Mint a transcript attribute for the programmatic association of transcripts with media elements] (Edward O'Connor)
* [http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange Defer ISSUE-194 until HTML.next] (Silvia Pfeiffer/Edward O'Connor)

Original Bug:
* [https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964 Bug 12964] - <video>: Declarative linking of full-text transcripts to video and audio elements

Correct Hidden Attribute Section v4

Jfoliot — Tue, 26 Jun 2012 18:18:22 GMT

Jfoliot: /* Add */

= Correct the <code>hidden</code> Attribute Section =

__NOTOC__
<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; width: 70%; font-size:0.9em;">
*The following is a Change Proposal for [http://www.w3.org/html/wg/tracker/issues/204 HTML5 ISSUE-204 aria-hidden].
* Editor: John Foliot (Based on [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden Laura Carlson's proposal], [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions John Foliot's note], and [http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden Jonas Sicking, Matt Turvey, Edward O'Connor's proposal], as well as Versions 2 and 3 of the draft CP.
* This version reflects modifications to the V3 Change Proposal, based upon further [http://lists.w3.org/Archives/Public/public-html/2012Jun/0066.html feedback from Ted O'Connor]
* Date: June 26, 2012. (Last updated June 26th, 2012)
</div>

== Summary ==

Authors sometimes want to provide a label or description to users of Assistive Technology, and to do so without any visual encumbrance or default visual indicator. They can already do this with CSS <code>display:none</code> and <code>visibility:hidden</code>, and should be able to do the same with the simpler <code>@hidden</code> attribute. The ARIA spec allows <code>aria-describedby</code> and <code>aria-labelledby</code> to reference hidden elements, so this change will correct the [http://dev.w3.org/html5//spec-author-view/editing.html#the-hidden-attribute <code>hidden</code> attribute section] to bring it into conformance with the ARIA specification and ARIA functionality. In addition, this would make the behavior of <code>@hidden</code> consistent with the long-implemented behavior of CSS display:none and visibility:hidden with HTML <code><label></code> and <code>aria-labelledby</code>.
__TOC__

== Rationale ==
=== Use Cases ===

Web authors often wish to provide a description of a complex element only to screen reader users, while hiding the description from all other users. Being able to provide such a description without any forced visual encumbrance or default visual indicator is a frequently-cited accessibility requirement.

==== Example 1====
Consider the following markup:

<pre><pre role=img aria-describedby=foo >
)\._.,--....,'``. fL
/, _.. \ _\ ;`._ ,.
`._.-(,_..'--(,_..'`-.;.'
</pre>
<p id=foo hidden>An ASCII art rendition of a cat in prone position.</p></pre>

This example contains an ASCII art rendition of a cat inside a <code><pre></code> element. A description of the art is provided for AT users. By using <code>aria-describedby</code> to point at a <code>@hidden</code> element, the web page author avoids any forced visual encumbrance or default visual indicator.

==== Example 2 ====
<code>

<input aria-labelledby="foo" type=text><input type=image src="search.png" alt="Go!">
<div id="foo" hidden>Search</div>

</code>

In this example, a short plain-text string is used to label the text input, and that label is hidden from view. For visual users, the text box followed by a looking glass icon is a well-known visual pattern for a search function. The hidden label makes this clear to users who cannot see the text box or graphic.

==== Example 3 ====
<code>
<input aria-labelledby="foo" type="text" onmouseover="showFoo();" onmouseout="hideFoo();">
<input src="go.gif" type="image" alt="Go!">
<div id="foo" hidden><img src="decorative-image.gif" alt="">Search</div>

</code>

This example shows a variation of Example 2 where the label has a decorative image, and is shown to visual users onmouseover. Since the image gives no real information, it has null alt text. The hidden label is used to give the screen-reader user more information via the accessibility API, so that he does not need to navigate to the tooltip. The accessible name in the accessibility API tells him exactly what that text is for, where a popup tooltip would require more cognitive overhead. However, the popup tooltip, with it's pretty graphic, is shown to improve the experience of sighted users who are exploring the input. Since the screen-reader user does not use a mouse, and does not trigger the mouseover, he gets an experience that works for him, and the sighted user gets one that works for her. (Caveat: This is not a great piece of UI design for exploring an input by a sighted user. It is offerred as a simple example of where one might want to flatten the text for some users.)

The <code>@hidden</code> attribute is a mechanism for hiding elements in HTML. Given this, authors are likely to use it to hide content. The WAI-ARIA specification allows <code>aria-describedby</code> to point at non-visible content, so it is reasonable for authors to expect such markup to function properly. Because authors rarely run their content through conformance checkers, authors are likely to point at <code>@hidden</code> content from <code>aria-describedby</code> whether or not we forbid them from doing so. Therefore it is incumbant to document what can, and what cannot be achieved through these techniques.

=== Feedback from Browser Implementers ===

Two people working for browser implementers have suggested that exposing hidden elements in the accessibility tree is feasible, and similar to the work already under way to expose hidden child elements of the <code><canvas></code> element:

<blockquote>I don't think Apple has a strong stance either way on using @aria-describedby to point to @hidden elements, but I believe we could reasonably expose full semantics of hidden content pointed to by aria-describedby, this is more or less the same as the work we'd have to do to expose <canvas> children as an accessible tree.</blockquote>

[http://lists.w3.org/Archives/Public/public-html/2012Feb/0060.html Maciej Stachowiak, Apple]

In addition, this is the behavior that is specified for <code>@aria-describedby</code> in the ARIA User Agent Accessibility Guidelines (see below), and it is currently implemented in Safari.

<blockquote>In firefox, the reason that @hidden elements are "stringified" when
exposed through aria-describedby is because they don't have CSS boxes.
This is also why we have problems currently when exposing the contents
of a <canvas>. In both cases the accessibility code "fails" because it
tries to use the CSS boxes which aren't there. Hence the fallback to
stringify.</blockquote>

<blockquote>Exposing the rich semantics of contents inside a <canvas> in Firefox
will take a lot more than changing what object <canvas> inherits from.
Whatever solution we come up with for that can hopefully be reused to
expose the rich contents of @hidden elements exposed through
aria-describedby.</blockquote>

<blockquote>We now have two implementations which say that exposing the rich
contents of @hidden elements pointed to using aria-describedby is
implementable. And is implementable without changes from AT vendors.</blockquote>

[http://lists.w3.org/Archives/Public/public-html/2012Feb/0085.html Jonas Sicking, Mozilla]

There are similar constructs in Internet Explorer. For example, an aria-labelledby that references an element with CSS visibility:hidden or display:none will populate the accessible name for that element in IE9. Similarly, the accessible name of an input element will be populated with the text of it's associated label element, even if that label element is hidden with CSS visibility:hidden or display:none. This has been true in IE since IE 5 or 6. Having <code>@hidden</code> behave differently sets up a confusing situation for developers of both web applications and assistive technologies.

=== Compatibility and interoperability with ARIA 1.0 ===

As [http://lists.w3.org/Archives/Public/public-html/2012Apr/0046.html Richard Schwerdtfeger succinctly stated on April 9, 2012],

<blockquote>
The HTML 5 reference to aria-describedby is inaccurate as hidden text is
loaded into the accessible description string in an accessible object even though no accessible object representing the text description is exposed in the accessibility API.
</blockquote>

Because of how APIs work, any hidden content referenced by an ARIA attribute is rendered as a plain-text string. The [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions ARIA Can Only Refer To Hidden Content With Specific Restrictions change proposal] explains this in detail:

<blockquote>
The issue of whether or not hidden content could be referenced by ARIA attributes has actually been discussed by the ARIA Working Group, as recently as [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html March 2012].

The outcome of the ARIA WG's latest discussions has resulted in changes to the [http://www.w3.org/WAI/PF/aria-implementation Draft ARIA Implementation Guide] which speaks specifically to this Issue:

<blockquote>
<strong>[http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements 5.1.2. Excluding Elements from the Accessibility Tree]</strong>
<p>The following elements are not exposed via the accessibility API and user agents <strong class="rfc2119">MUST NOT</strong> include them in the accessibility tree</p>

* Elements with <code>role="[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]"</code> according to the rules for <code>[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]</code> role defined in <cite>[http://www.w3.org/WAI/PF/aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0]</cite>.

* <strong>Elements, including their descendents, that have host language semantics specifying that the element is hidden, such as CSS <code>display:none</code> or <code>visibility:hidden</code> or HTML 5 <code>hidden</code> attribute. </strong>
</blockquote>
The net effect of this is that any hidden content referenced by an ARIA attribute will be left to <strong>render as string text only</strong>, as it is forbidden by ARIA Processing rules, as well as the various Accessibility APIs (AAPIs), to take on any other role...

For this reason, any text that is hidden but referenced by an ARIA attribute will have limited, but not zero, value to screen reader users with AAPI aware tools.

So, to the question of "Should HTML5 permit ARIA attributes to reference (point to) content that is hidden from the visual view-port of sighted users?" the answer is, <u>it already can</u>.
</blockquote>

UAIG says that hidden elements are not exposed via the accessibility API, and this may be the cause of confusion. The intention was to forbid hidden elements from being exposed *as separate accessibility objects in the accessibility api object tree*. This was not intended to forbid mapping text from hidden objects to properties of other objects in the accessibility api tree. We will add an issue to UIAG to add a note to this effect.

However, section '''5.6.1.3. Text Alternative Computation''' of UIAG states explicitly that authors can provide plain-text strings for the accessible name and description via aria references to hidden elements, and that browsers are to process them as plain-text strings for these fields.
<blockquote>1.Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby being used in the current computation. By default, users of assistive technologies won't receive the hidden information, but an author will be able to explicitly override that and include the hidden text alternative as part of the label string sent to the accessibility API.</blockquote>

In addition, UAIG Section '''5.5.1. State and Property Mapping Table''' describes the use of aria-describedby and aria-labelledby in name and description calculation, and makes no mention of special treatment based on hidden state.

{| border="1"
! rowspan="1" colspan="1" |
WAI-ARIA State or Property
! rowspan="1" colspan="1" |
MSAA UIA Express
! rowspan="1" colspan="1" | MSAA IAccessible2
! rowspan="1" colspan="1" |
UIA
! rowspan="1" colspan="1" |
ATK/AT-SPI
! rowspan="1" colspan="1" | Mac OS X
|-
| rowspan="1" colspan="1" |
[http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby <code>aria-describedby</code>]
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.

If the object is in the accessibility tree, expose pointer to the accessible object in <code>IA2_RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation].

Expose pointer to the accessible object in <code>DescribedBy</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose pointer to the accessible object in <code>RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>string AXDescription</code> (reserved for non-visible accessible name or calculated description)
|-
| rowspan="1" colspan="1" |
[http://www.w3.org/WAI/PF/aria/states_and_properties#aria-labelledby <code>aria-labelledby</code>]
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>accName</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>accName</code> property.

Expose a reference to the accessible object in <code>IA2_RELATION_LABELLED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>Name</code> property.

Expose a reference to the accessible object in the <code>LabeledBy</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation].

Expose a reference to the accessible object in <code>RELATION_LABELLED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [#mapping_additional_nd Name Computation]. Expose in <code>string AXTitle</code> (reserved for visible name)
|}

====Accessibility API mappings====
When aria-labelledby and aria-describedby reference an element that '''IS NOT''' hidden, the following things happen:
# An Accessible Object is created in the Accessibility API tree for both the referencing and the referenced elements.
# In APIs that support such relationships, a relationship is created with bi-directional pointers between the objects. This can be used by AT products to find the referenced element and navigate to it.
# A DOM relationship is created between the referencing and referenced elements. DOM-based AT products, or browsers themselves, can use this to build UI that allows users to navigate to the description.
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

When aria-labelledby and aria-describedby reference an element that '''IS''' hidden, the following things happen:
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

Name calculation is what is at issue in this CP. It happens whether the referenced items are hidden or not. When the referenced items are hidden, then the relationships for navigation are not created. Again, this is ALREADY TRUE for CSS display:none and visibility:hidden, and has been true in browser implementation for years.

The structure of the referenced element is flattened in name calculation because properties where it is placed are of type string. In MSAA, for example, each accessible object is a COM object with properties of type string for the name and description. For more information, see the MSDN documentation for [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.aspx IAccessible], the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accdescription.aspx AccDescription] property, and the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accname.aspx AccName] property.

== Details ==
===Remove===

<p>The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.</p>

<p>Elements that are not hidden should not link to or refer to elements that are hidden.</p>

<p>For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. If the content is not applicable or relevant, then there is no reason to link to it.</p>

<p>It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.</p>

===Add===

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive.

Elements that are not themselves hidden must not hyperlink to elements that are hidden. Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements. For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate.

However, hidden elements '''MAY''' be used to provide descriptive text if such content provides a good user experience, by using aria-describedby and aria-labelledby and HTML labelling elements such as <label>, <legend>, <caption>, and <figcaption>.

Authors '''SHOULD''' avoid using hidden elements for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), as some user-agents/AT will flatten the referenced elements to plain text, losing interactivity and semantic structure, as noted above in the [http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v4#Accessibility_API_mappings ARIA API mappings]. If a (scripted) mechanism is used to render the hidden content on-screen (on demand) so that sighted and non-sighted users can effectively interact with the structured content, then authors '''MAY''' provide structured content in this scenario.

===Remove===

It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

== Impact ==

=== Positive Effects ===
* Makes the behavior of references from aria-describedby to elements with the @hidden attribute consistent with long-implemented browser behavior for references to content hidden with CSS display:none and visibility:hidden using <label> and aria-labelledby. This is a good example of documenting the web as it is.
* Provides a simple, consistent way for UAs to hide content from sighted users while exposing it to AT via the accessibility API.
* Allows authors to provide in-place information to AT users in scenarios where doing so provides the best user experience.
* Has no impact on scenarios where navigating to another location for additional information provides the best user experience.
* Provides an intuitive way for authors to hide content from sighted users. If you want your description to not be visible, put a hidden attribute on it, just like other contents that you don't want to be visible by default.
* Corrects the HTML5 specification with what in reality, ARIA actually says and does.
* Authors are told to not use a technique that does not work, e.g., hidden cannot support HTML-rich, structured content such as headings, paragraphs, list markup, table markup, anchor text, or inline content (such as <span>).

=== Negative Effects ===

* See Risks.

=== Conformance Classes Changes ===

* No change.

=== Risks ===

* Some authors will misunderstand the limitations of what can be achieved using ARIA, and will point aria-describedby to hidden structured text. Browsers will flatten that structure to a string and populate the accessible name and description fields in the accessibility API, which can cause a poor user experience for screen reader users. There have not been many reports of problems with this--the existing <label> and aria-labelledby functionality with CSS display:none and visibility:hidden, but since descriptions are often longer, it may be more of a problem with descriptions.

== References ==

* [http://www.w3.org/TR/wai-aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0] (W3C Candidate Recommendation)
* [http://www.w3.org/WAI/PF/aria-implementation WAI-ARIA 1.0 User Agent Implementation Guide] (W3C Editor's Draft)
* [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html Action-970 (PF) Publish F2F Minutes Extract RE ARIA-Describedby]

ChangeProposal/ISSUE-194/TranscriptURL

Spfeiffe — Mon, 11 Jun 2012 07:50:12 GMT

Spfeiffe: added some further clarification

[[Category:Issues]]

= Introduction of a @transcript=URL attribute =

Author: Media Subgroup of HTML Accessibility Task Force

Discussions by: John Foliot, Janina Sajka, Edward O'Connor, Eric Carlson, Charles McCathieNevile, Silvia Pfeiffer

Editors: Silvia Pfeiffer, John Foliot

== Rationale ==

This is a proposal to address the need for programmatically linked video and audio transcripts in HTML5 through introduction of a @transcript attribute on HTML5 media elements that contains a URL (preferably an absolute URL).

It is based on an analysis of use cases for video transcripts as provided by [http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement#The_use_cases the TranscriptElement CP]. An [http://lists.w3.org/Archives/Public/public-html-a11y/2012Jun/0018.html agreement was reached] to leave support for interactive transcripts (UC3) to HTML.Next. Further, UC4 can be solved in the way suggested by [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B the transcript-IDREFs CP].

The remaining use cases are proposed to be solved by a combination of existing aria attributes and a new @transcript attribute for media elements (particularly for the embedding case).

After long discussions, this proposal (the "transcript URL proposal") and [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B the "IDREFs proposal"] are the only two remaining proposals that aim to introduce a change to support transcripts in HTML5. Their difference is only in A further [http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange "no change" proposal] is also still on the table, aiming to provide more time to experiment with transcripts.

__TOC__

== Summary ==

[http://www.w3.org/html/wg/tracker/issues/194 Issue 194] asks for a mechanism for associating a full transcript with an audio or video element.

In this CP we analyze the different use cases for transcripts and the need for programmatic linkage to the media elements. We then provide markup examples that solve the use cases, thus identifying the gap that remains to solve with new markup.

It is important to note that the "IDREFs change proposal" and this proposal address the same use cases and are based on the same [http://www.w3.org/html/wg/wiki/ISSUE-194/Research research].

== The use cases ==

=== UC1: A full text transcript is provided with the media resource in a ''separate but linked resource''. ===

Examples:
* [http://www.centrelink.gov.au/internet/internet.nsf/individuals/baby_bonus_video.htm Centerlink AU Gov site]
* [http://www.pm.gov.au/videos PM Australia videos]

=== UC2: A full text transcript is provided as ''text on the same page'' of the media resource. ===

Examples of non-timed transcripts published underneath the video on-page:
* [http://www.state.gov/secretary/rm/2012/05/189592.htm US State Department]
* [http://www.manythings.org/b/e/5000/ ESL Videos]
* [http://foxnewsinsider.com/2012/05/04/video-transcript-hannity-takes-on-ows-organizer-in-explosive-interview/ Fox News]
* [http://www.commoncraft.com/video/rss RSS explained]
* [http://dotsub.com/view/ef3d7b6c-eab5-478a-a51c-d27166d27dcc Kony 2012 on DotSub]

Further, these use cases need to satisfy the requirements listed in the [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B#Requirements_from_the_TranscriptElement_proposal transcript-IDREFs CP].

== The Need of programmatic linkage between the video and its transcript ==

Before addressing the two mentioned use cases, it is important to understand what kind of programmatic linkage is desirable.

It is important to understand how transcripts are being published. In all analysed examples, videos are published in one screen area and transcripts are published in another screen area, typically below or beside the video. There is generally a defined screen area for the transcript, which is also where a choice between transcripts in different languages are made. The most usable ways in which transcripts are published are with the video above or beside it - in this way the user gets the choice to watch the video while reading the transcript or at least to seek to locations in the video while reading the transcript. The least usable video transcripts are plain text pages that are reached by linking away from the page with the video since the user loses all context.

The following list came about in discussions and is supported with examples from the Web.

=== What is not desirable: ===
* rendering of the transcript inside the boundaries of the video player (e.g. as an alternative to the video or an overlay within the video boundaries) - there is not sufficient space and it removes the possibility to watch the video while reading the transcript.
* having a button on the video player that links away from the video to a page that doesn't also contain the video - it removes the possibility to watch the video while reading the transcript.
Example: http://www.pm.gov.au/videos (poor experience when following the off-page link)
* having a button on the video element that scrolls down to where the transcript is displayed - it takes the eyes off the video.

=== What is desirable/acceptable: ===
* the transcript is rendered outside the video player, e.g. in a different region on the same page near the video player.
Example: http://www.state.gov/secretary/rm/2012/05/189592.htm
* having a link underneath the video player that allows to download the transcript and read it in parallel to watching the video.
Example: http://www.pm.gov.au/videos (note the download link)
* having a button underneath the video player that opens a section of the Web page that contains the transcript nearby.
Example: http://dotsub.com/view/ef3d7b6c-eab5-478a-a51c-d27166d27dcc
* having a button on the video player that links to a page that contains the video itself with the transcript.
Example: almost all embeddable players link back to their original page where transcripts reside (e.g. YouTube, DotSub)
* having a button on the video player that unhides a section on the page to reveal the transcript nearby. Note that this use case is typically identical to the button underneath the video player, since the video player in this instance is made up of more complex elements that just look like they are part of the video player.
Example: http://www.ted.com/talks/lang/mr/eli_pariser_beware_online_filter_bubbles.html

== Analysis ==

Some trends are revealed in the above examples that influence the required linkage between video and transcript.

=== The majority of use cases shows a visible transcript on the same page as the video player. ===

This is the preferred publishing means of transcripts. It makes it easy for the user to consume the transcript together with the video. This works for all users, not just the sighted or not just users of AT.

There are some different ways of rendering included in this case:
* text in plain view
<video poster="poster.jpg" controls aria-label="video with transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<p>
This is where the full transcript goes.
</p>

* text in plain view, but rendered from a separate html document
<video poster="poster.jpg" controls aria-label="video with transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<iframe src="transcript.html">
</iframe>

* button toggles the text in/out with JS
<video poster="poster.jpg" controls aria-label="video with transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<button id="transcript">Click to view transcript</button>
<div id="unhide_on_click" hidden>
<h4>Transcript</h4>
<p>
This is where the full transcript goes.
</p>
</div>

* link to open the transcript in a separate window/tab
<video poster="poster.jpg" controls aria-label="video with transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<a id="transcript" target="_blank" href="transcript.html">Transcript (HTML)</a>

* link to download the transcript
<video poster="poster.jpg" controls aria-label="video with transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<a id="transcript" href="transcript.doc">Download Transcript (doc)</a>

For the sighted user, there is no programmatic linkage required, since they can immediately discover whether a transcript is available or not and consume it adequately.

For the vision-impaired user, the screen reader should make an announcement that a transcript is available. This can be done using @aria-label and other accessibility-only attributes.

''No new attribute is required to solve this use case.''

=== The use case where a video has a transcript, but not on the same page: typically happens when embedding ===

When a publisher decides to publish a video transcript and a video, there is always a page that contains both. Sometimes the transcript is behind a (download) link, but there is always a Web page that connects the two. This is covered above.

However, when such videos can also be embedded on other sites (like YouTube videos or DotSub videos), the video player can end up being the only thing that moves to the new page, because the publisher wants to avoid the space requirements.

The DotSub player has a version where a richer HTML snippet than just the video player is embedded and this richer HTML snippet also embeds the transcript. However, there is a video-only embed player and that doesn't have a link or reference to the transcript. The YouTube player similarly doesn't have a link to the transcript.

Both the DotSub and the YouTube video player, however, have a link on their video player that links back to the video's home page, which contains (amongst other things) the transcript.

In order for transcripts to remain discoverable in this situation, we need a means to take the link to the transcript along with the video into the new site. This may or may not result in a visual representation of the link in the video controls. In either case, it is important that the transcript remains discoverable.

''A new attribute is suggested to solve this use case: @transcript=URL .''

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://example.com/video.html">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>

The URL should preferably be an absolute URL, such that it survives embedding. It should preferably link to a page that contains the video and the transcript together - linking to pages that only contain the transcript should be avoided.

== Proposal ==

Putting the two use cases above together, we reach a common proposal for '''introduction of a @transcript attribute that contains a URL'''. This URL points to the transcript either on the same page using a fragment ID or on another page.

In combination with the @aria-label attribute, the availability of the transcript is made discoverable to AT users.

* text in plain view
<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<p>
This is where the full transcript goes.
</p>

* text in plain view, but rendered from a separate html document
<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<iframe src="transcript.html">
</iframe>

* button toggles the text in/out with JS
<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<button id="transcript">Click to view transcript</button>
<div id="unhide_on_click" hidden>
<h4>Transcript</h4>
<p>
This is where the full transcript goes.
</p>
</div>

* link to open the transcript in a separate window/tab
<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<a id="transcript" target="_blank" href="transcript.html">Transcript (HTML)</a>

* link to download the transcript
<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<a id="transcript" href="transcript.doc">Download Transcript (doc)</a>

* "embedded" video with link to page that has transcript
<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://original.domain/original.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>

This design fulfills the basic need for programmatic association of transcripts with media elements, and it's possible to link to same-document transcripts as well as external resources.

It is worth noting that when copying the video element in all use cases, the transcript URL remains as part of the video element and is not lost.

It is further worth noting that the transcript itself can be provided in or below any element, including <a>, <area>, <iframe>, <article>, any type of header element, or any other element (including a possible future <transcript> element that may contain interactive transcripts). The URL is able to point to any such element.

This technique is simple to author and easily extends on existing transcript publication patterns.

=== Rendering ===

The introduction of a new transcript attribute on media elements creates a transcript link that all users can use, since blind users and sighted users are affected equally.

Different options for rendering are:
* Browsers can decide to include the URL in the controls bar rendered of a video or audio element when player controls are active. This could be a button or could be a menu entry called "Transcript" in a settings menu. Since it's a single URL with a clear semantic meaning ("transcript"), internationalization is simple for this one-word entry.
* Web developers should similarly be encouraged to add a link (called "transcript") in any custom media element controls that they create.
* Browsers can decide to include the URL in the context menu of the media element under a menu item of "Transcript".
* Screen readers should announce the availability of the transcript URL and provide the user with a means to follow the link.

Preferably all these options will be made available.

== Details ==

Note: The spec changes described below are intended to fully describe the sorts of changes necessary, but the exact form of the changes to be made are left to the discretion of the editor(s). (This is not a diff that can be blindly applied to the specification. Should the editor(s) find this description difficult to apply unambiguously, the author of this Change Proposal volunteers to work with them and the WG to resolve any such ambiguities identified.)

=== New section on transcripts ===

Add a section defining the @transcript attribute.

Transcripts for media elements may be provided, either directly in the text of the page, indirectly by linking to an external document with an <a> element, or by transclusion with an <iframe> element.

Where a transcript or transcript link is not visible on the page, but still available - e.g. in the case of embedded video - a @transcript attribute on the media element may be used.

The @transcript attribute may be specified to indicate a different Web location at which a transcript for the media element is available. This should preferably be a Web page that also contains the video for a better viewing experience.

If the attribute is specified, the attribute's value is a URL.

=== Modifications to the-video-element and the-audio-element ===

* In [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#media-elements the media elements IDL] add:

<code>
attribute DOMString transcript;
</code>

* Add "transcript" to the list of common media element attributes below the IDL:

<code>
The media element attributes, src, preload, autoplay, mediagroup, loop, muted, controls, '''and transcript''' apply to all media elements.
</code>

* After section [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#user-interface 4.8.10.13 User interface] insert a section "4.8.10.14 Transcript" roughly containing the following:

<code>
The transcript content attribute on media elements gives the address of a Web resource that contains a text transcript for the media element. The attribute, if present, must contain a valid non-empty URL potentially surrounded by spaces.

The transcript IDL attribute on media elements must reflect the content attribute of the same name.

media . transcript<br>
Returns the address of the resource containing the transcript.<br>
Returns the empty string when there is no transcript address.
</code>

* Further non-normative text should be added along the lines of:

<code>
The transcript content attribute should preferably contain an absolute URL to a Web page that contains both the media element and the transcript in plain text. This will ascertain that users can consume the transcript together with the media element's content. An absolute URL further reduces the risk of loosing the reference when embedding the media element's code.
</code>

* Further non-normative text should be added [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-media-controls in the controls section] that encourages means of rendering:

<code>
This user interface should include features to begin playback, pause playback, seek to an arbitrary position in the content (if the content supports arbitrary seeking), change the volume, change the display of closed captions or embedded sign-language tracks, select different audio tracks or turn on audio descriptions, '''link to transcripts''' and show the media content in manners more suitable to the user (e.g. full-screen video or in an independent resizable window). Other controls may also be made available.

Even when the attribute is absent, however, user agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), '''and to link to a transcript''' but such features should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu.
</code>

== Impact ==

=== Positive Effects ===

* By programmatically associating transcripts with media elements, we enable users, both assistive technology users and otherwise, to more reliably be made aware of existing transcripts for media resources.

* It's easy to update existing content to use this markup pattern, so it's easy for authors to adopt this technique.

* It's possible to link to same-document transcripts as well as external resources.

* Where multiple transcripts in different languages are available, the linked Web page should contain a means to select between the different transcripts and allow watching the video while reading one of the transcripts. This proposal builds on existing HTML features to make this possible.

* For UAs that don't support the <video> or <audio> elements, transcripts should be linked to inside the media element. Thus this proposal makes use of existing fallback mechanisms.

=== Negative Effects ===

* An additional attribute is added to media elements, which browser vendors have to support.

=== Conformance Class Changes ===

* The @transcript attribute is allowed on <audio> and <video> elements.

=== Risks ===

* UAs might not implement this mechanism, thus causing us to drop it from the specification in due course. However, since video and audio elements have controls and UAs are in the process of implementing menus to support captions, audio descriptions, and chapters, adding an additional menu entry may not be as objectionable. Since it's a single URL and a single menu entry compared, UA adoption can be simple. In comparison, the IDREFs proposal requires parsing of the elements that the IDREFs link to, making it much more complex to implement with no added value.
* Authors might not adopt this mechanism. Since the technique is simple, this risk is low.

== Obsoleting Change Proposals ==

This Change Proposal obsoletes the following CPs:

* [http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement Introduction of a <transcript> element] (1st media subgroup proposal)
* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP Introduction of a <transcript> element] (Silvia Pfeiffer)
* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_v2 Introduction of a new @kind value: "transcript"] (John Foliot)
* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194 Introduce a new attribute: @transcript] (John Foliot)
* [http://www.w3.org/html/wg/wiki/ISSUE-194/Option3B Reuse the rel and for attributes to programmatically associate transcripts with media elements] (Edward O'Connor)

These CPs remain:

* [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-2B Mint a transcript attribute for the programmatic association of transcripts with media elements] (Edward O'Connor)
* [http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange Defer ISSUE-194 until HTML.next] (Silvia Pfeiffer/Edward O'Connor)

Original Bug:
* [https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964 Bug 12964] - <video>: Declarative linking of full-text transcripts to video and audio elements

== Comparing to the IDREFs change proposal ==

In the (withdrawn) [http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement Introduction of a transcript element Change Proposal], ten requirements for transcripts were defined. As does the IDREFs proposal, we here examine the merits of each requirement and how the mechanism in the two remaining Change Proposals fare, since our views differ.

=== R1 Discoverability ===

This is a requirement that transcripts be both human-discoverable and machine-discoverable.

This proposal fulfills this requirement using a combination of the @aria-label and @transcript attributes. The @transcript attribute allows both sighted and non-sighted users to find the transcript following the link. Non-sighted users are additionally made aware of the existence of the link using ARIA. Similarly, machines find the transcript by following the URL. Existing user agents are no worse off with this proposal. In addition, discoverability is not lost when the video element markup is embedded on other pages.

The IDREFs proposal provides for similar discoverability for machines, which can follow an IDREF to an element on the same page. In fact, discoverability is of comparable quality between the two proposals when the transcript is provided on the same page. While the IDREFs proposal does not speak about how to announce the availability of the transcript to screen readers, it can be expected that it either also relies on an ARIA attribute, or it requires screen readers to be extended to interpret the @transcript attribute to announce its availability. This is therefore an identical feature.

However, when the transcript is provided on a different page to the page that the video is published on, the IDREFs proposal becomes a lot more fragile.

Firstly, since it relies on the transcript being provided on the same page, an off-page transcript needs to be provided through a separate element (in the examples it's an <a> element) that has to be provided somewhere on the page (and may need to be hidden if the page author does not want it shown). Thus, getting to the transcript requires resolution of a double indirection, something that the browsers will need to check for.

Secondly, if the video element gets embedded into another page, discoverability may suffer with the IDREFs proposal because the IDREF points to another element on the page. The only means around this is to put the <a> element with the indirection to the transcript inside the video element. Then it won't get lost when embedding.

Putting all these together for the IDREFs proposal makes for this implementation:

Here is the page on which the video element is published with the transcript below:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="foo">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
<a href="http://this.domain/this.page#transcript" hreflang=en id=foo>English Transcript</a>
</video>
<h4 id="transcript">Transcript</h4>
<p>
This is where the full transcript goes.
</p>

Then this will survive embedding in another page:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="transcript-ref">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
<a href="http://this.domain/this.page#transcript" hreflang=en id=foo>English Transcript</a>
</video>

This markup expects web developers to understand the double indirection and to provide anchors inside the video element that provide a URL to the actual transcript. The transcript-URL does not have such a double indirection and uses the URL directly on the video element.

So, in comparison the transcript-URL proposal has this markup:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<p>
This is where the full transcript goes.
</p>

When embedded in another page, it survives:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>

In addition, it poses no restriction on what markup is provided for fallback to older clients. It could include the transcript URL inside the video element if that is what the author would like, but it does not have to.

Summary: both proposals fulfill R1, but the IDREFs proposal is more fragile and has a double indirection that Web developers have to understand and browsers have to interpret to be able to provide discoverability of the transcript on the video element. Thus, the URL proposal provides a preferable solution.

=== R2 Choice to consume ===

This requires that users have the ability to control whether or not they consume a transcript. Both proposals fulfill this requirement.

=== R3 Rich text transcripts ===

This is a requirement that transcripts may be expressed in various rich text formats (such as HTML), and not just in plain text. Both proposals fulfill this requirement.

=== R4 Design aesthetics ===

This has two sub-requirements: one, that how transcripts are displayed be styleable by authors, and two, that it must be possible to expose transcripts in custom video controls. Both proposals fulfill each of these requirement.

=== R5 Embeddable ===

This requires that it be possible for transcripts to be expressed as an external document, while also embedded into the document which contains the media element. Both proposals fulfill this requirement (with <iframe>).

A further aspect of this requirement, which has not fully been expressed, is that the transcript link not be lost when the video is embedded elsewhere. This has been addressed in R1. It is noteworthy that the URL transcript proposal provides for a simple solution here without a double indirection, while the IDREFs proposal requires special markup inside the video element and a double indirection to allow embedding without loss of linkage. Or simply said: if an IDREF points to a section on the page that is not part of the video element, it will end up as a dangling reference (or worse: potentially pointing to something else on the embedding page) and the browser has no means to determine that this is wrong.

=== R6 Fullscreen support ===

This requires that it be possible for transcripts to "go fullscreen with the media element." The meaning of this is that when the video element goes fullscreen, the transcript should not be lost. Since both requirements allow the reference to the transcript to be included in the video's controls or a context menu and these do not get lost when going fullscreen, both proposals fulfill this requirement.

=== R7 Retrofitting ===

Existing pages publish transcripts for media elements through a visible transcript on the same page as the media player. Often times this transcript is lost when the video is embedded in a different page (for example this is the case for all YouTube videos). Thus, when we retrofit existing publications, we want to make sure to both, continue to support the publication of transcripts on the same page, but also enable to retain the link to the transcript when embedding. These requirements were a key motivation of this Change Proposal.

Like the IDREFs proposal, this proposal does not restrict any publication means of transcripts on the same page. This continues to work in UAs that do not support the <video> element or those that support it, but not the @transcript attribute. Existing author behaviour is not inflicted in either case.

However, the IDREFs proposal falls down when videos are embedded, but transcripts are not, which is a very common use case, too. The IDREFs proposal does not provide a good solution to this use case, but focuses specifically on pages where the transcripts are published on the same page.

The IDREFs proposal suggests that this proposal is fragile because Web developers may put into the URL just the relative link to the element on page that contains the transcript, thus losing it when embedding. This is a possibility for the URL proposal, which needs to be overcome with education, examples, and with validators that point out problems when relative URLs are used in the @transcript attribute. However, it's only a risk, whereas in the IDREFs proposal it is a certainly, since all links are relative. Thus, the IDREFs proposal is much more prone to this problem than this URL proposal.

Summary: the URL proposal fulfills R7 better than the URL proposal, since it does not fail easily for the classic use case of embedding, which is the main need and the main advantage over existing transcript publication methods.

=== R8 No link duplication ===

This requirement asks that transcript links are not duplicated. However, there are a multitude of use cases of transcripts and what this requirement asks for is to not duplicate the URL on the same page.

To compare the URL and the IDREFs proposals properly, one has to start with the case where a video is published with a transcript on the same page and made embeddable without losing the transcript link. Thus, we need to compare the IDREFs proposal example that has the link in an anchor inside the video element to the transcript-URL proposal:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="foo">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
<a href="http://this.domain/transcript.html" hreflang=en id=foo>English Transcript</a>
</video>
<h4 id="transcript">Transcript</h4>
<iframe src="transcript.html">
</iframe>

This contains a duplication of links. Thus, a better way to publish it would be:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="foo">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
<a href="http://this.domain/this.page#transcript" hreflang=en id=foo>English Transcript</a>
</video>
<h4 id="transcript">Transcript</h4>
<iframe src="transcript.html">
</iframe>

Comparing this to the transcript-URL proposal looks like this:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<iframe src="transcript.html">
</iframe>

It could also be published like this:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/transcript.html">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<iframe src="transcript.html">
</iframe>

but that would make the transcript less usable when embedded because it links back to just the page with the transcript instead of the video and the transcript. This is therefore to be avoided.

In either case, the IDREFs proposal has to deal with the same question as the transcript-URL proposal: what URL is included in the anchor element inside the video element. Since the transcript-URL proposal always uses the same suggestion: namely link to the current page with an offset to the element with the transcript, it is less prone to URL duplication.

Summary: the transcript-URL proposal fulfills R8 better than the IDREFs proposal.

=== R9 Multiple transcripts ===

Transcripts may be available in several languages - this indeed happens in current transcript publication sites, including YouTube and TED. TED and YouTube have found two different means of dealing with this situation.

YouTube changes the language of the displayed transcript when the language of the captions that are displayed is changed. This makes sense for YouTube, because the transcripts are created from the captions and are just a different means of displaying the captions. This is, however, not a general requirement - in fact, it is preferable for transcripts to also contain scene descriptions and not just the spoken transcription, because that allows users to read the transcript without having to watch the video (a particularly important use case for deaf-blind users).

TED has found a different solution to this problem: where the transcript is displayed, there is also a menu that allows the choice of language that is displayed. This makes the transcript one semantic entity on a page and independent of the video element. It is therefore a preferable means of dealing with transcripts.

In the transcript-URL proposal, there is no restriction about the language in which the transcript is published - it continues to allow Web sites to publish their transcripts in multiple languages and to provide a menu to change the language in which it is published. It simply provides programmatic linkage between the video element and the transcript - any specification of language has to be provided by the elements through which the transcript are published.

This is essentially the same with the IDREFs proposal. It also does not allow for specification of language in the @transcript attribute. It does, however, allow for specification of multiple IDREFs, which could all point at elements with different languages (they don't have to, but they could). It could even support creation of a menu with transcripts of different languages on the video element, but it would require to parse the elements that the IDREFs point to for getting this information. Thus, this is possible:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="foo1 foo2 foo3">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
<a href="http://this.domain/this.page#transcript_en" hreflang=en id=foo1>English Transcript</a>
<a href="http://this.domain/this.page#transcript_de" hreflang=en id=foo2>German Transcript</a>
<a href="http://this.domain/this.page#transcript_fr" hreflang=en id=foo3>French Transcript</a>
</video>
<h4 id="transcript">Transcript</h4>
<p id="transcript_en lang="en">This is the actual transcript.</p>
<p id="transcript_de lang="de" hidden>Dies ist das Transkript.</p>
<p id="transcript_fr lang="fr" hidden>Ceci est le transcripte.</p>
<button>Display English transcript</button>
<button>Display German transcript</button>
<button>Display French transcript</button>

However, the difference is only that the choice of language happens in the video element rather than the linked to page. Thus, when you have linked to the page and want to change the language thereafter, you still need the choice on the page. This is a duplication of the selection mechanism. The key issue here is that the transcript is not handled as its own semantic content in its own right, but rather regarded as a dependent content from the video.

Also note that the IDREFs proposal requires duplication of the language markup both on the link through which the transcript menu is created as well as on the transcript elements themselves, which is another consequence of the double indirection.

In contrast, the transcript-URL attribute regards the transcript as a semantically rich piece of content in its own right that only requires a linkage to the video element. Thus, the above example becomes:

<video poster="poster.jpg" controls aria-label="video with transcript" transcript="http://this.domain/this.page#transcript">
<source type="video/mp4" src="video.mp4">
<source type="video/webm" src="video.webm">
</video>
<h4 id="transcript">Transcript</h4>
<p id="transcript_en lang="en">This is the actual transcript.</p>
<p id="transcript_de lang="de" hidden>Dies ist das Transkript.</p>
<p id="transcript_fr lang="fr" hidden>Ceci est le transcripte.</p>
<button>Display English transcript</button>
<button>Display German transcript</button>
<button>Display French transcript</button>

Also note that as a consequence of the single link on the video element, there is no need for provisioning of a descriptive text - it is simply always the word "transcript" (internationalized to the browser's default language) that links to the transcript. No further metadata is required, since the target transcript publication page will provide for all the required metadata and markup.

Finally, it has been mentioned that this means that transcripts are handled differently to captions. This is actually intended and a good thing. Captions are a part of video and rendered on top of them, while transcripts are a piece of content that can stand alone in their own right. Thus they have to be handled as a separate concept and the language choice should be made where the transcript is, and not where the video is.

Summary: Both proposals support the publication of multiple transcripts in different languages, but the transcript-URL proposal works more directly with existing means of publication of transcripts and requires less new markup to do so and therefore instills less parsing requirements on the UA. The IDREFs proposal conflates the concept of "linking a transcript (area) to the video" and the concept of "choosing between different transcripts" unnecessarily. Thus, the transcript-URL proposal fulfills R9 better than the IDREFs proposal.

=== R10 Stand alone transcripts ===

It is possible for UAs to render stand-alone transcript documents which are not programmatically associated with media elements in the same way for both proposals. In both proposals, if the @transcript attribute is not available, there is no means to link programmatically between the video element and a transcript (that is potentially on another page). In both proposals, if the transcript is published on the same page as the video, it is available to all users, no matter whether their browser supports the @video element or not. The transcript-URL proposal further suggests the use of @aria-label to actually make AT users aware of the availability of the transcript, but this is a means that is also available to the IDREFs proposal. So, both proposals satisfy this requirement in the same way.

=== Conclusion ===

The IDREFs proposal is a more fragile solution to the requirement of programmatically associating transcripts with video elements. To survive cross-document copy and paste operations, it requires that extra markup be placed inside the video element the contain the link that the transcript-URL proposal directly places into the @transcript attribute. To add menu elements inside the video controls that allow users to link directly to the transcript, it requires the browser to parse those elements inside the <video> element that point to the transcripts themselves, thus requiring a double indirection be resolved by the UA. This latter is particularly fragile since it requires the Web Developer to create markup inside the video element that is used both as fallback content and as a menu for the video element, thus overloading an area that has one use with a second use case.

One example provided in the IDREFs proposal provides a good idea of the challenges that UAs have to go through to add menu elements to the video element:

<video src=video.mp4 transcript="foo bar">
<div id=foo lang=en>English transcript goes here</div>
<p>A <a href=bar.html hreflang=de id=bar>German language transcript</a> is available as well.
</video>

In this example, the UA would need to parse the text inside the video element to come up with a menu that reads:

* English transcript (with a link of: "#foo" and a hreflang="en")
* German language transcript (with a link of "bar.html" and a hreflang="de")

While possible, resolution of such double indirection is not something we've had elsewhere before in HTML and is particularly dependent on good authoring practice. (Note, e.g. that the bar.html link will not survive copy-and-paste to a different domain. Also note that if the English transcript is meant to be published on the same page as the video is, too, there will need to be duplication of the div).

In essence, the IDREFs proposal optimizes on a single use case: the one where the transcript is published on the same page as the video. This use case does not even require a solution, since the transcript is on the same page as the video and therefore discoverable. For the second use case - the one where the transcript is published on another page - the IDREFs proposal requires a double indirection, requiring to link to another element that contains the off-page link. Thus, the transcript-URL proposal is an optimisation of the IDREFs proposal.

'''Summary:''' The transcript-URL proposal fulfills our requirements better than the IDREFs proposal.

ChangeProposals/Issue31cMetaGeneratorUpdated

Mike — Wed, 30 May 2012 10:06:58 GMT

Jbrewer: /* Re-updated Re-open Request and Change Proposal on Meta Generator */

= Re-updated Re-open Request and Change Proposal on Meta Generator =
*The [[#toc|table of contents]] immediately follows the Summary.
*Authors: Judy Brewer, Mike Smith
*Contributors: Laura Carlson, Janina Sajka
*Status: Ready for review

== Summary ==
'''This change proposal:'''
* '''provides background on prior discussions regarding meta name="generator";'''
* '''identifies new rationales and information on why the meta generator exception is a bad idea;
* '''updates recent new information regarding deficiencies in specification of the "generator" value;'''
* '''identifies contradictions between the meta generator exception and the HTML5 design principles;
* '''describes problems in weighting of evidence for and against the "generator exception";'''
* '''provides details and describes the impact of the proposed changes.'''

A requirement for alternative text on images in HTML had existed for fifteen years in order to help ensure accessibility of Web content for people with disabilities. The current HTML5 specification introduces exceptions that change that requirement.

In particular, the draft specification currently uses the following language to define the "generator" value for meta name:

<blockquote>
The value must be a free-form string that identifies one of the software packages used to generate the document. The value must not be used on hand-authored pages.
</blockquote>

Note especially that the spec introduces the new language "the value must not be used on hand-authored pages". This change proposal (CP) argues in part that the above specification of the "generator" value is based on assumptions which are not supported by any evidence and are at odds with actual real-world authoring practices, and contains language that is ambiguous in that it leaves to speculation what is meant by the term "hand-authored". Taken together, those deficiencies greatly weaken any arguments in favor of the viability of the meta generator exception, which depends on this new definition of the generator being sound, and the assumptions behind it being sound.

As far as the part of the spec which actually states the meta generator exception, the following part of the spec introduces that, by defining conformance-checker constraints with regard to the alt attribute on the img element:

<blockquote>
A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies:

* The img element is in a figure element that satisfies the conditions described [in a previous section of the specification].
* The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.)
</blockquote>

The HTML Co-Chairs have previously issued an HTML Working Group decision in support of that exception to allow missing alt to be evaluated as conformant for any pages which include the string <code><meta name="generator" /></code>. Generator is a value that is automatically inserted by a variety of types of authoring and content management tools to indicate the tools that were used in creating a page or processing content on the page; this often results in multiple generator tags being inserted into and retained in a page as it is processed through a sequence of tools.

This conformance exception for pages that contain the "generator" value for meta name exempts images on a large portion of pages on the web from an accessibility requirement that is essential to effective use of the web by users with visual impairments. This CP argues that among the reasons the meta generator exception should be removed is that trying to fix a problem by introducing a new document-global-switch is a bad idea, and that it inadvertently and retroactively introduces new, undocumented, magic semantics.

This CP also re-analyzes the Co-Chairs' previous decisions in favor of the <code><meta name="generator" /></code> exception and against the requirement for alternative text, identifying factual and logical inaccuracies. It describes the harm that is done by the generator exception, and proposes removing the generator conformance exception in order to address these problems.

This CP is currently being put forward simply as a request for the issue to be reopened so that the group can have the opportunity to consider the new information it provides. We believe it presents more than sufficient weight of new information to merit having the issue reopened so that the HTML Working Group can provide their reconsideration of the topic.

=== Background of "generator exception" discussion ===

This change proposal is an updated re-open request for a CP on the <meta name="generator"> exception for alternative text, with an extensive discussion history going back several years. Key steps have included:

* [http://www.w3.org/html/wg/tracker/issues/31 2008-02, Issue 31 raised: Author conformance requirements for the alt attribute on images]
** (Includes comprehensive reference links for this topic)
* [http://www.w3.org/2002/09/wbs/40318/issue-31-80-validation-objection-poll/results#xwarning 2011-04 Survey regarding objections to "generator exception" for alternative text]
**(Question: Should it be permitted to omit alt when the generator mechanism is present?);
** [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElementSurveyConformaceChoices 2011-01 Change proposal choices for Alt Issue 31]
** [http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html 2011-04 HTML Co-Chairs' decision against removing the "generator exception"];
* [http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming 2012-01 Steve Faulkner's reconsideration request for removal of the "generator exception"];
** [http://lists.w3.org/Archives/Public/public-html/2012Feb/0237.html 2012-02 HTML Co-Chairs' rejection of Steve Faulkner's re-open request.]
* [http://www.w3.org/html/wg/wiki/ChangeProposals/Issue31cMetaGenerator 2012-05 Updated Re-Open Request and Change Proposal]
** [http://lists.w3.org/Archives/Public/public-html/2012May/0005.html 2012-05 Re-open request from Judy Brewer]
** [http://lists.w3.org/Archives/Public/public-html-a11y/2012May/0094.html 2012-05 HTML Co-Chairs' rejection of Judy Brewer's re-open request]
* 2012-06 Re-updated Re-Open Request and Change Proposal with new information (this document)

__TOC__

== Rationale ==

This section provides detailed rationale for the proposal to drop the meta-generator exception.

=== Fixing something bad by introducing a document-global switch is a Bad Idea (new) ===

''This section provides new information that was not presented in any previous CPs.''

In many years of collective experience with Web language-standards development, among the things we've learned and that are now generally accepted is that trying to fix a problem by introducing a new document-global switch is a bad idea.

Consider the precedent of quirks modes and the behavior of switching into it based on the presence or absence of a doctype and the nature of the doctype. It was a "seemed like a good idea at the time" design decision that is now universally understood to have been a serious mistake with bad consequences that author-developers and all of us are now stuck with, forever.

Introducing any new document-global switches is something that should be avoided, and something that should never be done at all unless there is prevailing agreement that it's absolutely necessary. But that is not at all the case with meta generator.

Further, the badness of this particular Bad Idea is even further compounded if it takes an ''already existing'' element and retroactively turns it into a document-global switch -- especially an element like meta generator, which previously had no effect on processing behavior in any application conformance class defined by the spec, and which previously had obvious, clearly understandable, very simple semantics. The existing spec text that makes meta generator a document-global switch has the consequence of changing its semantics in a opaque, non-obvious-to-authors way, as well as assigning it new behavioral effects in a key class of applications (validators) in a way that authors are never going to be alerted to.

=== "Legacy use" of meta generator is never likely to be supplanted by use conforming to the current spec text (new) ===

''This section provides new information that was not presented in any previous CPs.''

Arguments in favor of the meta-generator exception appear to assume that the current way that tools use
meta generator -- due to the new constraints the spec introduces -- is going to become "legacy
use". That "legacy use" argument about meta generator seems to assume that at least one of the following things is going to happen:

* It assumes that tools which currently emit meta generator in a way that violates the current spec are going to be updated, to stop emitting it from now on.

* It assumes that users of tools which currently emit meta generator in a way that violates the current spec are going to switch to using whatever option the tool provides for suppressing meta generator (e.g., to start using the tidy-mark=no option with Tidy).

* It assumes that authors of what the current spec calls "hand-authored" documents that contain meta generator (e.g., because it was put into the doc by some other tool before the author switched to "hand authoring" it) will take time to manually remove the meta generator instances from their documents. This assumes that the authors are aware of this spec constraint to begin with; that is, that they are aware that the spec has redefined meta generator as a document-global switch, and retroactively assigned new magic semantics to all documents containing meta generator.

At this point, no evidence has been presented by anyone to support the assumption that any of those things is actually going to happen in practice on any kind of scale.

On the other hand, we do have evidence to suggest that most or are all of those are in fact not going to happen in practice. That evidence includes the following:

* We know there are many widely-used tools that currently emit meta generator but which are no longer actively maintained. The non-HTML5 version of Tidy is one example; there has not been a new release of that since 2009, and there has been no active work on it since. Yet that is still the main version that most users have, and the version that's going to be the most widely used for a long time to come.

* We have evidence that developers of actively maintained tools that emit meta generator, in a way that violates the new magic semantics and constraints that the spec has retroactively assigned to it, are not going to stop having their tools emit it. Those comments include statements made on public-html by Daniel Glazman (Blue Griffon HTML editing application) and Mike Smith (HTML5 Tidy): [http://lists.w3.org/Archives/Public/public-html/2012May/thread.html#msg104 http://lists.w3.org/Archives/Public/public-html/2012May/thread.html#msg104] and [http://lists.w3.org/Archives/Public/public-html/2012Jun/0023.html http://lists.w3.org/Archives/Public/public-html/2012Jun/0023.html] and Julian Reschke [http://lists.w3.org/Archives/Public/public-html/2012May/0109.html http://lists.w3.org/Archives/Public/public-html/2012May/0109.html].

Furthermore, we have no evidence to suggest that authors are, on any kind of scale, going to start manually removing meta generator instances from their documents. It seems in fact very unlikely that they will, because without users having read the HTML5 spec, they have no way to discover the fact their documents now may all contain a document-global switch with new magic semantics that they're possibly now violating.

Consider the problem the current spec language introduces with respect to validator behavior. The purpose of the validator is to help authors find and fix errors in their documents that they otherwise would not be aware of. A key problem with the meta generator exception is that it provides no way to make authors aware of this particular spec constraint. The requirement silently changes the behavior of the validator in a way that most authors are never going to realize and never be made be aware of. The end result is that many users are no longer being alerted to a very important case of errors in their documents that they would otherwise be informed about and would fix.

A spec constraint that validators are unlikely to inform users about is fundamentally flawed. It is a spec constraint ("meta generator must not be used on hand-authored pages") that's neither possible to check programatically, nor possible for validator users to evaluate and assess on a given document in isolation from any knowledge of how it might have been authored; and the effects of the generator exception will result in confusion from the results of validation of output of legacy tools.

=== Inadvertently and retroactively introducing new, undocumented, magic semantics (minor update) ===

''Update: We note that the chairs have recognized that the argument put forward in this section "is new information, as surprisingness to authors was not previously raised", which gives it weight toward re-opening of the decision The rest of the language of this section remains the same as it was in the previously submitted CP.''

The effect of the generator exception is that it inadvertently assigns additional new semantics to meta generator -- magic semantics that are not clearly documented in the spec and not obvious to implementors and users of the spec. Specifically, the generator exception has the effect of making meta generator provide the new meaning, "I do not want conformance checkers to emit error messages about missing alternative text for any <code>img</code> elements in this document." And it unilaterally and retroactively assigns that additional meaning to all existing documents that contain meta generator, not just to newly created documents.

If I am implementing, for example, an HTML editing application based on the spec, it is not clear to me from reading the spec that having my editing application add a meta generator element means that for every single document any author creates with my application, conformance checkers are never going to emit error messages about missing alternative text for <code>img</code> elements.

And as a document author, it is not at all clear to me from reading the spec that if I keep a meta generator element that has been added by any tool in the production or evaluation process, anywhere in any document, it means that I am choosing to completely opt out of having conformance checkers emit any error messages about missing alternative text for any <code>img</code> elements in the document. Among other things, the result is a significantly reduced ability for me to identify potential errors which I otherwise would have been alerted to; I lose an important capability due to meta generator having surprise magic semantics that are not clearly inferable from the spec.

Moreover, assigning this new "do not emit error messages about missing alternative text for any <code>img</code> elements in this documents" meaning to meta generator results in retroactively changing the processing behavior of an entire conformance class for all existing documents that have ever been created on the Web which contain meta generator instances. That is, prior to HTML5, the meaning of meta generator in those documents was simply that it was a stamp to indicate which applications were used to create the document. But now, an additional meaning that the original creators of those documents never intended is unilaterally and retroactively being assigned to those documents, with one of the consequences being that the documents will now be handled by conformance checkers in a way that is very different from that way in which they were handled previously. In that sense, it "breaks" existing content.

The meta generator exception is therefore actively harmful and should not be part of the specification.

=== Fatal ambiguity in the specification (minor update) ===

''Update: We note that a bug has been opened for this problem -- [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17438 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17438] -- and that the chairs have recognized that "Pointing out the ambiguity [described in this section] is a new point and arguably new information", which gives it weight toward re-opening of the decision. The rest of the language in this section remains the same as it was in the previously submitted CP.''

The specification introduces the authoring-conformance constraint that a meta generator element must not be used on "hand-authored" pages. However, it does not define what a "hand-authored" page is, and the definition of that term is not obvious. That lack of a clear definition for "hand-authored" is thus a fatal ambiguity in the spec -- fatal in the sense that it entirely undermines the implicit rationale that the spec uses for excepting certain documents from the requirement to provide alternative text for images, which is based completely on the assumption of the possibility of clearly making a distinction between a supposedly "hand-authored" page and a supposedly non-"hand-authored" page.

It is not at all clear whether a "hand-authored page" is intended to mean, for example, a document that was created in a text editor without using any post-processing tools at all, or whether it can mean a page that was at some point created with an automated tool of some sort, but subsequently was edited exclusively in a text editor or other tool.

It is also worth noting -- regardless of what the ambiguous term "hand-authored" was intended to mean -- that given a document in isolation from its author, it is impossible to know whether that document was "hand-authored" or authored in some other way. So conformance-checking tools can never be expected to reliably detect whether a document was "hand-authored" or not.

=== Tool-mediated insertions of alternative text are ignored (minor update) ===

''Update: We note that chairs did not address this section at all in their response to the previous CP. The rest of the language of this section remains the same.''

A mistaken assumption that seems to be implicit in the current specification language regarding meta generator is that the authoring production process is binary: that a document is either generated in a completely automated fashion, or that it is completed authored by hand. That assumption does not match reality. The document production process often includes multiple steps. For instance, documents may be first generated using some kind of automated tool, or some conversion process from another format (for example, from a word-processing application such as Microsoft Word or OpenOffice, etc.); then they may be processed through intermediate stages to address layout, format, animations, etc.; then they may be validated, cleaned or repaired using various tools. Any of the tools in this production chain may add generator tags, and, once added, these tags are generally not stripped out by other tools.

At most of these stages, most types of authoring or processing tools allow tool-mediated adjusting of content. Some of these tools, such as Tidy (which adds a generator tag) allow hand-editing as well.

Steve Faulkner's [http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming#Majority_of_content_not_exclusively_WYSIWYG_.28New.29%3Chttp://www.w3.org/html/wg/wiki/ChangeProposal/meta_name=generator_does_not_make_missing_alt_conforming change proposal] provides data on a variety of tools which, as relevant evidence to establishing the range of production processes, allow tool-mediated editing of content. Some of the tools listed also allow hand-editing.

=== The "generator exception" obviates the intent of the Validator (updated) ===

''Update: We note that the chairs most recent response stated that this section "presents an argument based on presumed benefits and instead of citing actual benefits". This section has now been updated in an attempt to address that response.''

In an earlier response, the Co-Chairs asserted that because the "generator exception" did not assert benefits relative to the Validator, such benefits were immaterial to the decision:
<blockquote>
Another objection argues that the generator mechanism fails to have certain benefits:
<blockquote>
The generator mechanism does not improve user experience or the
chances of accessible content being produced. It does not help
authors catch mistakes. It does not help educate developers.
</blockquote>
No one disputed this argument; but conversely, no one argued that
generator has these benefits or should be allowed because of such
benefits. With no concrete argument as to why the generator exception
ought to have these benefits, this was taken to be a weak objection.
</blockquote>

The W3C Validator service provides these benefits without regard to whether the generator mechanism claims such benefits. As the W3C Validator documentation states, [http://validator.w3.org/about.html "Validating Web documents is an important step which can dramatically help improving and ensuring their quality..."]. It provides a teachable moment, to whit: [http://validator.w3.org/docs/why.html#learning "Validation helps teach good practices"]. Additional information is available at [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#HTML5_Should_Help_Facilitate_Accessibility_Awareness_and_Education HTML5 Should Help Facilitate Accessibility Awareness and Education.]

In the presence of the generator exception, the validator suppresses error identification, and is thereby stripped of its educative benefits. If content developers are not aware that a problem (missing alternative text) exists, they are not notified about it, nor do they have the opportunity to rectify specific instances of missing alternative text. They are therefore deprived of the opportunity to learn about the general issue, and deprived of the opportunity to improve their content in the future.

So while the survey comments specifically raised the question of generator benefits, by extension they also raise the important question of Validator benefits, and how not to inadvertently undermine them.

Regardless, the problem with the effect of the meta generator exception on validator behavior is not really about presumed benefits. The problem is that it is detrimental because it reduces the ability of authors to find and fix errors in their documents that they otherwise would not be aware of (the fundamental purpose of the validator) -- because it defines a new document conformance requirement that the validator has no way to make authors aware of, with the result being that many users of the validator are no longer being alerted to errors in their documents that they would otherwise be informed about and would fix. Validator users are not benefitted when the validator fails to inform them about errors in their documents that violate document-conformance constraints in the specification.

<strong>The issue of the meta generator exception being detrimental for users of the validator should have been evaluated as a strong objection, rather than a weak argument.</strong>

=== The "generator exception" results in inequitable rendering of graphical content (updated) ===

'''Update: We note that the chairs have recognized that the argument put forward in this section "represents a notable improvement" and that it is "likely not a point that is in dispute," however, that the HTML Co-Chairs seek additional evidence. Please note updated discussion below.'''

In their April 2011 decision, the HTML Co-Chairs incorrectly asserted that arguments regarding structural integrity against the generator exception were circular and gave these no weight:
<blockquote>
Another objection was that the generator exemption breaks the structure of the img element:
<blockquote>
Requiring a set of programmatically determinable valid options helps ensure that images have complete structure. Complete structure of the <img> element requires both src and text alternatives.
</blockquote>
This claim seems to be based on a circular argument. Omitting alt should not be allowed, because that would make the img element have incomplete structure, because img requires alt. Thus, the objection fails to make its case and was given no weight.
</blockquote>

This argument is not circular. For web content to be independent of presentation, both the <code>src</code> attribute and the <code>alt</code> attribute are necessary for images.

* Omit the <code>src</code> attribute, and sighted users have no content;
* Omit text alternatives, and non-sighted users have no content.

For a sighted user, if there is no <code>src</code> element, then no content is rendered, and therefore it is a document error. For a blind user, if no content is rendered, then there is likewise a document error; without <code>alt</code> content, the <code>img</code> element is not representing anything to that user. It is inequitable for a document to represent something to a sighted user but not to a non-sighted user.

Without both a <code>src</code> attribute and a text alternative the <code>img</code> element is incomplete, as further discussed in [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#HTML5_Should_Require_Structural_Integrity_for_the__.3Cimg.3E_Element Laura Carlson's change proposal on conformance checking].

The most recent HTML Co-Chairs' response on this point acknowledges a notable improvement in this rationale:

<blockquote>
This replaces prior statement of "complete structure" and represents a notable improvement; that being said this is (a) merely an assertion provided without evidence (citing the actual problems caused with existing tools would be helpful), and (b) likely is not a point that is in dispute.
</blockquote>

Regardless of whether a point is in dispute or not, if there is a notable improvement in a rationale, it seems appropriate to consider that as relevant information for this re-open request, so that the working group may have the opportunity to consider this rationale.

As to the request for evidence, such as problems with existing tools, there appears to be a misunderstanding. We have not raised concerns regarding tool behavior; the concern we raised is with regard to equitability of presentation of web content for users with disabilities who require different modes of presentation.

This is a rationale with regard to principle, not tool behavior.

<strong>The argument against the "generator exception," regarding structural integrity of the <img> element, should have been evaluated as a strong objection rather than to have been given no weight.</strong>

=== The "generator exception" breaks harmonization with other standards and guidelines (updated) ===

In their decision, the Co-Chairs suggested that the disharmonization with standards and guidelines introduced by an HTML5 "generator" exception is a failure of other standards and guidelines to update, and therefore they weighted this objection to the generator exception low:
<blockquote>
Yet another objection was based on standards and guidelines:
<blockquote>
The generator mechanism breaks standards and guidelines requiring text equivalents on an individual element basis.
</blockquote>
Many specific standards and guidelines were listed. However, these
guidelines were generally created before the generator mechanism
exemption was invented, so it's not clear if the disagreement
indicates a problem, or just failure to update. Thus, this was taken
to be a weak objection.
</blockquote>

This disagreement indicates a problem that cannot be solved as the HTML Co-Chairs seem to suggest by updating numerous other standards and guidelines, but that must rather be solved by removing the "generator" exception in HTML5 that has introduced this disharmonization.

The problem introduced by the "generator" exception is major with regard to standards harmonization, in that accessibility standards require alternative text for images, but the "generator" exception makes this requirement meaningless on the large number of web pages that have a "generator" tag inserted. In exempting a large percentage of pages on the web from the requirement to provide alternative text for images, people with visual disabilities are not provided equitable access to web content--equitable access that could have readily been provided by following the provisions of these standards and guidelines.

The date that the guidelines and standards were created--whether before, during or after creation of the generator exemption--has no bearing on the validity of the user requirement for alt, as had been suggested by the HTML Co-Chairs. User needs for alternative text as captured in provisions of web standards and guidelines do not somehow become irrelevant because of a standard that does not follow the provisions of existing standards and guidelines. The existence of people with visual disabilities, and the need to accommodate them on the web, have not disappeared in the intervening years, and it is in order to address these user needs for alternative text for images on the web that provisions for alternative text exist in the Web Content Accessibility Guidelines (WCAG) 2.0 and other accessibility standards.

This assertion also presumes that other accessibility standards and guidelines would now agree with the generator exception, though the opposite is a far more likely conclusion; other standard developers are well aware of automated authoring tools, and simply do not agree that alt is unnecessary or expendable when a tool is involved, and therefore accommodate the need for provision of alternative text. Again contrary to the HTML Co-Chairs' assertions above, content management systems (CMS) existed long before the completion of accessibility guidelines, including WCAG 2.0, containing provisions for alternative text. The HTML Co-Chairs are mistaken in their assumption that these standards did not consider the implications of CMS. Additionally, even accessibility guidelines and standards currently under development continue to recognize the need for and utility of alternative text in order to address accessibility requirements for web users with visual impairments.

To suggest that the problem of standards breakage (standards fragmentation), resulting from the generator exception, is a failure of standards and guidelines to update is to suggest that users' needs are shaped by a technical standard rather than vice versa. People with different disabilities experience a wide range of functional requirements which are highly addressable in a digital environment such as the web. The means to addressing these functional requirements are by specification of accessibility provisions such as alternative text for images. Exempting the great extent of web content from conformance-checking for alternative text, just because that content happens to include a generator tag put there as an authoring tool product mark, does indeed create standards harmonization because it would mean that documents created with HTML5 could no longer be validated in a way that would indicate whether they conformed to WCAG 2.0, another W3C specification.

The most recent HTML Co-Chairs' response on this point reflects several continuing points of confusion:

<blockquote>
If there is evidence on which the other standards have been based that needs to be brought forward, then do so. Simply citing a difference and making an assertion as to which is in error is not sufficient. Also from the original decision:
+ it's clear that there are tools which do not follow ATAG in this respect, and no evidence was provided that this would change.
</blockquote>

The primary standard which the generator exception is creating disharmonization with is the Web Content Accessibility Guidelines (WCAG) 2.0, which establishes the user requirement for alternative text. By nullifying the requirement for alternative text on a large category of web pages, the draft HTML5 specification interferes with the ability of authors to conform to WCAG 2.0. It does so by preventing validators from ascertaining whether alternative text has been provided on any page that happens to create a generator tag -- which, over time, will become the majority of pages on the web.

WCAG 2.0 is already required for public websites in many countries, and will be increasingly over time. If web content cannot be validated for appropriate presence of alternative text for images, it would not be possible to reliably demonstrate that HTML5 content conforms to WCAG 2.0 with regard to one of the most basic user requirements encoded in accessibility standards.

The relevant evidence regarding the need for alternative text on which accessibility standards are based is that there still are and will continue to be web users who are blind and partially-sighted, and who need to know what is in the images in web content, regardless of whether there's a generator tag somewhere in the page that they are using. Contrary to the HTML Co-Chairs' assertion, this isn't an assertion that this or that standard is wrong; it's based on an understanding that different standards have different scopes, and that the scope of an accessibility standard is to describe what is necessary for the technology covered by that standard to be accessible.

Whether or not there are any authoring tools that do not conform to ATAG 2.0, a draft specification that is not even a Recommendation, is irrelevant to the user requirements represented in WCAG 2.0; there remains a consistent end-user need for availability of alternative text in web content.

<strong>The argument against the <meta name="generator"> exception, regarding failure to harmonize with standards and guidelines, should have been evaluated as a very strong rather than a weak objection.</strong>

=== The "generator exception" inappropriately gives authoring tool conformance considerations precedence over end-user requirements (updated) ===

In their decision, the Co-Chairs asserted multiple rationales for retaining the generator exception based on the inconvenience that might otherwise result for authoring tool conformance:
<blockquote>
At least one Change Proposal argued that when a page is created by an automated content generation tool, and that tool indicates this using <meta name=generator>, it should be permitted to omit the alt attribute.

It was argued that there was a valid use case for the generator exemption, namely automated content generators which cannot produce alt themselves and for various reasons cannot or will not demand alt from the user. The following objection, though entered for role=presentation, directly argues one such use case:
<blockquote>
Consider a GUI authoring tool used by end-users, not professional Web developers or content authors. Such tools generate <img> elements, but it is not always appropriate for such tools to pause and demand alt text from the user before continuing.
</blockquote>
</blockquote>
Whether or not authoring tools prompt for alternative text at any given stage of document production process is immaterial. Even authoring tools that fail to prompt for missing alternative text nevertheless may permit the introduction of alternative text for images, or else can be used with other production tools that do provide that capability; so content authors are not prevented from creating appropriate alternative text. And even the Authoring Tool Accessibility Guidelines (ATAG), which address support for production of accessible content, do not recommend intrusive prompting. But regardless, whether or not an author was prompted for alt does not change the fact that the end-user requires it, and that the generator exception will interfere with determining whether of not the resulting document contains it.
<blockquote>
Several objectors cited this use case, and further pointed out that if content generators are forced to generate nonconforming markup to satisfy this use case, they may instead enter bogus alt values, which would merely exacerbate the problem:
<blockquote>
If an authoring tool or other generator does not have sufficient information to include either alternative text or a caption, there is nothing the tool can do. If we say that in those cases the authoring tool would be non-conforming if it didn't provide alternative text or a caption, then the tool will just provide bogus (placebo) alt="" attribute values, which just makes the problem non-machine-detectable instead. To address this, therefore, we should allow generator tools to include images without alternative text or captions if absolutely necessary.
</blockquote>
Also:
<blockquote>
I object to treating the absence of the alt attribute as a validation error when the generator mechanism is used, because if it is treated as an error in that case, generator developers are incented to generate bogus values in order to make their products emit markup that doesn't trigger errors. (There are always generator developers who want to make the output of their programs validate.)
</blockquote>
The use case of GUI tools that do not prompt for alt seems well established.
</blockquote>

While there may indeed may be authors who irresponsibly choose to enter bogus alternative text, knowingly violating the intended use of alternative text as an accessibility accommodation, this is not a reason to codify their bad practices by removing validation alerts for missing alternative text for content authors who would prefer to do the right thing and provide alternative text for images. Nor is this assertion even evidence-backed, as the Co-Chairs acknowledge in their most recent rejection of re-open requests of this issue...

<blockquote>
the claim of negative consequences to disallowing this use case was somewhat weakened by the lack of concrete evidence that bogus values have been used in the past or would be used in the future"
</blockquote>

...which acknowledged that no concrete evidence has been presented that bogus values had or would be used.

The lines of reasoning included here imply that considerations of authoring tool conformance should take precedence over end-user requirements for accessible web content. Given that alternative text is essential to understanding graphical web content for some web users, the proposed justification for the omission of alternative text based on conformance convenience for authoring tools, and validation convenience for content authors, is an inadequate counter-consideration to the needs of end-users for accessible content.

After examining a variety of arguments regarding the convenience of the generator exception for assessing conformance of authoring tools, without consideration of the experience of the end-users who require alt as an accessibility accommodation for graphical web content, the HTML Co-Chairs asserted that:
<blockquote>
After considering all these arguments, it seems established that there is a valid use case for allowing the alt attribute to be omitted when the generator mechanism is specified. This use case makes for a moderately strong objection. However, the claim of negative consequences to disallowing this use case was somewhat weakened by the lack of concrete evidence that bogus values have been used in the past or would be used in the future. So overall, this makes for a medium objection.
</blockquote>

Given multiple problems with the arguments above, the omission of alternative text in the presence of one or more generator tags has by no means been established as a valid case.

<strong>Regardless, to give it weight over end-user and author requirements is contrary to the [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies Priority of Constituencies principle] in the [http://www.w3.org/TR/html-design-principles/ HTML5 Design Principles], which states:</strong>

<blockquote>
3.2 Priority of Constituencies: In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
</blockquote>

<strong>These objections to the removal of the generator exception should have been no weight, when juxtaposed with the end-user requirements to have alternative text for images, and authors inconvenience caused by conformance-checking for production of accessible content that is interrupted by the presence of a generator tag.</strong>

=== Harmful consequences of the generator exception include harm to web authors and to web content users with disabilities (updated) ===

In their decision, the Co-Chairs mentioned survey comments that asserted harm from the omission of alt:
<blockquote>
Some argued that omitting alt and using the generator mechanism had harmful consequences:
<blockquote>
Hence, the generator mechanism should not have any bearing on the @alt requirements as the generator string/mechanism has no bearing on the attributes of the <img> or the context in which the img appears in. The negative effects of omission of an empty or non-empty @alt are in no way made up for by the presence of the generator mechanism.
</blockquote>
This statement in itself lacks specifics...
</blockquote>

The HTML Co-Chairs asserted that this statement lacks specifics. Breaking the statement down into specifics, this means that the harmful impact of missing alt, for web users who have visual impairments, is in no way made up for by the speculative benefit to authoring tools by the generator exception. When people with disabilities encounter accessibility barriers on websites, they may be unable to carry out essential activities in their lives, such as pursuing education, employment, health care, recreation, and so forth. When web content that omitted alternative texts doesn't trigger conformance errors because there was a generator tag on the page, this does nothing to fulfill the function that alternative text would have. Requirements for alternative text for accessibility support, and convenience of error-free conformance reports if the generator exception is sustained, are not tradeable one for the other. The presence of generator tags in web content does not provide a functional replacement for information about images that should have been provided by alternative text; neither does the presence of generator tags in web content serve as a replacement for sight.

To put this another way, in the Web Content Accessibility Guidelines (WCAG) 2.0, Guideline 1.1 is...
<blockquote>
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language
</blockquote>
and explained in the [http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv.html "Intent" section of Understanding WCAG 2.0 Guideline 1.1]...
<blockquote>
The purpose of this guideline is to ensure that all non-text content is also available in text. "Text" refers to electronic text, not an image of text. Electronic text has the unique advantage that it is presentation neutral. That is, it can be rendered visually, auditorily, tactilely, or by any combination. As a result, information rendered in electronic text can be presented in whatever form best meets the needs of the user. It can also be easily enlarged, spoken aloud so that it is easier for people with reading disabilities to understand, or rendered in whatever tactile form best meets the needs of a user.
</blockquote>
The specifics for the statement about harm quoted above are that the presence of the generator tag in web content does not make up for what alternative text would have provided to a web user who is blind.

The HTML Co-Chairs also asserted that lists of authoring tools inserting the generator tag had no evidentiary value, dismissing the notion that a significant amount of web content would use the generator exception:
<blockquote>
A list was provided of example <meta name=generator> values, and from this a conclusion was drawn that a tremendous amount of Web content would make use of the generator exemption. However, it's not clear where this list came from. It is not present in the spec, and does not seem to align with the spec's definition of a content generator. In particular, it includes many text editors which do not seem to qualify as automated markup generators. Was this list derived from the output of actual authoring tools? Was it found by looking at real Web content? In the absence of information about where this list came from, it was taken to have no evidentiary value.
</blockquote>

The generator exception does not differentiate between content generators and authoring tools that insert a generator string. Authors of all documents with a <meta name=generator> string would remain ignorant that their document had any missing text alternatives. The HTML Co-Chairs were mistaken to disqualify [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#HTML5_Should_Not_Facilitate_the_Creation_of_Inaccessible_Content the original evidence]. It was derived from searching and from examining tools that automatically insert a meta generator string and their resulting content. Since this initial evidence was provided, a [http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming#current_usage_of_meta_name.3Dgenerator_.28New.29 copious amount of further evidence of widespread use has been provided].

Other generator studies seem to indicate further usage of <meta name=generator>.

*[http://www.html5accessibility.com/HTML5data/dump/generator.html Windows Grep Search Results] - Steve Faulkner
*[http://philip.html5.org/data/dreamweaver-generators.txt dreamweaver-generators.txt] - Philip
*[http://philip.html5.org/data/generators.txt generators.txt] - Philip
*[http://philip.html5.org/data/underline-generators.txt underline-generators.txt] - Philip
*[http://lists.w3.org/Archives/Public/public-html/2011Apr/0580.html Generator Tools] - Leif Halvard Silli.

The HTML Co-Chairs also dismissed objections that a document-level generator option would make it easy for authors to forget to provide alternative text for images:

<blockquote>
...but there were some concrete arguments supporting the case for negative consequences:
<blockquote>
The generator mechanism facilitates the creation of inaccessible content.
</blockquote>
No evidence was provided that more inaccessible content would be created if the generator exemption is allowed than otherwise. So this was taken to be a weak objection.
</blockquote>

And, in a related argument, they rated an objection to the generator exception as moderately weak on the basis that there should have been sufficient time already for expanded evidence of harm from missing alt -- though it is unclear which authoring tools and validators, if any have already built in a generator exception for alternative text, and no time to accumulate statistical evidence of this presumed expanded harm.

<blockquote>
Another objection was based on the possibility of authoring mistakes:
<blockquote>
The generator mechanism is actively harmful to accessibility. If the generator option is left at document level, it would be far too easy for authors to have the software automatically insert "generator" and then forget to provide any text alternatives for images.
</blockquote>
If supported by concrete evidence, this would have been a strong
objection. This seems like a plausible authoring mistake which would
have negative consequences. But it was weakened by lack of any
specific evidence that this problem has actually occurred in
practice. This provision has been in HTML WG Editor's Drafts and
Working Drafts since September 3, 2009:

[http://dev.w3.org/cvsweb/html5/spec/Overview.html?rev=1.2915 http://dev.w3.org/cvsweb/html5/spec/Overview.html?rev=1.2915]

This should be enough time to see at least anecdotal evidence of the
claimed problem. Even though normally lack of supporting evidence
would render an objection weak, in this case, there is a
plausible-sounding argument even in the absence of evidence, so the
objection based on authoring mistakes is overall taken as moderately
weak.
</blockquote>

The HTML Co-Chairs appear to be arguing on the one hand that the generator mechanism is in sufficient use to merit an exception, while on the other hand dismissing objections to the generator exception by claiming that insufficient evidence was provided that the generator mechanism is in use. These arguments are contradictory.

The HTML Co-Chairs also appear to be arguing on the one hand that content authors would be bothered by validation failures in the event of missing alt, while on the other hand claiming insufficient evidence that the generator exception would undermine the creation of accessible content. These two arguments are especially contradictory.

Shawn Henry provides additional descriptions of how the generator exception will harm both authors and users:

<blockquote>
In my role as WAI Education and Outreach Coordinator and previous roles of accessibility specialist and usability specialist, I have evaluated the accessibility of web content, performed usability studies with web content authors, and trained people how to make accessible web content for nearly 20 years. Missing alternative text is one of the most common web accessibility errors.

From usability studies of content authors, I have observed two key reasons for missing alt text: 1. the nature of web content prototyping, and 2. content authors using authoring tools without knowing markup. When designers and developers are creating prototypes, they often skip alt text, because the focus is on other aspects of the prototype and they expect to add it later. However, adding alt text is often missed in later development.

The other situation is people who are not markup-savvy, and often not accessibility-savvy, who are updating content using authoring tools. Unless the tool requires them to add alternative text, most will skip it.

In both cases, authoring tools need to require alt text, and support authors in providing appropriate alt text. If generator-tagged web content is exempted from checking for alt text, the tools that people rely on to create standards-compliant content will be useless in providing this support. The result will be less accessible content and more accessibility barriers for people who are blind and others who rely on alt text.
</blockquote>

This evidence from usability observations of the workflow involving delayed alt-insertions following web content prototyping, and updating of web content by non-savvy web users who tend not to provide alternative text unless required, shows that the generator exception would reduce creation of alternative text by authors, increasing accessibility barriers for users.

<strong>These objections regarding harm to end-users with disabilities should have been evaluated as strong, not weak, objections to the generator exception, as they speak to the core issue of unmet user requirements resulting from exempting pages containing "generator" from the requirement to provide alternative text.</strong>

=== The weighting of objections against the "generator exception" is opaque (updated) ===

In the HTML Co-Chairs' [http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html April 2011 compound decision on Issue 31 and 80], they asserted that individual objections to the "generator" exception, on the whole, drew weaker objections than would removing the exception:
<blockquote>
Overall, there were many claimed disadvantages that flow from the generator exception, ranging from weak to moderately weak. They were generally unsupported by details or concrete evidence. Even though the use case for omitting alt when the generator mechanism is used was disputed and only found to be a medium objection, it still outweighs these claimed disadvantages, as they were all found to be weak or moderately weak.

Thus, on the whole, the proposal to allow alt to be omitted when the generator mechanism is used was found to draw weaker objections, compared to the proposal to still require alt, even when the generator mechanism is used.
</blockquote>

Within the "generator" portion of the HTML Co-Chairs' April 2011 compound decision on issues pertaining to alternative text, the Co-Chairs used six different levels of "weights" in evaluating the objections gathered in the survey: "strong," "moderately strong," "medium," "moderately weak," "weak," and "zero." These were presented without any definitions.

Further complicating the rating scheme, these levels were applied bidirectionally -- they were on the one hand applied to objections to the generator exception, and on the other hand, to objections to removing the generator exception, <strong>thus totaling twelve possible rankings for any argument, all without definition</strong>.

No point values were declared for any of the levels used in the decision, with the exception of "zero," making the individual weightings, as well as the aggregate scoring, unverifiable independently.

The opaque rating scheme made it difficult for interested stakeholders to follow, let alone to contest, the HTML Co-Chairs' rationale in maintaining the generator exception. It is difficult to accept the uniformly low weighting that was assigned to these numerous objections. Relevant arguments from the April 2011 decision were re-examined above, along with the weighting of those arguments, and have since been updated.

== Details ==

=== Change [1], at [http://www.w3.org/TR/2012/WD-html5-20120329/the-meta-element.html#meta-generator 4.2.5.1] ===

Remove:

<blockquote cite"http://www.w3.org/TR/2012/WD-html5-20120329/the-meta-element.html#meta-generator">
The value must not be used on hand-authored pages.
</blockquote>

=== Change [2] at [http://www.w3.org/TR/2012/WD-html5-20120329/the-img-element.html#guidance-for-conformance-checkers 4.8.1.1.13]===

Remove:

<blockquote>
The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text - validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.)
</blockquote>

== Impact ==

=== Positive Effects ===

* Authors can more safely assume that when they use a validator it will appropriately check the conformance of the document, rather than some arbitrary subset of requirements.
* The use of meta name=generator will not change in a way that is contrary to its current usage and effects.
* Authors will be made aware that they have not provided a text alternative giving them the opportunity to fix their error and produce a conforming document.
* Upholds the structural integrity of <img> element.
* Enables automatic validators to programmatically detect occurrences of the presence or absence of text alternatives. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=9218 Bug 9218].
* Facilitates accessibility awareness and education.
* Upholds the [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies HTML section 3.2. "Priority of Constituencies" Design Principle].

=== Negative Effects ===

* None

=== Conformance Class Changes ===

* The meta generator exception is removed from section 4.8.1.1.13 Guidance for conformance checkers. (Refer to Change [2] in the Details section of this document.)

=== Risks ===

# There are no risks in doing the changes.
# Risks to '''not doing the changes''' include:
##unmet user requirements, in that individuals who have visual impairments or other needs for alternative text will not have equitable access to web content;
##HTML5 conformance evaluation for <meta name="generator"> will assert false conditions on authoring tool production processes;
##The HTML5 spec will be ambiguous with regard to the hand-authoring test for alternative text in the presence of the "generator" tag.

ISSUE-194/TranscriptElement

Spfeiffe — Mon, 21 May 2012 11:31:06 GMT

Spfeiffe: turn examples into lists

[[Category:Issues]]

= Introduction of a <transcript> element =

Author: Media Subgroup of HTML Accessibility Task Force

In particular: Silvia Pfeiffer (Google), John Foliot, Janina Sajka, Charles McCathieNevile

Editors: Silvia Pfeiffer (Google), John Foliot

== Rationale ==

This is a proposal to address the need for video and audio transcripts through introduction of a <transcript> element and a @transcript attribute on HTML5 media elements.
It is based on an analysis of use cases for video transcripts and proposes a machine-discoverable, unified approach to realizing them with a dedicated rendering area for the transcript / transcript link.

__TOC__

== Summary ==

[http://www.w3.org/html/wg/tracker/issues/194 Issue 194] asks for a mechanism for associating a full transcript with an audio or video element. It does so by stating some requirements and a single use case, namely a link to an off-page transcript resource.

In the arguments of the different suggested Change Proposals, many different use cases appear, not just the off-page link use case.

In this CP we collect the different use cases for transcripts and address them in a uniform manner.

== The use cases ==

UC1: '''A full text transcript for the media asset is provided with the media resource in a ''separate but linked resource''.'''
(also T1 in the [http://www.w3.org/WAI/PF/media-accessibility-reqs/#transcripts Media Accessibility User Requirements])

Publishers that don't have captions often replace them with links to non-timed transcripts because [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-av-only-alt.html WCAG2 Success Criteria 1.2.1] explicitly mentions this as a solution. These linked documents are often not even in HTML.

Examples:
* [http://www.centrelink.gov.au/internet/internet.nsf/individuals/baby_bonus_video.htm Centerlink AU Gov site]
* [http://www.pm.gov.au/videos PM Australia videos], [http://www.state.gov/secretary/rm/2012/05/189592.htm US State Department]

UC2: '''A full text transcript for the media asset is provided as ''text on the same page'' of the media resource.'''
(also T2 in the [http://www.w3.org/WAI/PF/media-accessibility-reqs/#transcripts Media Accessibility User Requirements])

Examples of non-timed transcripts published underneath the video on-page:
* [http://www.manythings.org/b/e/5000/ ESL Videos]
* [http://foxnewsinsider.com/2012/05/04/video-transcript-hannity-takes-on-ows-organizer-in-explosive-interview/ Fox News]
* [http://www.commoncraft.com/video/rss RSS explained]

UC3: '''A full text [http://en.wikipedia.org/wiki/Interactive_Transcripts ''interactive transcript''] for the media asset is provided as text on the same page with the media resource and scrolls along in sync to the media resource.'''
(also T2 in the [http://www.w3.org/WAI/PF/media-accessibility-reqs/#transcripts Media Accessibility User Requirements])

Publishers that have a timed transcript (e.g. captions) provide an interactive transcript next to/underneath their videos.

Examples:
* [http://www.ted.com/talks/lang/mr/eli_pariser_beware_online_filter_bubbles.html TED video]
* [http://www.nytimes.com/interactive/2012/01/24/us/politics/state-of-the-union-2012-video-transcript.html NY Times]
* [http://dispatch.media.gbuild.net/video/14 educational video from vtt file of captions+descriptions]
* [http://johndyer.name/html5-video-player-with-slides-and-transcript/ DTS video player]
* [http://maddowblog.msnbc.msn.com/_news/2010/06/28/4576681-the-new-video-player-and-its-miraculous-transcript?lite Maddow Blog MSNBC]
* [http://www.globalnews.ca/decisioncanada/debate/index.html GlobalNews Dabate]

Video solution providers:
* [http://wistia.com/product/transcripts Wistia]
* [http://www.3playmedia.com/interactive/ 3Play]
* {http://www.protranscript.com/ ProTranscript]
* [http://speakertext.com/captionbox Speakertext]
* [http://clickablecaptions.com/captioning-with-instant-search/ ClickableCaptions]
* [http://dotsub.com/labs/interactiveTranscript DotSub]
* [http://www.subply.com/en/Products/InterActiveTranscript.htm SubPly]

This is a paradigm that Web developers often implement and often get wrong, so providing it by a Web browser is exciting new functionality.

Interactive transcripts are particularly useful to blind and vision-impaired users: they can scan through the text in the transcript with a screen-reader and click to activate video playback at a point in time that is of interest to watch the video/audio. This is similar to chapter markers, except that the full text transcript is being used to scan through the video rather than some (typically scant) chapter markers.

Interactive transcripts can be visually distracting. Therefore, browsers may provide an interactive means to allow users to hide interactive transcripts, e.g. by rendering a "minimize" control on the rendered transcript.

UC4: '''A full text transcript for the media asset is provided on a ''separate page'' to the media resource.'''

We sometimes see pages publish the transcript of an event without actual video or audio recordings.

Example:
* [http://allthingsd.com/20070531/d5-gates-jobs-transcript/ Gates Jobs at D5]
* [http://www.whitehouse.gov/it-gets-better-transcript White House]

== The Requirements ==

R1: '''Discoverability''' - the end user (sighted or otherwise) can discover that there is a transcript available; machines (AT, search engines, syndication) can discover that there is a transcript available.

R2: '''Choice to consume''' - the option to consume or not consume the transcript remains in the control of the user.

R3: '''Rich text transcripts''' - transcripts should be able to support richer content than flat text, including WebVTT files, HTML, RTF, Daisy or other formats.

R4: '''Design aesthetics''' - the transcript display needs to be stylable for design aesthetic, including the possibility to include it in the video controls.

R5: '''Embeddable''' - the transcript needs to be embeddable, i.e. given as a separate resource, but rendered full-text on-page.

R6: '''Fullscreen support''' - the transcript needs to be able to go fullscreen with the media element

R7: '''Retrofitting''' - it should be easy for authors who are already publishing content with transcripts to retrofit their existing pages.

R8: '''No link duplication''' - transcript link duplication should be avoided.

R9: '''Multiple transcripts''' - transcripts may be available in different languages - making multiple links available should be possible.

R10: '''Stand alone transcripts''' - transcripts need to be available even in browsers that do not support or do not render audio or video elements. In fact, it should be possible to render transcripts without requiring a media element be present on the same page.

== Proposed Solution: Overview ==

To deal with transcripts as first class citizens on the Web, we propose to introduce a <transcript> element.

Similar to how <article> or <footer> denote areas of particular semantic on Web pages, transcripts are text areas of particular semantic - also called a '''landmark'''. They are a div-like or iframe-like area on the Web page.

The <transcript> element is linked to a video or audio element, if presented on the same page, through a @transcript attribute, which contains one or more IDREFs to <transcript> elements.

Simple example:

<video transcript="foo" controls src="video.mp4"></video>
<transcript id="foo" lang="en" aria-label="English transcript"><a href="transcript.html">Transcript for video</a></transcript>

This makes the availability of the transcript discoverable from the video element and allows a visual representation of the availability of the transcript both on the video element and on the Web page.

The availability of a transcript MUST be announced by AT.

The transcript can be styled with CSS and hidden if necessary, while still being available to AT through the @transcript attribute on the video element.

== Details of the Proposed Solution ==

The proposal is for introduction of both a <transcript> element as a block-level element and a @transcript attribute on the HTMLMediaElement.

The @transcript attribute will consist of a space separated list of IDREFs.

The <transcript> element will have the following IDL (similar to div, but with track support):

interface HTMLTranscriptElement : HTMLElement {
readonly attribute TextTrackList textTracks;
TextTrack addTextTrack(DOMString kind, optional DOMString label, optional DOMString language);
};

The <track> element will be allowed to be used as a child of the transcript element before any flow content.

Also add "transcripts" to the list of UI controls that a browser vendor should include in [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#attr-media-controls default rendered media controls]:

''"If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user. This user interface should include features to begin playback, pause playback, seek to an arbitrary position in the content (if the content supports arbitrary seeking), change the volume, change the display of closed captions or embedded sign-language tracks."
''

Suggestion:

Add ''"or transcripts"'' to the end of that sentence.

=== Satisfying [UC1] linked transcripts ===

* Linked transcripts are in current practice typically provided through a visible URL underneath the video.

* This is a simple and effective solution and satisfies WCAG2.

* It provides visual exposure to all users and to old UAs and ATs.

* However, this approach does not integrate with the new HTML media elements (R5), nor are such transcripts machine discoverable (R1).

* We propose to embrace this approach through enclosing the typically used <a> element in a <transcript> element.

The proposed markup for this use case is:

<video transcript="t1" src=video.mp4 controls></video>
<transcript id=t1 lang="en" aria-label="English transcript">
<a href="transcript.doc">Link to the English transcript</a>
</transcript>

It renders as a link on the page in the location of the <transcript> element. The browsers are also encouraged to render an interactive control/switch on the video element that takes the viewer to the transcript. This control may be a menu and the value of the @aria-label attribute can provide the item text. However, this may adapt to device- and platform-specific native browser controls.

* If the <transcript> is made invisible (e.g. by rendering off-screen), this still enables the link to be present in the video player.

* Links to multiple languages can then be published either in the linked document or listed through several <transcript> elements:

<video transcript="t1 t2" src=video.mp4></video>
<transcript id=t1 lang=en aria-label="English transcript">
<a href="transcript.html">Transcript for the video</a>
</transcript>
<transcript id=t2 lang=de aria-label="German transcript">
<a href="transkript.rtf">Transkript fuer das Video</a>
</transcript>

This will render two links on the page and two menu items on the video player's transcript menu.

* Web browsers can render a menu on top of the video with the links off-page and the @aria-label attribute value as a "label" of the menu item.

* Since there is an <a> element inside the <transcript> element, this approach renders well in old browsers that do not yet support <transcript>.

=== Satisfying [UC2] on-page transcripts ===

* On-page transcripts are in current practice typically provided through a text block underneath or beside the video (in <p> or <div> or <textarea>).

* This is a simple and effective solution and satisfies WCAG2.

* However, this approach does not integrate with the new HTML media elements (R5), nor are such transcripts machine discoverable (R1).

* We propose to embrace this approach by encapsulating the given transcript inside a landmark <transcript> element to provide text directly on-page that is machine-discoverable:

<video transcript=t1 src=video.mp4></video>
<transcript id=t1>
<p>This is an on-page transcript of the video.</p>
</transcript>

* This is backwards compatible with browsers that do not yet support the <transcript> element.

* It provides visual exposure to all users.

* It is trivial for existing publishers to change their content to this approach by just adding a <transcript> element around their existing text content and to link it to a HTML5 video element.

* It is also possible to render an off-page HTML page into a <transcript> element by using an <iframe>:

<video transcript=t1 src=video.mp4></video>
<transcript id=t1>
<iframe src="transcript.html" style="width:200px; height:200px;"></iframe>
</transcript>

* Rich markup is also possible inside the <transcript> element.

* If the video and transcript want to be taken fullscreen together, the Web developer should add a <div> around the two and a button that would make the two go fullscreen together:

<div id="fullscreen">
<video transcript=t1 src=video.mp4></video>
<transcript id=t1>
<p>This is an on-page transcript of the video.</p>
</transcript>
</div>
<script>
var elem = document.getElementById("fullscreen");
elem.requestFullscreen();
</script>

* Similarly for embedding the video with the transcript, use a <div> around the two elements and copy that to another page (or use the iFrame trick of YouTube):

<div id="embed">
<video transcript=t1 src=PATH/video.mp4></video>
<transcript id=t1>
<p>This is an on-page transcript of the video.</p>
</transcript>
</div>

=== Satisfying [UC3] interactive transcripts ===

* [http://en.wikipedia.org/wiki/Interactive_Transcripts Interactive transcripts] are becoming more common now and increasingly understood what they typically look like and how they behave. For example, they are gaining acceptance within educational settings, where they re-enforce multi-modal learning practices.

* They are frequently requested by video publishers that have created interactive transcripts as a caption file, but who are not Web developers.

* Interactive transcripts are typically authored as timed text files in the style of WebVTT or TTML.

* Interactive transcripts typically sit next to or below the video or audio element that they transcribe and take up extra space, so cannot be part of the video's dimensions.

* Interactive transcripts interact with their video or audio element by keeping the currently displayed text in sync with the currentTime of the element.

* Interactive transcripts also allow manipulating the video's currentTime when a user clicks on a text segment.

* It is possible to re-use the <track> element inside <transcript> as a means to provide timed text for interactive transcript purposes:

<video transcript="t1" src=video.mp4></video>
<transcript id=t1 style="width:200px; height:200px" aria-label="English transcript">
<track src=transcript1.vtt srclang=en>
</transcript>
<transcript id=t1 style="width:200px; height:200px" aria-label="German transcript">
<track src=transcript2.vtt srclang=de>
</transcript>

This will render a full, interactive transcript into the <transcript> element and provide for the synchronization between the video and the transcript element's content position. The @kind value is not relevant in this case (for consistency purposes we could introduce @kind="transcript").

* The default rendering would be a section of text on the page with a link associated with each text segment that when clicked on will reposition the video's playback position to the time of the segment. (This follows common practices today: [http://www.3playmedia.com/interactive/interactive-transcript 1], [http://www.youtube.com/watch?v=IY3U2GXhz44 2]) In addition, playback of the video would move the display in the transcript element to have the text segment that relates to the current playback time visible and in focus. Basically it's a different rendering means of a text track file.

* It is also possible to provide interactive transcripts through JavaScript, for example:

<video id="v1" transcript="t1" src=video.mp4></video>
<transcript id=t1>
<script src="cues.js" type="text/javascript"></script>
<span data-for="v1" data-start="0" data-end="5">This is the text for the first cue of the transcript.</span>
<span>...</span>
</transcript>

* If the video or audio element fails to load, the <transcript> should never-the-less display, just without any interactive links. This takes us to UC4.

=== Satisfying [UC4] transcript-only pages ===

* Transcripts can easily be created from caption and description files.

* Sometimes publishers want to just publish a transcript (and no media element) on a page, or they may publish just a link to a media element, but not a full video element.

* The transcript element can create such a transcript with just text content and without a link to a media element.

* Example without a media element:

<transcript lang=en>
<a href="transcript.doc">Here is a transcript of the discussed podcast.</a>
</transcript>

* Example with a download video link next to the transcript:

<a href="video.mov">Download the video here</a>
<transcript style="width:200px; height:200px">
<track src=transcript1.vtt srclang=en default>
</transcript>
<transcript style="width:200px; height:200px">
<track src=transcript2.vtt srclang=de>
</transcript>

* Example with a download video link as part of the transcript:

<transcript>
This is a transcript of a <a href="SOURCE/video.html">video</a>.
<a href="video.mov">Download the video here</a>
</transcript>

* Example with a transcript that may itself contain a link to a video:

<transcript id=t1>
<iframe src="transcript.html" style="width:200px; height:200px"></iframe>
</transcript>

== Impact ==

'''Positive Effects'''

* A <transcript> element is a landmark element that provides for machine-discoverable transcripts.

* It supports all use cases, in particular linked and on-page transcripts and can also provide a native implementation of interactive transcripts using <track> elements.

* AT can announce the availability of a <transcript> when reaching the video element.

* If a particular Website doesn't want to show the transcript on the page, they can hide the <transcript> element from visual view. The programmatic association should not suffer in this scenario.

'''Negative Effects'''

* Requires introduction of a new element and a new attribute.

'''Advantages in comparison to a plain IDREFs @transcript attribute only'''

A @transcript attribute on the video/audio element alone cannot satisfy some of the needs for a generic solution for transcripts:

* There is no explicit semantic element that allows for the identification of transcripts - it all has to go through the video/audio element. Transcripts being semantically hidden and not explicitly called out on the page make them second-class citizens on the Web. This is particularly problematic for Use Case 4 where there is no media element on the page, but possibly a download link close or even part of the transcript element.

* A <transcript> element can receive an aria landmark so you can jump directly to them with AT - this is not possible for the indirect identification of transcripts through a video/audio element and impossible without a media element.

* There is a multitude of markup possibilities (IDREF to anchor, div, iframe, p, textarea, article, footer etc elements) but not a uniform solution. This is particularly problematic when providing default styling both by the browser and by the Web app developer. It is also much harder to find when manually editing or when scripting.

* A <transcript> element would be "sectioning content" and thus define the scope of headers, see http://www.w3.org/TR/html5/content-models.html#sectioning-content .

* Marking <a>, <div>, <p>, &;lt;iframe>, or any other element as a transcript-containing element is unclean and ugly - a <transcript> element is elegant and extensible for further new transcript-related features.

* There is no obvious means to provide a label for the transcript/transcript link that could be provided in a menu in the video element. For a <transcript> element we can use @aria-label (or something else more adequate).

* A @transcript pointing to a div or p element is essentially the same as pointing @aria-describedby at a div or p - these uses may become confused if transcripts are not more explicitly dealt with.

* Automated rendering of interactive transcripts from a TextTrack file is not possible with such a solution. However, interactive transcripts are a core requirement for blind users to be able to interact in a meaningful way with audio and video - DAISY devices are the living proof. Even if browsers won't implement automated rendering for TextTracks yet, at minimum the browser should expose parsed <track> elements as TextTracks to Web developers so they can render them themselves into a <transcript> element. Ultimately, it would be better to provide such interactive transcripts natively without the need for JavaScript.

* Even if the user forgets to mark up the video with an @transcript attribute, a <transcript> element will still be announced as transcript content to AT, thus being more robust.

* Transcript-specific features can be introduced more easily with an explicit <transcript> element, e.g. automatically download with the video page for offline viewing.

* Using an explicit <transcript> element actually encourages publishers to keep their transcripts visible on page and include them in their published content to the advantage of all users. It makes it a first class feature.

'''Conformance Classes Changes '''

* Requires support of a new element and potentially new attributes on video/audio.

'''Risks'''

* None.

=== Obsoletes the following Change Proposals: ===

* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP Introduction of a <transcript> element] (Silvia Pfeiffer)
* [http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_v2 Introduction of a new @kind value: "transcript"] (John Foliot)
* [http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange Defer ISSUE-194 until HTML.next] (Silvia Pfeiffer/Edward O'Connor)
* [http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposal/Issue194 Introduce a new attribute: @transcript] (John Foliot)

This CP remains: [http://www.w3.org/html/wg/wiki/ISSUE-194/Option3B Reuse the rel and for attributes to programmatically associate transcripts with media elements] (Edward O'Connor)

Related: [https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964 Bug 12964] - <video>: Declarative linking of full-text transcripts to video and audio elements

ChangeProposal/Issue194 SP

Spfeiffe — Thu, 10 May 2012 07:51:15 GMT

Spfeiffe: /* Details of Proposed Solution */

[[Category:Issues]]

= Introduction of a <transcript> element =

Author: Silvia Pfeiffer (Google)

== Rationale ==

This is a proposal to address the need for video and audio transcripts through introduction of a <transcript> element. It is based on an analysis of use cases for video transcripts and recommends means of realizing these use cases in HTML5.

__TOC__

== Summary ==

[http://www.w3.org/html/wg/tracker/issues/194 Issue 194] asks for a mechanism for associating a full transcript with an audio or video element. It does so by stating some requirements and a single use case, namely a link to an off-page transcript resource.

In the arguments of the different Change Proposals that have been made, many different use cases appear, not just the off-page link use case.

In this CP we argue that the different use cases for transcripts need to be listed individually and addressed in a uniform manner.

== The requirements ==

Issue 194 lists these requirements:

(1) people with disabilities need a way to access audio/video

(2) transcripts are often provided as a separate resource - we need to include a link to it

(3) the transcript needs to be discoverable for AT users

(4) the transcript needs to be programmatically identifiable by search engines

(5) the transcript needs to be programmatically identifiable for design aesthetic

(6) the transcript needs to be programmatically identifiable for content syndication

(7) the transcript needs to be embeddable (presumably: with the video)

Further requirements have [http://www.w3.org/html/wg/wiki/ISSUE-194/Research emerged in the discussion]:

(8) transcripts are useful to all users (e.g. skimming the content of a lecture)

(9) transcripts/transcript links need to be exposed to all users

(10) transcripts may be exposed in video controls, because when media elements are taken fullscreen, the transcript link still needs to be visible

(11) visibility of a transcript/transcript link should not remove programmatic identifiability

(12) it should be easy for authors who are already publishing content with transcripts to retrofit their existing pages

(13) transcript link duplication should be avoided

(14) transcripts may be available in different languages - linking to them should be possible

(15) transcripts may be embedded on the page - linking to that should be possible

(16) transcripts need to be available even in browsers that do not support or do not render audio or video elements

Note: We agree with most, but not all of these arguments, as will later become obvious.

== The use cases ==

In the [http://www.w3.org/WAI/PF/media-accessibility-reqs/#transcripts Media Accessibility User Requirements] document we have actually already identified existing use cases:

[T-1] Support the provisioning of a full text transcript for the media asset in a separate but linked resource, where the linkage is programatically accessible to AT.

[T-2] Support the provisioning of both scrolling and static display of a full text transcript with the media resource, e.g., in a area next to the video or underneath the video, which is also AT accessible.

More detailed, what we encounter in the wild are the following four real-world uses of transcripts:

[UC1] [http://en.wikipedia.org/wiki/Interactive_Transcripts '''Interactive transcripts''']: Publishers that have a timed transcript (e.g. captions) provide an interactive transcript next to/underneath their videos. Well-known examples here are YouTube and TED (e.g. [http://www.ted.com/talks/lang/mr/eli_pariser_beware_online_filter_bubbles.html TED video], [http://www.nytimes.com/interactive/2012/01/24/us/politics/state-of-the-union-2012-video-transcript.html NY Times]) and several other video player providers offer them (3ply etc).

[UC2] '''Linked Transcripts''': Publishers that don't have timed transcripts often replace them with links to non-timed transcripts because [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-av-only-alt.html WCAG2 Success Criteria 1.2.1] explicitly mentions this as a solution (e.g. [http://www.centrelink.gov.au/internet/internet.nsf/individuals/baby_bonus_video.htm Centerlink AU Gov site], [http://www.state.gov/secretary/rm/2012/05/189592.htm US State Department]). These are often not even in HTML.

[UC3] '''On-page Transcripts''': Sometimes we also see non-timed transcripts published underneath the video on-page (e.g. [http://www.manythings.org/b/e/5000/ ESL Videos], [http://foxnewsinsider.com/2012/05/04/video-transcript-hannity-takes-on-ows-organizer-in-explosive-interview/ Fox News]).

[UC4] '''Transcript-only pages''': Sometimes we even have Websites that only publish the transcript of an event without actual video or audio recordings. (e.g. [http://allthingsd.com/20070531/d5-gates-jobs-transcript/ Gates Jobs at D5], [http://www.whitehouse.gov/it-gets-better-transcript White House]).

== Observations ==

'''All four real-world use cases expose the transcript or transcript link explicitly on the Web page.'''

This makes sense, since transcripts are useful to all users (as requirement 8 states), and need to be exposed to all users (req 9).

'''None of the real-world use cases expose a transcript link button in the video player itself.'''

There is a reason this is not done: once in the video element - and in particular when full screen - everything that is clicked on keeps you in the video viewing experience - such a link wouldn't.

'''None of the real-world use cases expose a transcript link in the context menu either.'''

Context menus don't easily translate to touch devices, so advanced functionality is avoided in context menus.

'''When video players provide a fullscreen experience of a transcript with the video, it is an interactive transcript.'''

Players that have a transcript included (e.g. [http://buildamodule.com/tips-for-getting-the-most-out-of-the-video-player?overlay=1 Drupal BuildAModule]) are not just video players any more: they have an extra area next to the video in which the transcript is provided.

== Proposed Solution: Overview ==

To deal with transcripts as first class citizens on the Web, we propose to introduce a <transcript> element.

Similar to how <article> or <footer> denote areas of particular semantic on Web pages, transcripts are text areas of particular semantic, in particular interactive transcripts. They are a div-like or iframe-like area on the page that is linked to a video, if such a video is present on the page.

The <transcript> element should provide means to render timed text files as an interactive transcript where sections of text are linked back to video and clicking on them will move the video's playback position - similarly, a video's current playback time will influence what text in the interactive transcript is currently scrolled into view. This is a paradigm that Web developers often implement and often get wrong, so providing it by a Web browser is exciting new functionality.

The <transcript> element's content will also be available to display non-timed text, such as one or more links to off-page transcript resources, or an actual text-only transcript in one or more paragraphs.

The <transcript> element will be linked to a video or audio element if presented on the same page. It can be styled with CSS and hidden if necessary, while still being available to AT.

== Details of Proposed Solution ==

This section is still speculative in parts. It proposes actual markup features for the <transcript> element, the details of which still need to be worked out.

'''Satisfying [UC1] interactive transcripts'''

* Interactive transcripts are common now and it is well understood what they typically look like and how they behave that we should introduce a solution.

* Interactive transcripts are based on timed text files - WebVTT and TTML files can provide such data.

* Interactive transcripts sit next to the video or audio element that they transcribe and take up extra space, so cannot be part of the video's dimensions.

* Interactive transcripts interact with their video or audio element by keeping the currently displayed text in sync with the currentTime of the element.

* Interactive transcripts also allow manipulating the video's currentTime when a user clicks on a text segment.

The basic idea is to introduce a <transcript> element with a @for attribute that provides the link back to the <video> and a @src attribute that links to a text transcript with timing. The default rendering would be a section of text on the page with a link behind each text segment that when clicked on will reposition the video's playback position to the time of the segment. In addition, playback of the video would move the display in the transcript element to have the text segment that relates to the current playback time visible and in focus. Basically it's a different rendering means of a text track file.

A markup example could be:

<video id=v1 src=video.mp4></video>
<transcript for=v1 id=t1>
<track src=transcript1.vtt srclang=en default>
<track src=transcript2.vtt srclang=de>
</transcript>

* If the video or audio element fails to load, the <transcript> should never the less display, just without any timing links.
* If the video and transcript want to be taken fullscreen together, one should add a <div> around the two and allow that to go fullscreen.
* Similarly for embedding the video with the transcript, use a <div> around the two elements in an <iframe>.

'''Satisfying [UC2] linked transcripts'''

* Linked transcripts are currently provided through a URL underneath the video.

* This is a simple and effective solution and satisfies WCAG2.

* It provides visual exposure to all users and to old UAs and ATs.

* We can further integrate it with the interactive transcript proposal to achieve programmatic linkage.

A markup example could be:

<video id=v1 src=video.mp4></video>
<transcript for=v1 id=t1>
<a href=transcript.doc>Transcript for the video</a>
</transcript>

* It is trivial for existing publishers to change their content to this approach by just adding a <transcript> element around their existing link.

* Links to multiple languages can then be published either in the linked document or listed inside the <transcript> element.

'''Satisfying [UC3] on-page transcripts'''

* On-page transcripts are currently provided through a text block underneath the video (in <p> or <div> or <textarea>).

* This is a simple and effective solution and satisfies WCAG2.

* It is possible to use the content of the <transcript> element to provide text directly on-page. That would, however, have no timing adjustments with the video.

* It provides visual exposure to all users and to old UAs and ATs.

* We can further integrate it with the interactive transcript proposal to achieve programmatic linkage.

A markup example could be:

<video id=v1 src=video.mp4></video>
<transcript for=v1 id=t1>
<p>This is a on-page transcript.</p>
</transcript>

* It is trivial for existing publishers to change their content to this approach by just adding a <transcript> element around their existing text content.

* Different language transcripts would in this example typically be provided by loading the Web page in a different language (i.e. under a different url).

'''Satisfying [UC4] transcript-only pages'''

* Transcripts can easily be created from caption and description files.

* Somstimes publishers want to just publish a transcript (and no media element) on a page.

* The transcript element can create such a transcript.

A markup example could be:

<transcript>
<track src=transcript1.vtt srclang=en default>
<track src=transcript2.vtt srclang=de>
</transcript>

* This would automatically render the text in the timed text resources on the page, however without links to the video, since there is no video rendered.

'''Details to work out:'''
* I don't actually know how to render a selection mechanism between different track elements. A menu could be rendered as part of the text block. Or instead it could be done in the video element and influence the rendering in the <transcript> element.
* It might be better to put the programmatic linkage (currently done through @for) onto the video element (then through @transcript) to avoid full page searches for related elements.

== Impact ==

'''Positive Effects'''

* A <transcript> element will provide a native implementation of interactive transcripts and also support linked and on-page transcripts.

* AT can announce the availability of a <transcript> when reaching the video element. In particular if we choose the @transcript method.

* If a particular Website doesn't want to show the transcript on the page, they can hide the <transcript> element from visual view. The programmatic association should not suffer in this scenario.

* Is a better solution for long text alternatives than @longdesc or @aria-describedAt, since it also solves the interactive transcript need.

'''Negative Effects'''

* Requires introduction of a new element.

'''Conformance Classes Changes '''

* Requires support of a new element and potentially new attributes on video/audio.

'''Risks'''

* None.

ChangeProposal/Issue194 v2

Jfoliot — Wed, 09 May 2012 03:17:30 GMT

Jfoliot: /* Examination of some misconceptions and false assumptions */

= Change Proposal: introduction of a new @kind value: "transcript" =
<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; margin-bottom:1em!important; width: 70%; font-size:0.9em;">
*The following is a Change Proposal for [http://www.w3.org/html/wg/tracker/issues/194 ISSUE-194 (full-transcript)].
* Editor: John Foliot (Based on [http://www.w3.org/html/wg/wiki/ISSUE-194/Research research done by Edward O'Connor].
* This version reflects significant modifications to the [http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposal/Issue194 original Change Proposal], made after extensive discussion at the Mountain View Face-to-Face meetings May 3rd & 4th, 2012.
* Date: May 8, 2012. (Last updated May 8th, 2012)
</div>

== Rationale ==

Raised from bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964

Full transcripts give people with disabilities a way to access audio/video
content. Transcripts are often provided as a separate resource, because they're
often too lengthy to be included on the same page as the audio/video they're
associated with.

A mechanism that creates an association between an audio/video element and a
full (off page) transcript would have many benefits. These include
discoverability for assistive technology users, programmatic identification for
search engine indexing, design aesthetic, and content syndication or
embedding.

__TOC__
== Summary ==

As part of it's initial work for Media accessibility in HTML5, the Accessibility Task Force sub-team charged with this effort produced a document, the [http://www.w3.org/WAI/PF/media-accessibility-reqs/ Media Accessibility User Requirements] which outlined all of the different requirements that various user groups would need with regard to the HTML5 media elements.

For transcripts, the requirements state, in part:
<blockquote>
<p>A transcript can either be presented simultaneously with the media material, which can assist slower readers or those who need more time to reference context, but it should also be made available independently of the media.</p><p>A full text transcript should include information that would be in both the caption and video description, so that it is a complete representation of the material, as well as containing any interactive options.</p><p>Systems supporting transcripts must: <br>'''[T-1] Support the provisioning of a full text transcript for the media asset in a separate but linked resource, where the linkage is programatically accessible to AT.'''</p>
</blockquote>

After evaluating a number of different design patterns researched by Edward O'Connor, it became obvious to members of the Accessibility Task Force that the best candidate to support the Transcripts requirement was to put the transcript information in the body of the media element, by extending the <code><track></code> element with the introduction of a new @kind value: transcript.

Sample markup:

<nowiki><video src="video.mp4">
<track kind="transcript"
src="transcript.html"
srclang="en"
label="English language transcript">
</track>
</video></nowiki>

As [http://www.w3.org/html/wg/wiki/ISSUE-194/Research#4A_-_reuse_the_track_element Edward noted in his research], it's easy to author and to update existing content to use this markup pattern. We can link to external resources as well as another node in the current document. As well, you can link to many transcripts, and you can use the existing <code>srclang=""</code> attribute to hint to the UA about the language that each transcript is in. Finally, the programmatic association of the <code><video></code> with its transcript would be maintained through a cross-document copy-and-paste operation.

Further discussion at the May Face=to-Face meetings also suggested that it was a simpler authoring pattern to teach content creators, that the pattern would lend itself more easily to WYSIWYG authoring tools (where one modal dialog assistant could allow authors to select all of the different accommodation assets at one time, in one location), and did not impose any design restrictions on content authors (a.k.a. the "D link" problem), as the common controls associated with the <code><video></code> element would serve to expose the Transcript to all users, sighted or non-sighted alike.

=== Examination of some misconceptions and false assumptions ===

In Edward's research, he also made some assumptions and statements that warrant further investigation. He states:

<blockquote>
Transcripts are untimed, not timed text, so this is abusing the semantics of <code><track></code>.
</blockquote>

'''Response:''' this presumes all transcripts will not have any form of timing information associated to them. This is a false presumption; the Media Requirements state: ''"A transcript can either be presented simultaneously with the media material, which can assist slower readers or those who need more time to reference context"'' - which would require some form of timing information to achieve.

The requirements also state: ''"A full text transcript should include information that would be in both the caption and video description, so that it is a complete representation of the material, as well as containing any interactive options."'' - once again interactivity, while not specifically noted as requiring timing, likely could use timing as part of the interaction scripting.

It was also commented at the Face-to-Face that currently the <code>@kind="metadata"</code> specifically does not define how that metadata should be processed by the UA, and does not forbid it from being non-timed content.

Finally, it was noted that at least one time-stamp format currently (soon to be) supported in at least one browser, TTML, has a [http://www.w3.org/TR/ttaf1-dfxp/#metadata-attribute-role role of ''transcript''] which authors today may use.

<blockquote>
This design does not lead to a good experience in UAs that do not support the <code><video></code> element, nor in UAs that support <code><video></code> but not <code>transcript=""</code>.
</blockquote>

'''Response:''' there is nothing in HTML5 that forbids authors from placing a standard link to the transcript inside the <code><video></code> element as a form of "fallback" content: UAs that do not support <code><video></code> will render the link as fallback content.

Assertions that UAs would not or could not support <code>@kind="transcript"</code> are unfounded at this time, and there is no reason or evidence why UAs that will support other <code><track></code> kinds will be unable to support <code>@kind="transcript"</code>.

<blockquote>
<p>This design does not readily expose the transcript link to users. Should the Web author want to expose the transcript link to her page's readers, she would have to duplicate the link in markup... <snipped></p><p>In such a scenario, the duplicate links may get out of sync as the page is maintained and the location of the transcript changes. It is likely that the visible link will be more up to date than the invisible link, thus harming AT users.</p>
</blockquote>

'''Response:''' given the newness of HTML5 video content overall, and the still emergent support for any kind of support for the <code><track></code> element and <code>@kind</code> attribute, it is premature to suggest that it would be difficult for users to 'discover' the transcript. UAs have an opportunity to expose the <code>kind="transcript"</code> content in any fashion best suited to the UA/hardware configuration. Accessing the transcript will be no more or less difficult than accessing captions, subtitles or other <code>@kind</code> values in emergent UA players, and could reuse existing patterns/designs used for other <code>@track</code> content, including but not limited to media control buttons, addition to a drop-down menu along side sub-title options, etc. Further, as yet another <code><track></code> value, advanced authors will be able to easily script other exposure/rendering solutions to meet specific design demands.

(<opinion>Given half a chance, there are many smart and talented designers who will solve this issue with elegance and panache</opinion>)

Assertions that transcripts linked on a page using the standard anchor tag would be more up-to-date than transcripts linked via <code>@track</code> cannot be proven or dis-proven at this time. There is no evidence to suggest that transcripts would somehow become less up-to-date than closed-captions or subtitles associated to the same video using <code>@track</code>, and in fact if [http://john.foliot.ca/wysiwyg_longdesc/ current examples of WYSIWYG's handling of <code>@longdesc</code>] are any indication, emergent modal dialogs for inserting <code><video></code> into web pages and Content Management Systems will likely manage this quite effectively.

If the accuracy question is one of significant concern, then it would apply to all assets linked via <code>@track</code>, and not exclusively to the Transcript.

== Details ==

== Impact ==

=== Positive Effects ===

* Unknown

=== Negative Effects ===

* Unknown

=== Conformance Classes Changes ===

* Unknown

=== Risks ===
* Unknown

== References ==

* [http://www.w3.org/WAI/PF/media-accessibility-reqs Media Accessibility User Requirements] - W3C Editor's Draft 14 December 2011
* [http://www.w3.org/html/wg/wiki/ISSUE-194/Research Possible methods for associating transcripts with media elements] - Author: Edward O'Connor (Apple)
* [http://www.w3.org/TR/ttaf1-dfxp Timed Text Markup Language (TTML) 1.0] - W3C Recommendation 18 November 2010
* [http://john.foliot.ca/wysiwyg_longdesc/ WYSIWYG support for @longdesc today] - Author: John Foliot

__NOTOC__

Correct Hidden Attribute Section v3

Jfoliot — Tue, 08 May 2012 00:23:26 GMT

Jsajka: /* Correct the hidden Attribute Section */

[[Category:ChangeProposal]]

= Correct the <code>hidden</code> Attribute Section =

__NOTOC__
<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; width: 70%; font-size:0.9em;">
*The following is a Change Proposal for [http://www.w3.org/html/wg/tracker/issues/204 HTML5 ISSUE-204 aria-hidden].
* Editor: Cynthia Shelly (Based on [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden Laura Carlson's proposal], [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions John Foliot's note], and [http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden Jonas Sicking, Matt Turvey, Edward O'Connor's proposal], as well as Version 2 of the draft CP.
* This version reflects modifications to the V2 Change Proposal, made in consultation with Edward O'Connor at the Mountain View Face-to-Face meetings, and removes the restriction for browsers to improve support of ARIA attributes whenever possible - a strong objection from the browser vendors. It now also incorporates RFC 2119 language requirements which can be adopted by conformance checkers.
* Date: May 4, 2012. (Last updated May 8th, 2012)
</div>

== Summary ==

Authors sometimes want to provide a label or description to users of Assistive Technology, and to do so without any visual encumbrance or default visual indicator. They can already do this with CSS <code>display:none</code> and <code>visibility:hidden</code>, and should be able to do the same with the simpler <code>@hidden</code> attribute. The ARIA spec allows <code>aria-describedby</code> and <code>aria-labelledby</code> to reference hidden elements, so this change will correct the [http://dev.w3.org/html5//spec-author-view/editing.html#the-hidden-attribute <code>hidden</code> attribute section] to bring it into conformance with the ARIA specification and ARIA functionality. In addition, this would make the behavior of <code>@hidden</code> consistent with the long-implemented behavior of CSS display:none and visibility:hidden with HTML <code><label></code> and <code>aria-labelledby</code>.
__TOC__

== Rationale ==
=== Use Cases ===

Web authors often wish to provide a description of a complex element only to screen reader users, while hiding the description from all other users. Being able to provide such a description without any forced visual encumbrance or default visual indicator is a frequently-cited accessibility requirement.

==== Example 1====
Consider the following markup:

<pre><pre role=img aria-describedby=foo >
)\._.,--....,'``. fL
/, _.. \ _\ ;`._ ,.
`._.-(,_..'--(,_..'`-.;.'
</pre>
<p id=foo hidden>An ASCII art rendition of a cat in prone position.</p></pre>

This example contains an ASCII art rendition of a cat inside a <code><pre></code> element. A description of the art is provided for AT users. By using <code>aria-describedby</code> to point at a <code>@hidden</code> element, the web page author avoids any forced visual encumbrance or default visual indicator.

==== Example 2 ====
<code>

<input aria-labelledby="foo" type=text><input type=image src="search.png" alt="Go!">
<div id="foo" hidden>Search</div>

</code>

In this example, a short plain-text string is used to label the text input, and that label is hidden from view. For visual users, the text box followed by a looking glass icon is a well-known visual pattern for a search function. The hidden label makes this clear to users who cannot see the text box or graphic.

==== Example 3 ====
<code>
<input aria-labelledby="foo" type="text" onmouseover="showFoo();" onmouseout="hideFoo();">
<input src="go.gif" type="image" alt="Go!">
<div id="foo" hidden><img src="decorative-image.gif" alt="">Search</div>

</code>

This example shows a variation of Example 2 where the label has a decorative image, and is shown to visual users onmouseover. Since the image gives no real information, it has null alt text. The hidden label is used to give the screen-reader user more information via the accessibility API, so that he does not need to navigate to the tooltip. The accessible name in the accessibility API tells him exactly what that text is for, where a popup tooltip would require more cognitive overhead. However, the popup tooltip, with it's pretty graphic, is shown to improve the experience of sighted users who are exploring the input. Since the screen-reader user does not use a mouse, and does not trigger the mouseover, he gets an experience that works for him, and the sighted user gets one that works for her. (Caveat: This is not a great piece of UI design for exploring an input by a sighted user. It is offerred as a simple example of where one might want to flatten the text for some users.)

The <code>@hidden</code> attribute is a mechanism for hiding elements in HTML. Given this, authors are likely to use it to hide content. The WAI-ARIA specification allows <code>aria-describedby</code> to point at non-visible content, so it is reasonable for authors to expect such markup to function properly. Because authors rarely run their content through conformance checkers, authors are likely to point at <code>@hidden</code> content from <code>aria-describedby</code> whether or not we forbid them from doing so. Therefore it is incumbant to document what can, and what cannot be achieved through these techniques.

=== Feedback from Browser Implementers ===

Two people working for browser implementers have suggested that exposing hidden elements in the accessibility tree is feasible, and similar to the work already under way to expose hidden child elements of the <code><canvas></code> element:

<blockquote>I don't think Apple has a strong stance either way on using @aria-describedby to point to @hidden elements, but I believe we could reasonably expose full semantics of hidden content pointed to by aria-describedby, this is more or less the same as the work we'd have to do to expose <canvas> children as an accessible tree.</blockquote>

[http://lists.w3.org/Archives/Public/public-html/2012Feb/0060.html Maciej Stachowiak, Apple]

In addition, this is the behavior that is specified for <code>@aria-describedby</code> in the ARIA User Agent Accessibility Guidelines (see below), and it is currently implemented in Safari.

<blockquote>In firefox, the reason that @hidden elements are "stringified" when
exposed through aria-describedby is because they don't have CSS boxes.
This is also why we have problems currently when exposing the contents
of a <canvas>. In both cases the accessibility code "fails" because it
tries to use the CSS boxes which aren't there. Hence the fallback to
stringify.</blockquote>

<blockquote>Exposing the rich semantics of contents inside a <canvas> in Firefox
will take a lot more than changing what object <canvas> inherits from.
Whatever solution we come up with for that can hopefully be reused to
expose the rich contents of @hidden elements exposed through
aria-describedby.</blockquote>

<blockquote>We now have two implementations which say that exposing the rich
contents of @hidden elements pointed to using aria-describedby is
implementable. And is implementable without changes from AT vendors.</blockquote>

[http://lists.w3.org/Archives/Public/public-html/2012Feb/0085.html Jonas Sicking, Mozilla]

There are similar constructs in Internet Explorer. For example, an aria-labelledby that references an element with CSS visibility:hidden or display:none will populate the accessible name for that element in IE9. Similarly, the accessible name of an input element will be populated with the text of it's associated label element, even if that label element is hidden with CSS visibility:hidden or display:none. This has been true in IE since IE 5 or 6. Having <code>@hidden</code> behave differently sets up a confusing situation for developers of both web applications and assistive technologies.

=== Compatibility and interoperability with ARIA 1.0 ===

As [http://lists.w3.org/Archives/Public/public-html/2012Apr/0046.html Richard Schwerdtfeger succinctly stated on April 9, 2012],

<blockquote>
The HTML 5 reference to aria-describedby is inaccurate as hidden text is
loaded into the accessible description string in an accessible object even though no accessible object representing the text description is exposed in the accessibility API.
</blockquote>

Because of how APIs work, any hidden content referenced by an ARIA attribute is rendered as a plain-text string. The [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions ARIA Can Only Refer To Hidden Content With Specific Restrictions change proposal] explains this in detail:

<blockquote>
The issue of whether or not hidden content could be referenced by ARIA attributes has actually been discussed by the ARIA Working Group, as recently as [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html March 2012].

The outcome of the ARIA WG's latest discussions has resulted in changes to the [http://www.w3.org/WAI/PF/aria-implementation Draft ARIA Implementation Guide] which speaks specifically to this Issue:

<blockquote>
<strong>[http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements 5.1.2. Excluding Elements from the Accessibility Tree]</strong>
<p>The following elements are not exposed via the accessibility API and user agents <strong class="rfc2119">MUST NOT</strong> include them in the accessibility tree</p>

* Elements with <code>role="[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]"</code> according to the rules for <code>[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]</code> role defined in <cite>[http://www.w3.org/WAI/PF/aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0]</cite>.

* <strong>Elements, including their descendents, that have host language semantics specifying that the element is hidden, such as CSS <code>display:none</code> or <code>visibility:hidden</code> or HTML 5 <code>hidden</code> attribute. </strong>
</blockquote>
The net effect of this is that any hidden content referenced by an ARIA attribute will be left to <strong>render as string text only</strong>, as it is forbidden by ARIA Processing rules, as well as the various Accessibility APIs (AAPIs), to take on any other role...

For this reason, any text that is hidden but referenced by an ARIA attribute will have limited, but not zero, value to screen reader users with AAPI aware tools.

So, to the question of "Should HTML5 permit ARIA attributes to reference (point to) content that is hidden from the visual view-port of sighted users?" the answer is, <u>it already can</u>.
</blockquote>

UAIG says that hidden elements are not exposed via the accessibility API, and this may be the cause of confusion. The intention was to forbid hidden elements from being exposed *as separate accessibility objects in the accessibility api object tree*. This was not intended to forbid mapping text from hidden objects to properties of other objects in the accessibility api tree. We will add an issue to UIAG to add a note to this effect.

However, section '''5.6.1.3. Text Alternative Computation''' of UIAG states explicitly that authors can provide plain-text strings for the accessible name and description via aria references to hidden elements, and that browsers are to process them as plain-text strings for these fields.
<blockquote>1.Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby being used in the current computation. By default, users of assistive technologies won't receive the hidden information, but an author will be able to explicitly override that and include the hidden text alternative as part of the label string sent to the accessibility API.</blockquote>

In addition, UAIG Section '''5.5.1. State and Property Mapping Table''' describes the use of aria-describedby and aria-labelledby in name and description calculation, and makes no mention of special treatment based on hidden state.

{| border="1"
! rowspan="1" colspan="1" |
WAI-ARIA State or Property
! rowspan="1" colspan="1" |
MSAA UIA Express
! rowspan="1" colspan="1" | MSAA IAccessible2
! rowspan="1" colspan="1" |
UIA
! rowspan="1" colspan="1" |
ATK/AT-SPI
! rowspan="1" colspan="1" | Mac OS X
|-
| rowspan="1" colspan="1" |
[http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby <code>aria-describedby</code>]
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.

If the object is in the accessibility tree, expose pointer to the accessible object in <code>IA2_RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation].

Expose pointer to the accessible object in <code>DescribedBy</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose pointer to the accessible object in <code>RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>string AXDescription</code> (reserved for non-visible accessible name or calculated description)
|-
| rowspan="1" colspan="1" |
[http://www.w3.org/WAI/PF/aria/states_and_properties#aria-labelledby <code>aria-labelledby</code>]
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>accName</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>accName</code> property.

Expose a reference to the accessible object in <code>IA2_RELATION_LABELLED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>Name</code> property.

Expose a reference to the accessible object in the <code>LabeledBy</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation].

Expose a reference to the accessible object in <code>RELATION_LABELLED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [#mapping_additional_nd Name Computation]. Expose in <code>string AXTitle</code> (reserved for visible name)
|}

====Accessibility API mappings====
When aria-labelledby and aria-describedby reference an element that '''IS NOT''' hidden, the following things happen:
# An Accessible Object is created in the Accessibility API tree for both the referencing and the referenced elements.
# In APIs that support such relationships, a relationship is created with bi-directional pointers between the objects. This can be used by AT products to find the referenced element and navigate to it.
# A DOM relationship is created between the referencing and referenced elements. DOM-based AT products, or browsers themselves, can use this to build UI that allows users to navigate to the description.
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

When aria-labelledby and aria-describedby reference an element that '''IS''' hidden, the following things happen:
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

Name calculation is what is at issue in this CP. It happens whether the referenced items are hidden or not. When the referenced items are hidden, then the relationships for navigation are not created. Again, this is ALREADY TRUE for CSS display:none and visibility:hidden, and has been true in browser implementation for years.

The structure of the referenced element is flattened in name calculation because properties where it is placed are of type string. In MSAA, for example, each accessible object is a COM object with properties of type string for the name and description. For more information, see the MSDN documentation for [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.aspx IAccessible], the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accdescription.aspx AccDescription] property, and the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accname.aspx AccName] property.

== Details ==
===Remove===

<p>The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.</p>

<p>Elements that are not hidden should not link to or refer to elements that are hidden.</p>

<p>For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. If the content is not applicable or relevant, then there is no reason to link to it.</p>

<p>It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.</p>

===Add===

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive.

Elements that are not themselves hidden must not hyperlink to elements that are hidden. Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements. For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate.

However, hidden elements '''MAY''' be used to provide descriptive text if such content provides a good user experience, by using aria-describedby and aria-labelledby and HTML labelling elements such as <label>, <legend>, <caption>, and <figcaption>.
Authors '''SHOULD NOT''' use hidden elements for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), as some user-agents/AT will flatten the referenced elements to plain text, losing interactivity and semantic structure.

===Remove===

It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

== Impact ==

=== Positive Effects ===
* Makes the behavior of references from aria-describedby to elements with the @hidden attribute consistent with long-implemented browser behavior for references to content hidden with CSS display:none and visibility:hidden using <label> and aria-labelledby. This is a good example of documenting the web as it is.
* Provides a simple, consistent way for UAs to hide content from sighted users while exposing it to AT via the accessibility API.
* Allows authors to provide in-place information to AT users in scenarios where doing so provides the best user experience.
* Has no impact on scenarios where navigating to another location for additional information provides the best user experience.
* Provides an intuitive way for authors to hide content from sighted users. If you want your description to not be visible, put a hidden attribute on it, just like other contents that you don't want to be visible by default.
* Corrects the HTML5 specification with what in reality, ARIA actually says and does.
* Authors are told to not use a technique that does not work, e.g., hidden cannot support HTML-rich, structured content such as headings, paragraphs, list markup, table markup, anchor text, or inline content (such as <span>).

=== Negative Effects ===

* See Risks.

=== Conformance Classes Changes ===

* No change.

=== Risks ===

* Some authors will misunderstand the limitations of what can be achieved using ARIA, and will point aria-describedby to hidden structured text. Browsers will flatten that structure to a string and populate the accessible name and description fields in the accessibility API, which can cause a poor user experience for screen reader users. There have not been many reports of problems with this--the existing <label> and aria-labelledby functionality with CSS display:none and visibility:hidden, but since descriptions are often longer, it may be more of a problem with descriptions.

== References ==

* [http://www.w3.org/TR/wai-aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0] (W3C Candidate Recommendation)
* [http://www.w3.org/WAI/PF/aria-implementation WAI-ARIA 1.0 User Agent Implementation Guide] (W3C Editor's Draft)
* [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html Action-970 (PF) Publish F2F Minutes Extract RE ARIA-Describedby]

ChangeProposals/Issue31cMetaGenerator

Jbrewer — Wed, 02 May 2012 06:02:58 GMT

Jbrewer: /* Updated Re-Open Request and Change Proposal on Meta Generator */

=Updated Re-Open Request and Change Proposal on Meta Generator =
*The [[#toc|table of contents]] immediately follows the Summary.
*Authors: Judy Brewer, Mike Smith
*Contributors: Laura Carlson, Janina Sajka
*Status: Ready for review

== Summary ==
'''This change proposal:'''
* '''provides background on prior discussions regarding meta name="generator";'''
* '''identifies new information regarding deficiencies in specification of the "generator" value;'''
* '''identifies deficiencies in the weighting of evidence for and against removing the "generator exception";'''
* '''re-frames the core question as one of end-user requirements rather than authoring tool conformance considerations;'''
* '''provides details and describes the impact of the proposed changes.'''

A requirement for alternative text on images in HTML has existed for fifteen years in order to help ensure accessibility of Web content for people with disabilities. The HTML Co-Chairs have previously decided that HTML5 should allow missing alt to be evaluated as conformant for any pages which include the string <code><meta name="generator" /></code>, a value that is automatically inserted by a variety of types of authoring and content management tools to indicate tools used in creating a page or processing content on the page.

This conformance exception for pages that contain the "generator" value for meta name exempts images on a large portion of pages on the web from an accessibility requirement that is essential to effective use of the web by blind users. This exception has been based on misunderstandings about the authoring production process, and ambiguous criteria about hand-authoring.

This re-open request and change proposal (CP) presents new information regarding inaccuracies and ambiguities in the specification of the "generator" value, and proposes removing the sentence "The value must not be used on hand-authored pages" in order to address these problems.

This CP also re-analyzes the Co-Chairs' previous decisions in favor of the <code><meta name="generator" /></code> exception and against the requirement for alternative text, identifying factual and logical inaccuracies. It describes the harm that is done by the generator exception, and proposes removing the generator conformance exception in order to address these problems.

__TOC__

== Rationale ==

=== Background of "generator exception" discussion ===
This proposal is an updated re-open request for a change proposal on the <meta name="generator"> exception for alternative text, with an extensive discussion history going back several years. Key steps have included:
* [http://www.w3.org/html/wg/tracker/issues/31 Issue 31: Author conformance requirements for the alt attribute on images]
** (Includes comprehensive reference links for this topic)
* [http://www.w3.org/2002/09/wbs/40318/issue-31-80-validation-objection-poll/results#xwarning Survey regarding objections to "generator exception" for alternative text]
**(Question: Should it be permitted to omit alt when the generator mechanism is present?);
** [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElementSurveyConformaceChoices Change proposal choices for Alt Issue 31]
* [http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html HTML Co-Chairs' decision against removing the "generator exception"];
* [http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming Steve Faulkner's reconsideration request for removal of the "generator exception"];
* [http://lists.w3.org/Archives/Public/public-html/2012Feb/0237.html HTML Co-Chairs' rejection of Steve Faulkner's re-open request.]

=== The specification of the "generator" value is deficient ===

The current specification of the "generator" value for meta name is:

<blockquote>
The value must be a free-form string that identifies one of the software packages used to generate the document. The value must not be used on hand-authored pages.
</blockquote>

There are two significant deficiencies in this statement:

==== Fatal ambiguity in the specification ====

The specification introduces the authoring-conformance constraint that a meta generator element must not be used on "hand-authored" pages. However, it does not define what a "hand-authored" page is, and the definition of that term is not obvious. That lack of a clear definition for "hand-authored" is thus a fatal ambiguity in the spec -- fatal in the sense that it entirely undermines the implicit rationale that the spec uses for excepting certain documents from the requirement to provide alternative text for images, which is based completely on the assumption of the possibility of clearly making a distinction between a supposedly "hand-authored" page and a supposedly non-"hand-authored" page.

It is not at all clear whether a "hand-authored page" is intended to mean, for example, a document that was created in a text editor without using any post-processing tools at all, or whether it can mean a page that was at some point created with an automated tool of some sort, but subsequently was edited exclusively in a text editor or other tool.

It is also worth noting -- regardless of what the ambiguous term "hand-authored" was intended to mean -- that given a document in isolation from its author, it is impossible to know whether that document was "hand-authored" or authored in some other way. So conformance-checking tools can never be expected to reliably detect whether a document was "hand-authored" or not.

==== Tool-mediated insertions of alternative text are ignored by the "generator exception" ====

A mistaken assumption that seems to be implicit in the current specification language regarding meta generator is that the authoring production process is binary: that a document is either generated in a completely automated fashion, or that it is completed authored by hand. That assumption does not match reality. The document production process often includes multiple steps. For instance, documents may be first generated using some kind of automated tool, or some conversion process from another format (for example, from a word-processing application such as Microsoft Word or OpenOffice, etc.); then they may be processed through intermediate stages to address layout, format, animations, etc.; then they may be validated, cleaned or repaired using various tools. Any of the tools in this production chain may add generator tags, and, once added, these tags are generally not stripped out by other tools.

At most of these stages, most types of authoring or processing tools allow tool-mediated adjusting of content. Some of these tools, such as Tidy (which adds a generator tag) allow hand-editing as well.

Steve Faulkner's [http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming#Majority_of_content_not_exclusively_WYSIWYG_.28New.29%3Chttp://www.w3.org/html/wg/wiki/ChangeProposal/meta_name=generator_does_not_make_missing_alt_conforming change proposal] provides data on a variety of tools which, as relevant evidence to establishing the range of production processes, allow tool-mediated editing of content. Some of the tools listed also allow hand-editing.

==== Implications of correcting the deficiencies in specification of the "generator" value ====

Following this new information through to its logical conclusion, the remaining arguments against removal of the "generator exception" should be consider void. Nevertheless, additional perspectives on these points are provided below for the record, given the multiple misunderstandings that they represent regarding accessibility-related user requirements and authoring practices.

=== The "generator exception" results in inequitable rendering of graphical content ===

In their April 2011 decision, the HTML Co-Chairs incorrectly asserted that arguments regarding structural integrity against the generator exception were circular and gave these no weight:
<blockquote>
Another objection was that the generator exemption breaks the structure of the img element:
<blockquote>
Requiring a set of programmatically determinable valid options helps ensure that images have complete structure. Complete structure of the <img> element requires both src and text alternatives.
</blockquote>
This claim seems to be based on a circular argument. Omitting alt should not be allowed, because that would make the img element have incomplete structure, because img requires alt. Thus, the objection fails to make its case and was given no weight.
</blockquote>

This argument is not circular. For web content to be independent of presentation, both the <code>src</code> attribute and the <code>alt</code> attribute are necessary for images.

* Omit the <code>src</code> attribute, and sighted users have no content;
* Omit text alternatives, and non-sighted users have no content.

For a sighted user, if there is no <code>src</code> element, then no content is rendered, and therefore it is a document error. For a blind user, if no content is rendered, then there is likewise a document error; without <code>alt</code> content, the <code>img</code> element is not representing anything to that user. It is inequitable for a document to represent something to a sighted user but not to a non-sighted user.

Without both a <code>src</code> attribute and a text alternative the <code>img</code> element is incomplete, as further discussed in [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#HTML5_Should_Require_Structural_Integrity_for_the__.3Cimg.3E_Element Laura Carlson's change proposal on conformance checking].

<strong>The argument against the "generator exception," regarding structural integrity of the <img> element, should have been evaluated as a strong objection rather than to have been given no weight.</strong>

=== The "generator exception" inadvertently and retroactively introduces new, undocumented, magic semantics ===

The effect of the generator exception is that it inadvertently assigns additional new semantics to meta generator -- magic semantics that are not clearly documented in the spec and not obvious to implementors and users of the spec. Specifically, the generator exception has the effect of making meta generator provide the new meaning, "I do not want conformance checkers to emit error messages about missing alternative text for any <code>img</code> elements in this document." And it unilaterally and retroactively assigns that additional meaning to all existing documents that contain meta generator, not just to newly created documents.

If I am implementing, for example, an HTML editing application based on the spec, it is not clear to me from reading the spec that having my editing application add a meta generator element means that for every single document any author creates with my application, conformance checkers are never going to emit error messages about missing alternative text for <code>img</code> elements.

And as a document author, from reading the spec, it is not at all clear to me from reading the spec that if I keep a meta generator element that has been added by any tool in the production or evaluation process, anywhere in any document, it means that I am choosing to completely opt out of having conformance checkers emit any error messages about missing alternative text for any <code>img</code> elements in the document. Among other things, the result is a significantly reduced ability for me to identify potential errors which I otherwise would have been alerted to; I lose an important capability due to meta generator having surprise magic semantics that are not clearly inferable from the spec.

Moreover, assigning this new "do not emit error messages about missing alternative text for any <code>img</code> elements in this documents" meaning to meta generator results in retroactively changing the processing behavior of an entire conformance class for all existing documents that have ever been created on the Web which contain meta generator instances. That is, prior to HTML5, the meaning of meta generator in those documents was simply that it was a stamp to indicate which applications were used to create the document. But now, an additional meaning that the original creators of those documents never intended is unilaterally and retroactively being assigned to those documents, with one of the consequences being that the documents will now be handled by conformance checkers in a way that is very different from that way in which they were handled previously. In that sense, it "breaks" existing content.

The meta generator exception is therefore actively harmful and should not be part of the specification.

=== The weighting of objections against the "generator exception" is deficient ===

In the HTML Co-Chairs' [http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html April 2011 compound decision on Issue 31 and 80], they asserted that individual objections to the "generator" exception, on the whole, drew weaker objections than would removing the exception:
<blockquote>
Overall, there were many claimed disadvantages that flow from the generator exception, ranging from weak to moderately weak. They were generally unsupported by details or concrete evidence. Even though the use case for omitting alt when the generator mechanism is used was disputed and only found to be a medium objection, it still outweighs these claimed disadvantages, as they were all found to be weak or moderately weak.

Thus, on the whole, the proposal to allow alt to be omitted when the generator mechanism is used was found to draw weaker objections, compared to the proposal to still require alt, even when the generator mechanism is used.
</blockquote>

Within the "generator" portion of the HTML Co-Chairs' April 2011 compound decision on issues pertaining to alternative text, the Co-Chairs used six different levels of "weights" in evaluating the objections gathered in the survey: <strong>"strong," "moderately strong," "medium," "moderately weak," "weak," and "zero."</strong> These were presented without any definitions. Further complicating the rating scheme, these levels were applied bidirectionally -- on the one hand, to objections to the generator exception, and on the other hand, to objections to removing the generator exception, thus totally twelve possible rankings for any argument, all without definition. The primary criteria suggested by the HTML Co-Chairs to explain the low weighting of objections to the generator exception was repeated assertions of insufficient evidence; yet inaccurate assertions regarding authoring production processes on which the generator exception was originally based were apparently accepted without evidence. No point values were declared for the different levels used in the decision, with the exception of "zero," making it impossible to verify the arithmetic implied in the summary conclusion.

The multiple problems described above in the rating scheme make it difficult for readers to follow, let alone to contest, its application to objections to the generator exception, nor to accept the uniformly low weighting that was assigned to these objections. Therefore it is difficult to accept the conclusion that maintained the generator exception as an appropriate reflection of the arguments presented. Relevant arguments from the April 2011 decision are re-examined below, along with the weighting of those arguments, although these do not represent all the arguments of concern from that decision.

=== The "generator exception" breaks harmonization with other standards and guidelines ===

In their decision, the Co-Chairs suggested that the disharmonization with standards and guidelines introduced by an HTML5 "generator" exception is a failure of other standards and guidelines to update, and therefore they weighted this objection to the generator exception low:
<blockquote>
Yet another objection was based on standards and guidelines:
<blockquote>
The generator mechanism breaks standards and guidelines requiring text equivalents on an individual element basis.
</blockquote>
Many specific standards and guidelines were listed. However, these
guidelines were generally created before the generator mechanism
exemption was invented, so it's not clear if the disagreement
indicates a problem, or just failure to update. Thus, this was taken
to be a weak objection.
</blockquote>

This disagreement indicates a problem that cannot be solved as the HTML Co-Chairs seem to suggest by updating numerous other standards and guidelines, but that must rather be solved by removing the "generator" exception in HTML5 that has introduced this disharmonization.

The problem introduced by the "generator" exception is major with regard to standards harmonization, in that accessibility standards require alternative text for images, but the "generator" exception makes this requirement meaningless on the large number of web pages that have a "generator" tag inserted. In exempting a large percentage of pages on the web from the requirement to provide alternative text for images, people with visual disabilities are not provided equitable access to web content--equitable access that could have readily been provided by following the provisions of these standards and guidelines.

The date that the guidelines and standards were created--whether before, during or after creation of the generator exemption--has no bearing on the validity of the user requirement for alt. User needs for alternative text as captured in provisions of web standards and guidelines do not somehow become irrelevant because of a standard that does not follow the provisions of existing standards and guidelines. The existence of people with visual disabilities and the need to accommodate them on the web have not disappeared in the intervening years.

This assertion also presumes that the other standards would now agree with the generator exception, though the opposite is a far more likely conclusion; the other standards are quite aware of automated authoring tools and simply do not agree that alt is unnecessary and expendable when a tool is involved. There is no evidence that these standards have not considered the implications of CMS; in fact some of these standards have indeed been recently updated, and none have abandoned their reliance on alt.

To suggest that the problem of standards breakage (standards fragmentation) introduced by the generator exception is a failure of standards and guidelines to update is to suggest that the reality of users' needs is shaped by a technical standard rather than vice versa. It shows a lack of understanding of or disregard for the requirements of users with disabilities and the role that standards and guidelines serve in accommodating those requirements.

<strong>The argument against the <meta name="generator"> exception, regarding failure to harmonize with standards and guidelines, should have been evaluated as a strong rather than a weak objection.</strong>

=== The "generator exception" inappropriately gives authoring tool conformance considerations precedence over end-user requirements ===

In their decision, the Co-Chairs asserted multiple rationales for retaining the generator exception based on the inconvenience that might otherwise result for authoring tool conformance:
<blockquote>
At least one Change Proposal argued that when a page is created by an automated content generation tool, and that tool indicates this using <meta name=generator>, it should be permitted to omit the alt attribute.

It was argued that there was a valid use case for the generator exemption, namely automated content generators which cannot produce alt themselves and for various reasons cannot or will not demand alt from the user. The following objection, though entered for role=presentation, directly argues one such use case:
<blockquote>
Consider a GUI authoring tool used by end-users, not professional Web developers or content authors. Such tools generate <img> elements, but it is not always appropriate for such tools to pause and demand alt text from the user before continuing.
</blockquote>
</blockquote>
Whether or not authoring tools prompt for alternative text at any given stage of document production process is immaterial to question at hand. Even authoring tools that fail to prompt for missing alternative text nevertheless may permit the introduction of alternative text for images, or else can be used with other production tools that do provide that capability; so content authors are not prevented from creating appropriate alternative text. And even the Authoring Tool Accessibility Guidelines (ATAG), which address support for production of accessible content, do not recommend intrusive prompting. But regardless, whether or not an author was prompted for alt does not change the fact that the end-user requires it, and that the generator exception will interfere with determining whether of not the resulting document contains it.
<blockquote>
Several objectors cited this use case, and further pointed out that if content generators are forced to generate nonconforming markup to satisfy this use case, they may instead enter bogus alt values, which would merely exacerbate the problem:
<blockquote>
If an authoring tool or other generator does not have sufficient information to include either alternative text or a caption, there is nothing the tool can do. If we say that in those cases the authoring tool would be non-conforming if it didn't provide alternative text or a caption, then the tool will just provide bogus (placebo) alt="" attribute values, which just makes the problem non-machine-detectable instead. To address this, therefore, we should allow generator tools to include images without alternative text or captions if absolutely necessary.
</blockquote>
Also:
<blockquote>
I object to treating the absence of the alt attribute as a validation error when the generator mechanism is used, because if it is treated as an error in that case, generator developers are incented to generate bogus values in order to make their products emit markup that doesn't trigger errors. (There are always generator developers who want to make the output of their programs validate.)
</blockquote>
The use case of GUI tools that do not prompt for alt seems well established.
</blockquote>

While there may indeed may be authors who intransigently choose to enter bogus alternative text, knowingly violating the intended use of alternative text as an accessibility accommodation, this is not a reason to codify their bad practices by removing validation alerts for missing alternative text for content authors who would prefer to do the right thing and provide alternative text for images.

The lines of reasoning included here imply that considerations of authoring tool conformance should take precedence over end-user requirements for accessible web content. Given that alternative text is essential to understanding graphical web content for some web users, the proposed justification for the omission of alternative text based on conformance convenience for authoring tools, and validation convenience for content authors, is an inadequate counter-consideration to the needs of end-users for accessible content.

After examining a variety of arguments regarding the convenience of the generator exception for assessing conformance of authoring tools, without consideration of the experience of the end-users who require alt as an accessibility accommodation for graphical web content, the HTML Co-Chairs asserted that:
<blockquote>
After considering all these arguments, it seems established that there is a valid use case for allowing the alt attribute to be omitted when the generator mechanism is specified. This use case makes for a moderately strong objection. However, the claim of negative consequences to disallowing this use case was somewhat weakened by the lack of concrete evidence that bogus values have been used in the past or would be used in the future. So overall, this makes for a medium objection.
</blockquote>

Given multiple problems with the arguments above, the omission of alternative text in the presence of one or more generator tags has by no means been established as a valid case. <strong>These objections to the removal of the generator exception should have been no weight, when juxtaposed with the end-user requirements to have alternative text for images.</strong>

=== The "generator exception" obviates the intent of the Validator ===

In their decision, the Co-Chairs asserted that because the "generator exception" did not assert benefits relative to the Validator, such benefits were immaterial to the decision:
<blockquote>
Another objection argues that the generator mechanism fails to have certain benefits:
<blockquote>
The generator mechanism does not improve user experience or the
chances of accessible content being produced. It does not help
authors catch mistakes. It does not help educate developers.
</blockquote>
No one disputed this argument; but conversely, no one argued that
generator has these benefits or should be allowed because of such
benefits. With no concrete argument as to why the generator exception
ought to have these benefits, this was taken to be a weak objection.
</blockquote>

The W3C Validator service provides these benefits without regard to whether the generator mechanism claims such benefits. As the W3C Validator documentation states, [http://validator.w3.org/about.html "Validating Web documents is an important step which can dramatically help improving and ensuring their quality..."]. It provides a teachable moment, to whit: [http://validator.w3.org/docs/why.html#learning "Validation helps teach good practices"]. Additional information is available at [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#HTML5_Should_Help_Facilitate_Accessibility_Awareness_and_Education HTML5 Should Help Facilitate Accessibility Awareness and Education.]

In the presence of the generator exception, the validator suppresses error identification, and is thereby stripped of its educative benefits. If content developers are not aware that a problem (missing alternative text) exists, they are not notified about it, nor do they have the opportunity to rectify specific instances of missing alternative text. They are therefore deprived of the opportunity to learn about the general issue, and deprived of the opportunity to improve their content in the future.

So while the survey comments specifically raised the question of generator benefits, by extension they also raise the important question of Validator benefits, and how not to inadvertently undermine them. <strong>The issue of validator benefit should have been evaluated as a strong objection to the generator exception, rather than a weak argument against the generator exception.</strong>

=== Sufficient evidence of harm to end-users is implicit in arguments supporting the generator exception ===

In their decision, the Co-Chairs mentioned survey comments that asserted harm from the omission of alt:
<blockquote>
Some argued that omitting alt and using the generator mechanism had harmful consequences:
<blockquote>
Hence, the generator mechanism should not have any bearing on the @alt requirements as the generator string/mechanism has no bearing on the attributes of the <img> or the context in which the img appears in. The negative effects of omission of an empty or non-empty @alt are in no way made up for by the presence of the generator mechanism.
</blockquote>
This statement in itself lacks specifics...
</blockquote>

Inexplicably this was taken as non-evident despite widespread understanding that alternative text is necessary to ensure accessibility of images on the web for people who cannot see. Additional information on this is available at [http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv.html Understanding Guideline 1.1 of WCAG 2.0] as needed. The negative effects of omission of an empty or non-empty alt are in no way made up for by the presence of the generator mechanism, because the generator mechanism does nothing to fulfill the function that alternative text would have. The generator mechanism does not provide a functional replacement for the information provided by alternative text; nor does it provide a replacement for the visual functions of sighted users. It simply provides an excuse for why the necessary but absent alternative text is not there.

The HTML Co-Chairs also asserted that lists of authoring tools inserting the generator tag had no evidentiary value, dismissing the notion that a significant amount of web content would use the generator exception:
<blockquote>
A list was provided of example <meta name=generator> values, and from this a conclusion was drawn that a tremendous amount of Web content would make use of the generator exemption. However, it's not clear where this list came from. It is not present in the spec, and does not seem to align with the spec's definition of a content generator. In particular, it includes many text editors which do not seem to qualify as automated markup generators. Was this list derived from the output of actual authoring tools? Was it found by looking at real Web content? In the absence of information about where this list came from, it was taken to have no evidentiary value.
</blockquote>

The generator exception does not differentiate between content generators and authoring tools that insert a generator string. Authors of all documents with a <meta name=generator> string would remain ignorant that their document had any missing text alternatives. The HTML Co-Chairs were mistaken to disqualify [http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#HTML5_Should_Not_Facilitate_the_Creation_of_Inaccessible_Content the original evidence]. It was derived from searching and from examining tools that automatically insert a meta generator string and their resulting content. Since this initial evidence was provided, a [http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming#current_usage_of_meta_name.3Dgenerator_.28New.29 copious amount of further evidence of widespread use has been provided].

Other generator studies seem to indicate further usage of <meta name=generator>.

*[http://www.html5accessibility.com/HTML5data/dump/generator.html Windows Grep Search Results] - Steve Faulkner
*[http://philip.html5.org/data/dreamweaver-generators.txt dreamweaver-generators.txt] - Philip
*[http://philip.html5.org/data/generators.txt generators.txt] - Philip
*[http://philip.html5.org/data/underline-generators.txt underline-generators.txt] - Philip
*[http://lists.w3.org/Archives/Public/public-html/2011Apr/0580.html Generator Tools] - Leif Halvard Silli.

The HTML Co-Chairs also dismissed objections that a document-level generator option would make it easy for authors to forget to provide alternative text for images:

<blockquote>
...but there were some concrete arguments supporting the case for negative consequences:
<blockquote>
The generator mechanism facilitates the creation of inaccessible content.
</blockquote>
No evidence was provided that more inaccessible content would be created if the generator exemption is allowed than otherwise. So this was taken to be a weak objection.
</blockquote>

And, in a related argument, they rated an objection to the generator exception as moderately weak on the basis that there should have been sufficient time already for expanded evidence of harm from missing alt -- though it is unclear which authoring tools and validators, if any have already built in a generator exception for alternative text, and no time to accumulate statistical evidence of this presumed expanded harm.

<blockquote>
Another objection was based on the possibility of authoring mistakes:
<blockquote>
The generator mechanism is actively harmful to accessibility. If the generator option is left at document level, it would be far too easy for authors to have the software automatically insert "generator" and then forget to provide any text alternatives for images.
</blockquote>
If supported by concrete evidence, this would have been a strong
objection. This seems like a plausible authoring mistake which would
have negative consequences. But it was weakened by lack of any
specific evidence that this problem has actually occurred in
practice. This provision has been in HTML WG Editor's Drafts and
Working Drafts since September 3, 2009:

[http://dev.w3.org/cvsweb/html5/spec/Overview.html?rev=1.2915 http://dev.w3.org/cvsweb/html5/spec/Overview.html?rev=1.2915]

This should be enough time to see at least anecdotal evidence of the
claimed problem. Even though normally lack of supporting evidence
would render an objection weak, in this case, there is a
plausible-sounding argument even in the absence of evidence, so the
objection based on authoring mistakes is overall taken as moderately
weak.
</blockquote>

It is incongruous to, on the one hand, argue that the generator mechanism is in sufficient use to merit an exception, while on the other hand dismissing objections to the generator exception by claiming that insufficient evidence was provided that the generator mechanism is in use.

It is likewise incongruous to claim that content authors would be bothered by validation failures in the event of missing alt, while on the other hand claiming insufficient evidence that the generator exception would undermine the creation of accessible content.

<strong>These objections regarding harm to end-users with disabilities should have been evaluated as strong, not weak, objections to the generator exception, as they speak to the core issue of unmet user requirements resulting from exempting pages containing "generator" from the requirement to provide alternative text.</strong>

== Details ==

=== Change [1], at [http://www.w3.org/TR/2012/WD-html5-20120329/the-meta-element.html#meta-generator 4.2.5.1] ===

Remove:

<blockquote cite"http://www.w3.org/TR/2012/WD-html5-20120329/the-meta-element.html#meta-generator">
The value must not be used on hand-authored pages.
</blockquote>

=== Change [2] at [http://www.w3.org/TR/2012/WD-html5-20120329/the-img-element.html#guidance-for-conformance-checkers 4.8.1.1.13]===

Remove:

<blockquote>
The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text - validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.)
</blockquote>

== Impact ==

=== Positive Effects ===

* Authors can more safely assume that when they use a conformance checker it will check the conformance of the document, rather than some arbitrary subset of requirements.
* The use of meta name=generator will not change in a way that is contrary to its current usage and effects.
* Authors will be made aware that they have not provided a text alternative giving them the opportunity to fix their error and produce a conforming document.
* Upholds the structural integrity of <img> element.
* Enables automatic validators to programmatically detect occurrences of the presence or absence of text alternatives. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=9218 Bug 9218].
* Facilitates accessibility awareness and education.
* Upholds the [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies HTML section 3.2. "Priority of Constituencies" Design Principle].

=== Negative Effects ===

* None

=== Conformance Class Changes ===

* The meta generator exception is removed from section 4.8.1.1.13 Guidance for conformance checkers. (Refer to Change [2] in the Details section of this document.)

=== Risks ===

# There are no risks in doing the changes.
# Risks to '''not doing the changes''' include:
##unmet user requirements, in that individuals who are blind will not have equitable access to web content;
##HTML5 conformance evaluation for <meta name="generator"> will assert false conditions on authoring tool production processes;
##The HTML5 spec will be ambiguous with regard to the hand-authoring test for alternative text in the presence of the "generator" tag.

ChangeProposals/DisallowARIAReferencesToHiddenElements

Bhawkesl — Wed, 25 Apr 2012 06:56:05 GMT

Bhawkesl:

ChangeProposals/CorrectHidden/

Lcarlson — Mon, 23 Apr 2012 18:17:43 GMT

Lcarlson: /* Plain String Text By Design */

=Accessibility API Mappings=

__NOTOC__
<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; width: 70%; font-size:0.9em;">
*The following is part of the [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden Correct the hidden Attribute Section to be in Accord with the ARIA Spec Change Proposal].
* Editor: Laura Carlson (Based on [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions John Foliot's proposal], [http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2 Cynthia Shelly's proposal])
* Date: April 23, 2012. (Last updated April 23, 2012)
</div>

When aria-labelledby and aria-describedby reference an element that '''IS NOT''' hidden, the following things happen:
# An Accessible Object is created in the Accessibiltiy API tree for both the referencing and the referenced elements.
# In APIs that support such relationships, a relationship is created with bi-directional pointers between the objects. This can be used by AT products to find the referenced element and navigate to it.
# A DOM relationship is created between the referencing and referenced elements. DOM-based AT products, or browsers themselves, can use this to build UI that allows users to navigate to the description.
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

When aria-labelledby and aria-describedby reference an element that '''IS''' hidden, the following things happen:
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

== Results Are: Plain String Text ==
Name calculation is what is at issue in this CP. It happens whether the referenced items are hidden or not. When the referenced items are hidden, then the relationships for navigation are not created. Again, this is already true for CSS display:none and visibility:hidden, and has been true in browser implementation for years.

The structure of the referenced element is flattened in name calculation because properties where it is placed are plain text strings. In MSAA, for example, each accessible object is a COM object with properties of type string for the name and description. For more information, see the MSDN documentation for [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.aspx IAccessible], the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accdescription.aspx AccDescription] property, and the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accname.aspx AccName] property.

=== Plain String Text By Design ===
These results are <em>by design</em> so that keyboard-only users do not lose their visible focus as they tab through hidden content.

ChangeProposals/CorrectHidden/UAIG

Lcarlson — Wed, 18 Apr 2012 15:56:12 GMT

Lcarlson: /* User Agent Implementation Guide (UAIG) */

=User Agent Implementation Guide (UAIG)=

__NOTOC__
<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; width: 70%; font-size:0.9em;">
*The following is part of the [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden Correct the hidden Attribute Section to be in Accord with the ARIA Spec Change Proposal].
* Editor: Laura Carlson (Based on [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions John Foliot's proposal], [http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2 Cynthia Shelly's proposal])
* Date: April 18, 2012. (Last updated April 23, 2012)
</div>

The WAI-ARIA 1.0 User Agent Implementation Guide (UAIG) says that hidden elements are not exposed via the accessibility API, and this may be the cause some confusion. The intention was to forbid hidden elements from being exposed as separate accessibility objects in the accessibility api object tree. This was not intended to forbid mapping text from hidden objects to properties of other objects in the accessibility api tree. It sounds as though a note clarifying this should be added to UAIG.

==Authors Provide Strings and Browsers Process Strings==

Section [http://www.w3.org/TR/wai-aria-implementation/#mapping_additional_nd_te 5.6.1.3. Text Alternative Computation] of UIAG states explicitly that authors can provide strings for the accessible name and description via aria references to hidden elements, and that browsers are to process them as strings for these fields.
<blockquote>1.Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby being used in the current computation. By default, users of assistive technologies won't receive the hidden information, but an author will be able to explicitly override that and include the hidden text alternative as part of the label string sent to the accessibility API.</blockquote>

UAIG Section '''5.5.1. State and Property Mapping Table''' describes the use of aria-describedby in name and description calculation, and makes no mention of special treatment based on hidden state.

{|
! rowspan="1" colspan="1" |
WAI-ARIA State or Property
! rowspan="1" colspan="1" |
MSAA UIA Express
! rowspan="1" colspan="1" | MSAA IAccessible2
! rowspan="1" colspan="1" |
UIA
! rowspan="1" colspan="1" |
ATK/AT-SPI
! rowspan="1" colspan="1" | Mac OS X
|-
| rowspan="1" colspan="1" |
[http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby <code>aria-describedby</code>]
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.

If the object is in the accessibility tree, expose pointer to the accessible object in <code>IA2_RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation].

Expose pointer to the accessible object in <code>DescribedBy</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose pointer to the accessible object in <code>RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>string AXDescription</code> (reserved for non-visible accessible name or calculated description)
|}

Correct Hidden Attribute Section v2

Cshelly — Tue, 17 Apr 2012 21:25:26 GMT

Mturvey: Fixed link

[[Category:ChangeProposal]]

= Correct the <code>hidden</code> Attribute Section =

__NOTOC__
<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; width: 70%; font-size:0.9em;">
*The following is a Change Proposal for [http://www.w3.org/html/wg/tracker/issues/204 HTML5 ISSUE-204 aria-hidden].
* Editor: Cynthia Shelly (Based on [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden Laura Carlson's proposal], [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions John Foliot's note], and [http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden Jonas Sicking, Matt Turvey, Edward O'Connor's proposal])
* Date: April 17, 2012. (Last updated April 24, 2012)
</div>

== Summary ==

Authors sometimes want to provide a label or description to users of Assistive Technology, and to do so without any visual encumbrance or default visual indicator. They can already do this with CSS <code>display:none</code> and <code>visibility:hidden</code>, and should be able to do the same with the simpler <code>@hidden</code> attribute. The ARIA spec allows <code>aria-describedby</code> and <code>aria-labelledby</code> to reference hidden elements, so this change will correct the [http://dev.w3.org/html5//spec-author-view/editing.html#the-hidden-attribute <code>hidden</code> attribute section]to bring it into conformance with the ARIA specification and ARIA functionality. In addition, this would make the behavior of <code>@hidden</code> consistent with the long-implemented behavior of CSS display:none and visibility:hidden with HTML <code><label></code> and <code>aria-labelledby</code>.
__TOC__

== Rationale ==
=== Use Cases ===

Web authors often wish to provide a description of a complex element only to screen reader users, while hiding the description from all other users. Being able to provide such a description without any forced visual encumbrance or default visual indicator is a frequently-cited accessibility requirement.

==== Example 1====
Consider the following markup:

<pre><pre role=img aria-describedby=foo >
)\._.,--....,'``. fL
/, _.. \ _\ ;`._ ,.
`._.-(,_..'--(,_..'`-.;.'
</pre>
<p id=foo hidden>An ASCII art rendition of a cat in prone position.</p></pre>

This example contains an ASCII art rendition of a cat inside a <code><pre></code> element. A description of the art is provided for AT users. By using <code>aria-describedby</code> to point at a <code>@hidden</code> element, the web page author avoids any forced visual encumbrance or default visual indicator.

==== Example 2 ====
<code>

<input aria-labelledby="foo" type=text><input type=image src="search.png" alt="Go!">
<div id="foo" hidden>Search</div>

</code>

In this example, a short plain-text string is used to label the text input, and that label is hidden from view. For visual users, the text box followed by a looking glass icon is a well-known visual pattern for a search function. The hidden label makes this clear to users who cannot see the text box or graphic.

==== Example 3 ====
<code>
<input aria-labelledby="foo" type="text" onmouseover="showFoo();" onmouseout="hideFoo();">
<input src="go.gif" type="image" alt="Go!">
<div id="foo" hidden><img src="decorative-image.gif" alt="">Search</div>

</code>

This example shows a variation of Example 2 where the label has a decorative image, and is shown to visual users onmouseover. Since the image gives no real information, it has null alt text. The hidden label is used to give the screen-reader user more information via the accessibility API, so that he does not need to navigate to the tooltip. The accessible name in the accessibility API tells him exactly what that text is for, where a popup tooltip would require more cognitive overhead. However, the popup tooltip, with it's pretty graphic, is shown to improve the experience of signted users who are exploring the input. Since the screen-reader user does not use a mouse, and does not trigger the mouseover, he gets an experience that works for him, and the sighted user gets one that works for her. (Caveat: This is not a great piece of UI design for exploring an input by a sighted user. It is offerred as a simple example of where one might want to flatten the text for some users.)

The <code>@hidden</code> attribute is a mechanism for hiding elements in HTML. Given this, authors are likely to use it to hide content. The WAI-ARIA specification allows <code>aria-describedby</code> to point at non-visible content, so it is reasonable for authors to expect such markup to function properly. Because authors rarely run their content through conformance checkers, authors are likely to point at <code>@hidden</code> content from <code>aria-describedby</code> whether or not we forbid them from doing so. Therefore it is incumbant to document what can, and what cannot be achieved through these techniques.

=== Feedback from Browser Implementers ===

Two people working for browser implementers have suggested that exposing hidden elements in the accessibility tree is feasible, and similar to the work already under way to expose hidden child elements of the <code><canvas></code> element:

<blockquote>I don't think Apple has a strong stance either way on using @aria-describedby to point to @hidden elements, but I believe we could reasonably expose full semantics of hidden content pointed to by aria-describedby, this is more or less the same as the work we'd have to do to expose <canvas> children as an accessible tree.</blockquote>

[http://lists.w3.org/Archives/Public/public-html/2012Feb/0060.html Maciej Stachowiak, Apple]

In addition, this is the behavior that is specified for <code>@aria-describedby</code> in the ARIA User Agent Accessibility Guidelines (see below), and it is currently implemented in Safari.

<blockquote>In firefox, the reason that @hidden elements are "stringified" when
exposed through aria-describedby is because they don't have CSS boxes.
This is also why we have problems currently when exposing the contents
of a <canvas>. In both cases the accessibility code "fails" because it
tries to use the CSS boxes which aren't there. Hence the fallback to
stringify.</blockquote>

<blockquote>Exposing the rich semantics of contents inside a <canvas> in Firefox
will take a lot more than changing what object <canvas> inherits from.
Whatever solution we come up with for that can hopefully be reused to
expose the rich contents of @hidden elements exposed through
aria-describedby.</blockquote>

<blockquote>We now have two implementations which say that exposing the rich
contents of @hidden elements pointed to using aria-describedby is
implementable. And is implementable without changes from AT vendors.</blockquote>

[http://lists.w3.org/Archives/Public/public-html/2012Feb/0085.html Jonas Sicking, Mozilla]

There are similar constructs in Internet Explorer. For example, an aria-labelledby that references an element with CSS visibility:hidden or display:none will populate the accessible name for that element in IE9. Similarly, the accessible name of an input element will be populated with the text of it's associated label element, even if that label element is hidden with CSS visibility:hidden or display:none. This has been true in IE since IE 5 or 6. Having <code>@hidden</code> behave differently sets up a confusing situation for developers of both web applications and assistive technologies.

=== Compatibility and interoperability with ARIA 1.0 ===

As [http://lists.w3.org/Archives/Public/public-html/2012Apr/0046.html Richard Schwerdtfeger succinctly stated on April 9, 2012],

<blockquote>
The HTML 5 reference to aria-describedby is inaccurate as hidden text is
loaded into the accessible description string in an accessible object even though no accessible object representing the text description is exposed in the accessibility API.
</blockquote>

Because of how APIs work, any hidden content referenced by an ARIA attribute is rendered as a plain-text string. The [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions ARIA Can Only Refer To Hidden Content With Specific Restrictions change proposal] explains this in detail:

<blockquote>
The issue of whether or not hidden content could be referenced by ARIA attributes has actually been discussed by the ARIA Working Group, as recently as [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html March 2012].

The outcome of the ARIA WG's latest discussions has resulted in changes to the [http://www.w3.org/WAI/PF/aria-implementation Draft ARIA Implementation Guide] which speaks specifically to this Issue:

<blockquote>
<strong>[http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements 5.1.2. Excluding Elements from the Accessibility Tree]</strong>
<p>The following elements are not exposed via the accessibility API and user agents <strong class="rfc2119">MUST NOT</strong> include them in the accessibility tree</p>

* Elements with <code>role="[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]"</code> according to the rules for <code>[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]</code> role defined in <cite>[http://www.w3.org/WAI/PF/aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0]</cite>.

* <strong>Elements, including their descendents, that have host language semantics specifying that the element is hidden, such as CSS <code>display:none</code> or <code>visibility:hidden</code> or HTML 5 <code>hidden</code> attribute. </strong>
</blockquote>
The net effect of this is that any hidden content referenced by an ARIA attribute will be left to <strong>render as string text only</strong>, as it is forbidden by ARIA Processing rules, as well as the various Accessibility APIs (AAPIs), to take on any other role...

For this reason, any text that is hidden but referenced by an ARIA attribute will have limited, but not zero, value to screen reader users with AAPI aware tools.

So, to the question of "Should HTML5 permit ARIA attributes to reference (point to) content that is hidden from the visual view-port of sighted users?" the answer is, <u>it already can</u>.
</blockquote>

UAIG says that hidden elements are not exposed via the accessibility API, and this may be the cause of confusion. The intention was to forbid hidden elements from being exposed *as separate accessibility objects in the accessibility api object tree*. This was not intended to forbid mapping text from hidden objects to properties of other objects in the accessibility api tree. We will add an issue to UIAG to add a note to this effect.

However, section '''5.6.1.3. Text Alternative Computation''' of UIAG states explicitly that authors can provide plain-text strings for the accessible name and description via aria references to hidden elements, and that browsers are to process them as plain-text strings for these fields.
<blockquote>1.Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby being used in the current computation. By default, users of assistive technologies won't receive the hidden information, but an author will be able to explicitly override that and include the hidden text alternative as part of the label string sent to the accessibility API.</blockquote>

In addtion, UAIG Section '''5.5.1. State and Property Mapping Table''' describes the use of aria-describedby and aria-labelledby in name and description calculation, and makes no mention of special treatment based on hidden state.

{|
! rowspan="1" colspan="1" |
WAI-ARIA State or Property
! rowspan="1" colspan="1" |
MSAA UIA Express
! rowspan="1" colspan="1" | MSAA IAccessible2
! rowspan="1" colspan="1" |
UIA
! rowspan="1" colspan="1" |
ATK/AT-SPI
! rowspan="1" colspan="1" | Mac OS X
|-
| rowspan="1" colspan="1" |
[http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby <code>aria-describedby</code>]
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [#mapping_additional_nd Name Computation]. Expose in <code>accDescription</code> property.

If the object is in the accessibility tree, expose pointer to the accessible object in <code>IA2_RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation].

Expose pointer to the accessible object in <code>DescribedBy</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose pointer to the accessible object in <code>RELATION_DESCRIBED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible Description as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>string AXDescription</code> (reserved for non-visible accessible name or calculated description)
|-
| rowspan="1" colspan="1" |
[http://www.w3.org/WAI/PF/aria/states_and_properties#aria-labelledby <code>aria-labelledby</code>]
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>accName</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>accName</code> property.

Expose a reference to the accessible object in <code>IA2_RELATION_LABELLED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation]. Expose in <code>Name</code> property.

Expose a reference to the accessible object in the <code>LabeledBy</code> property.
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Computation].

Expose a reference to the accessible object in <code>RELATION_LABELLED_BY</code>

Expose reverse relations as described in [#mapping_additional_relations Relations].
| rowspan="1" colspan="1" |
Use in calculating the accessible name as described in [#mapping_additional_nd Name Computation]. Expose in <code>string AXTitle</code> (reserved for visible name)
|}

====Accessibility API mappings====
When aria-labelledby and aria-describedby reference an element that '''IS NOT''' hidden, the following things happen:
# An Accessible Object is created in the Accessibility API tree for both the referencing and the referenced elements.
# In APIs that support such relationships, a relationship is created with bi-directional pointers between the objects. This can be used by AT products to find the referenced element and navigate to it.
# A DOM relationship is created between the referencing and referenced elements. DOM-based AT products, or browsers themselves, can use this to build UI that allows users to navigate to the description.
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

When aria-labelledby and aria-describedby reference an element that '''IS''' hidden, the following things happen:
# The text of the referenced element is used in [http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd Name Calculation]
# the AriaProperties or ObjectAttributes are populated with the string aria-describedby=IDREF or aria-labelledby=IDREF, where IDREF is the ID of the referenced element.

Name calculation is what is at issue in this CP. It happens whether the referenced items are hidden or not. When the referenced items are hidden, then the relationships for navigation are not created. Again, this is ALREADY TRUE for CSS display:none and visibility:hidden, and has been true in browser implementation for years.

The structure of the referenced element is flattened in name calculation because properties where it is placed are of type string. In MSAA, for example, each accessible object is a COM object with properties of type string for the name and description. For more information, see the MSDN documentation for [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.aspx IAccessible], the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accdescription.aspx AccDescription] property, and the [http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.accname.aspx AccName] property.

== Details ==
===Remove===

<p>The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.</p>

<p>Elements that are not hidden should not link to or refer to elements that are hidden.</p>

<p>For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. If the content is not applicable or relevant, then there is no reason to link to it.</p>

<p>It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.</p>

===Add===

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive. User agents should not render elements that have the hidden attribute specified. User agents should not create accessible objects in the platform accessibility API tree for elements that have the hidden attribute specified. User agents should use the text-children of the hidden element to create a plain-text string, and use that string to fill in name and description properties in the objects created for the referring element, which does not have the hidden attribute specified. Note that it is not possible to store complex markup structures in these API properties, which are typed for plain-text strings. See the [http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html HTML to Platform Accessibility APIs Implementation Guide] for more details.

Elements that are not themselves hidden must not hyperlink to elements that are hidden. Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements.

For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate.

However, hidden elements may be used to provide descriptive plain text if such flattened content provides a good user experience by using aria-describedby and aria-labelledby and HTML labelling elements such as <label>, <legend>, <caption>, and <figcaption>.
This technique should not be used for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), as accessible name and description calculation [WAI-ARIA] will flatten the referenced elements to plain text, losing interactivity and semantic structure.

<p class="note"\>Note hidden labels and descriptions will not be exposed as objects in the accessibility tree, but may be used as part of accessible name and description calculation [WAI-ARIA]. Note the calculation will flatten the labelling and describing elements to plain text strings, losing interactivity and semantic structure. Authors must only use hidden labels and descriptions to label and describe elements when the calculated plain text strings are appropriate accessible names or descriptions.

For example the following would conform to this particular requirement because although <label> includes a sub-element, it still flattens to an appropriate accessible name for the <input>.</p>

<code>
<input id=f type=checkbox checked>
<label hidden for=f>
I do <strong>not</strong> want to receive marketing materials.
</label>
</code>

<p><p class="note">Additionally at the time of this writing, some screen reader products will read both the accessible name and accessible description, so authors should take care with the length of text provided via this method.</p></p>

===Remove===

It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

== Impact ==

=== Positive Effects ===
* Makes the behavior of references from aria-describedby to elements with the @hidden attribute consistent with long-implemented browser behavior for references to content hidden with CSS display:none and visibility:hidden using <label> and aria-labelledby. This is a good example of documenting the web as it is.
* Provides a simple, consistent way for UAs to hide content from sighted users while exposing it to AT via the accessibiltiy API.
* Allows authors to provide in-place information to AT users in scenarios where doing so provides the best user experience.
* Has no impact on scenarios where navigating to another location for additional information provides the best user experience.
* Provides an intuitive way for authors to hide content from sighted users. If you want your description to not be visible, put a hidden attribute on it, just like other contents that you don't want to be visible by default.
* Corrects the HTML5 specification with what in reality, ARIA actually says and does.
* Authors are told to not use a technique that does not work, e.g., hidden cannot support HTML-rich, structured content such as headings, paragraphs, list markup, table markup, anchor text, or inline content (such as <span>).

=== Negative Effects ===

* See Risks.

=== Conformance Classes Changes ===

* No change.

=== Risks ===

* Some authors will misunderstand the limitations of what can be achieved using ARIA, and will point aria-describedby to hidden structured text. Browsers will flatten that structure to a string and populate the accessible name and description fields in the accessibiltiy API, which can cause a poor user experience for screen reader users. There have not been many reports of problems with this the exisiting <label> and aria-labelledby functionality with CSS display:none and visibility:hidden, but since descriptions are often longer, it may be more of a problem with descriptions.

== References ==

* [http://www.w3.org/TR/wai-aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0] (W3C Candidate Recommendation)
* [http://www.w3.org/WAI/PF/aria-implementation WAI-ARIA 1.0 User Agent Implementation Guide] (W3C Editor's Draft)
* [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html Action-970 (PF) Publish F2F Minutes Extract RE ARIA-Describedby]

ChangeProposals/CorrectHidden

Lcarlson — Wed, 11 Apr 2012 20:05:40 GMT

Lcarlson: /* Correct the hidden Attribute Section to be in Accord with the ARIA Spec */

[[Category:ChangeProposal]]

= Correct the <code>hidden</code> Attribute Section to be in Accord with the ARIA Spec =

__NOTOC__
<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; width: 70%; font-size:0.9em;">
This is a '''Note''' submitted against [http://www.w3.org/html/wg/tracker/issues/204 Issue 204]. It was last edited on May 1, 2012. Although the author still worries that possessing special ARIA language (instead of simply reinforcing the simple concept that "hidden always means hidden" as the HTML5 spec currently does) adds complexity to the spec and will cause some authors, especially novice authors, confusion, she has chosen to '''withdraw''' it in
deference to [http://www.w3.org/html/wg/wiki/index.php?title=Correct_Hidden_Attribute_Section_v2&oldid=12821 Cynthia's stabilized proposal (id=12821)] as long as that proposal makes no further changes and remains stable, as it seems to bring HTML5 and ARIA in accord on this issue and illuminates normatively the fact that accessible name and description calculation (WAI-ARIA) flattens the referenced elements to plain text, losing interactivity and semantic structure.
</div>

== Summary ==

Correct the [http://dev.w3.org/html5//spec-author-view/editing.html#the-hidden-attribute <code>hidden</code> attribute section] so it is in accord with the ARIA specification and ARIA functionality.
__TOC__

== Rationale ==

As [http://lists.w3.org/Archives/Public/public-html/2012Apr/0046.html Richard Schwerdtfeger succinctly stated on April 9, 2012]:

<blockquote>
The HTML 5 reference to aria-describedby is inaccurate as hidden text is
loaded into the accessible description string in an accessible object even though no accessible object representing the text description is exposed in the accessibility API.
</blockquote>

Because of how APIs need to work, any hidden content referenced by an ARIA attribute is rendered as string text. The [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions ARIA Can Only Refer To Hidden Content With Specific Restrictions change proposal] explains this in detail:

<blockquote>
The issue of whether or not hidden content could be referenced by ARIA attributes has actually been discussed by the ARIA Working Group, as recently as [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html March 2012].

The outcome of the ARIA WG's latest discussions has resulted in changes to the [http://www.w3.org/WAI/PF/aria-implementation Draft ARIA Implementation Guide] which speaks specifically to this Issue:

<blockquote>
<strong>[http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements 5.1.2. Excluding Elements from the Accessibility Tree]</strong>
<p>The following elements are not exposed via the accessibility API and user agents <strong class="rfc2119">MUST NOT</strong> include them in the accessibility tree</p>

* Elements with <code>role="[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]"</code> according to the rules for <code>[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]</code> role defined in <cite>[http://www.w3.org/WAI/PF/aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0]</cite>.

* <strong>Elements, including their descendents, that have host language semantics specifying that the element is hidden, such as CSS <code>display:none</code> or <code>visibility:hidden</code> or HTML 5 <code>hidden</code> attribute. </strong>
</blockquote>
The net effect of this is that any hidden content referenced by an ARIA attribute will be left to <strong>render as string text only</strong>, as it is forbidden by ARIA Processing rules...

For this reason, any text that is hidden but referenced by an ARIA attribute will have limited, but not zero, value to screen reader users with AAPI aware tools.

So, to the question of "Should HTML5 permit ARIA attributes to reference (point to) content that is hidden from the visual view-port of sighted users?" the answer is, <u>it already can</u>.
</blockquote>

<span id="UAIG">The ARIA implementation guide requires aria-describedby populate a string description field (accDescription) and this is in fact implemented.</span> [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden/UAIG As explained UIAG states explicitly that authors can provide strings for the accessible name and description via aria references to hidden elements, and that browsers are to process them as strings].

The fact remains that structure will be flattened to a string text. The [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden/ Accessibility API mappings document] explains how this is accomplished and how it results in plain string text.

Again the [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Can_Only_Refer_To_Hidden_Content_With_Specific_Restrictions John Foilot's change proposal] illuminates this main point:

<blockquote>
what the Candidate Recommendation ARIA Specification and Draft Implementation Guide expressly forbids, is preserve any structured semantic content in a hidden element.
</blockquote>

All structured semantic content in a hidden element is lost. This will lead to a very poor user experience in longer content, as reading keys will not work. Users will not be able to interact with the content. All links will be dead.

== Details ==
===Remove===

<blockquote>
<p>The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.</p>

<p>Elements that are not hidden should not link to or refer to elements that are hidden.</p>

<p>For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. If the content is not applicable or relevant, then there is no reason to link to it.</p>

<p>It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.</p>
</blockquote>

===Add===

<blockquote>
<p>All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive. User agents should not render elements that have the hidden attribute specified.</p>

<p>Elements that are not themselves hidden must not hyperlink to elements that are hidden. Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements.</p>

<p>For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate.</p>

However, hidden elements may be used to provide descriptive plain string text, using aria-describedby and aria-labelledby and the <label> element. <span id="warning">This technique should not be used for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), as accessible name and description calculation [WAI-ARIA] will flatten the referenced elements to plain text, losing interactivity and semantic structure.</span>

<p class="note">Additionally at the time of this writing, some screen reader products will read both the accessible name and accessible description, so authors should take care with the length of text provided via this method.</p>

</blockquote>

===Remove===

<blockquote>
It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.
</blockquote>

== Impact ==

=== Positive Effects ===

* Corrects the HTML5 specification with what in reality, ARIA actually says and needs to do.
* Some skilled developers who use ARIA will be provided a limited technique. They can hide small snippets of text from visual rendering, and still reference it via aria-describedby and aria-labeledby.
* Authors are told to not use a technique that does not work, e.g., hidden cannot support HTML-rich, structured content such as headings, paragraphs, list markup, table markup, anchor text, or inline content (such as <span>).

=== Negative Effects ===

* See Risks.

=== Conformance Classes Changes ===

* No change.

=== Risks ===

* Some authors will misunderstand the limitations of what can be achieved using ARIA, and will point aria-describedby to hidden structured text. Structure will be flattened to a string text and that string will populate the accessible description field in the accessibility API. <strong>This will lead to a very poor user experience</strong> in longer content, as reading keys will not work. Users will not be able to interact with the content. All links will be dead.
* Possessing this special ARIA clause (instead of simply reinforcing the concept that "hidden always means hidden" as the spec currently does) adds complexity to the spec and will cause some authors, especially novice authors, confusion.

== Sub-Pages for this Proposal ==

* [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden/UAIG User Agent Implementation Guide (UAIG)]
* [http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden/ Accessibility API Mappings]

== References ==

* [http://www.w3.org/TR/wai-aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0] (W3C Candidate Recommendation)
* [http://www.w3.org/WAI/PF/aria-implementation WAI-ARIA 1.0 User Agent Implementation Guide] (W3C Editor's Draft)
* [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html Action-970 (PF) Publish F2F Minutes Extract RE ARIA-Describedby]

ISSUE-194

Eoconnor — Wed, 04 Apr 2012 22:16:37 GMT

Eoconnor:

= ISSUE-194 full-transcript =

Some background [[/Research|research]].

== Active Change Proposals ==

* [[/NoChange|Defer ISSUE-194 until HTML.next]]
* [[User:Eoconnor/ISSUE-194-2B|Mint a transcript attribute for the programmatic association of transcripts with media elements]]
* [[ChangeProposal/ISSUE-194/TranscriptURL|Introduction of a @transcript=URL attribute]]

May2012Agenda

Plehegar — Tue, 03 Apr 2012 18:21:39 GMT

Plehegar:

<div class="h-event vevent">
This is the Meeting Page including Agenda for the <span class="p-summary summary">HTML WG f2f meeting</span> in
<span class="p-location location h-adr adr">
<span class="p-locality locality">Mountain View</span>
<span class="p-region region">CA</span>
<span class="p-country-name country-name">US</span>
</span>
on
<span class="dt-start dtstart"><span class="value-title" title="2012-05-03">Thursday May 3</span></span>
and
<span class="dt-end dtend"><span class="value-title" title="2012-05-04">Friday May 4 2012</span></span>.
</div>

== Specifications, Documents and References ==

* see [http://www.w3.org/html/wg/ Group homepage]

== Potential Topics ==

* <time> vs. <data> OR - when and how we add specific semantic elements to HTML in the presence of a catchall (e.g. <mark> vs. <span> etc.) - [[User:Tantekelik|Tantek Çelik]]
** see related [http://www.w3.org/html/wg/tracker/issues/183 Issue 183].
** see also related [http://krijnhoetmer.nl/irc-logs/html-wg/20120412#l-544 2012-103 discussion on #htmlwg]
* Media extension specification proposals - discussion of goals and how the specs work
** [http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html Media Source Extensions]
** [http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Encrypted Media Extensions]
* Next HTML WG charter: scope and new deliverables
** Media extension proposals
*** (see above for the two proposals)
*** The [http://www.whatwg.org/specs/web-apps/current-work/#http+aes-scheme http+aes] and [http://www.whatwg.org/specs/web-apps/current-work/#https+aes-scheme https+aes] schemes
** [http://www.w3.org/html/wg/next/markup/ Proposed HTML elements and attributes]
*** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/035301.html register*Handler and Web Intents]
** [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035239.html Canvas 2D additions]
** [https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=HTML.next HTML.next bugs]
** [http://www.w3.org/wiki/HTML/next HTML.next wiki]
** [http://www.whatwg.org/specs/web-apps/current-work/#dom-document-csselementmap cssElementMap]
** Text Search APIs? (e.g. window.find())
** DOM Parsing and Serialization
* HTML Test Suite coverage and status

[add your agenda topic request here]

== Agenda May 3 ==

* 09:00 - 09:45 Tweak agenda à la an [http://en.wikipedia.org/wiki/Unconference unconference style meeting]
* 09:45 - 10:30 Stabilization
** Stabilization plan, FAQ, Timeline status, decision policy bugs, Community Group, WG procedures
* 10:45 - 12:00 [http://www.w3.org/html/wg/tracker/issues/199 Issue 199: ARIA Processing; ...]
* 12:00 - 13:00 Lunch
* 13:00 - 15:00 Canvas Path and Hit Testing Change Proposals
** [http://www.w3.org/html/wg/tracker/issues/201 Issue 201]
*** Change proposals: [http://www.w3.org/wiki/Canvas_hit_testing Canvas hit testing], [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-201 Provide for canvas location and hit testing capability with an exposed Path object and related alterations to the 2d Context API]
* 15:15 - 17:00 Issue 194
** time, data, [http://www.w3.org/html/wg/tracker/issues/183 183], [http://www.w3.org/html/wg/tracker/issues/184 184]

== Agenda May 4 ==

* 09:00 - 10:30 Media Extensions
* 10:45 - 12:00 Charter
* 12:00 - 13:00 Lunch
* 13:00 - 15:00 Open issues, testing
* 15:00 - 17:00 Open issues, testing

== Minutes ==

* [http://www.w3.org/2012/05/03-html-wg-minutes.html May 3]
* [http://www.w3.org/2012/05/04-html-wg-minutes.html May 4]

2012-05-f2f

Tantekelik — Thu, 22 Mar 2012 22:42:50 GMT

Tantekelik: added link to agenda

= 2012-05 f2f at Microsoft SVC in Mountain View, CA, USA =

The [http://www.w3.org/html/wg/ HTML Working Group] May 2012 meeting ...

== Agenda ==
See the [[May2012Agenda]]

== Minutes and Notes ==
* ...

== Schedule ==

=== 2012-05-03 ===
...

=== 2012-05-04 ===
...

__NOTOC__

== see also ==
* [[f2f]]
* [[Main_Page|HTML WG wiki]]

F2f

Tantekelik — Thu, 22 Mar 2012 22:31:50 GMT

Tantekelik: 2012-05

{{stub}}

* ...
* [[2007-11-f2f]]
* ...
* [[2012-05-f2f]]
* ...

ChangeProposals/LinkLongdescToImgRole

Lsilli — Tue, 20 Mar 2012 02:44:27 GMT

Lsilli: /* Rationale */

ChangeProposals/DoNotAllowAriaReferHidden

Jfoliot — Tue, 13 Mar 2012 23:19:03 GMT

Jfoliot: moved ChangeProposals/ARIA Can Only Refer To Hidden Content With Specific Restrictions to Jfoliot/ARIA Can Only Refer To Hidden Content With Specific Restrictions: Withdrawal of Change Proposal

= ARIA Can Only Refer To Hidden Content With Specific Restrictions =

<div id="boilerplate" style="border-left:3px solid #00CC77; padding: 0.5em 1em 0.5em 1em; background-color:#CCFFCC; color:#000; margin:auto; width: 70%; font-size:0.9em;">
<ul>
<li>Author: John Foliot</li>
<li>This is a '''Note''' submitted against [http://www.w3.org/html/wg/tracker/issues/204 Issue 204]. It has been edited on April 19 to remove some content, and converted from a Change Proposal to a Note, as the author has chosen to withdraw this Change Proposal against Issue 204. However, since more current Change Proposals directly reference this document, it is being preserved to support those links.</li></ul></div>

== Summary ==
There is some serious and significant misunderstanding around the entire Issue 204, which is described as:
<blockquote>
<h2>ISSUE-204: Exempt ARIA attributes from the rule that prohibits reference to hidden elements</h2>
<h3>aria-hidden</h3>
<h3>Exempt ARIA attributes from the rule that prohibits reference to hidden elements</h3>
</blockquote>

== Details ==

The issue of whether or not hidden content could be referenced by ARIA attributes has actually been discussed by the ARIA Working Group, as recently as [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html March 2012].

The outcome of the ARIA WG's latest discussions has resulted in changes to the [http://www.w3.org/WAI/PF/aria-implementation Draft ARIA Implementation Guide] which speaks specifically to this Issue:

<blockquote>
<h4>[http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements 5.1.2. Excluding Elements from the Accessibility Tree]</h4>
<p>The following elements are not exposed via the accessibility API and user agents <strong class="rfc2119">MUST NOT</strong> include them in the accessibility tree</p>

* Elements with <code>role="[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]"</code> according to the rules for <code>[http://www.w3.org/WAI/PF/aria/roles#presentation presentation]</code> role defined in <cite>[http://www.w3.org/WAI/PF/aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0]</cite>.

* <strong>Elements, including their descendents, that have host language semantics specifying that the element is hidden, such as CSS <code>display:none</code> or <code>visibility:hidden</code> or HTML 5 <code>hidden</code> attribute. </strong>

</blockquote>

The net effect of this is that any hidden content referenced by an ARIA attribute will be left to <strong>render as string text only</strong>, as it is forbidden by ARIA Processing rules, as well as the various Accessibility APIs (AAPIs), to take on any other role. This is in fact consistent with how browsers are implementing this today.

For this reason, any text that is hidden but referenced by an ARIA attribute will have limited, but not zero, value to screen reader users with AAPI aware tools.

So, to the question of "Should HTML5 permit ARIA attributes to reference (point to) content that is hidden from the visual view-port of sighted users?" the answer is, <u>it already can</u>.

<strong>What HTML5 cannot do, what the Accessibility APIs cannot do, and what the Candidate Recommendation ARIA Specification and Draft Implementation Guide expressly forbids, is preserve any structured semantic content in a hidden element.</strong>

Even if the HTML5 Specification sought a <i>willful violation</i> of the ARIA Candidate Recommendation, neither the browsers nor the spec can affect the way that the Accessibility APIs (which are system level APIs) can process the content - not only is it out of scope, it is quite literally out of reach.

== Impact ==

=== Positive Effects ===

* ARIA shows itself to be scalable to a certain extent
* Authors can hide small snippets of text from visual rendering, and still reference it via aria attributes

=== Negative Effects ===

* Any content, when hidden using any of the methods of (<code>aria-hidden</code>, <code>@hidden</code> or CSS <code>display:none</code> or <code>visibility:hidden</code>), cannot support HTML-rich, structured content such as Headings, Paragraphs, List markup, Table markup, Anchor Text, or inline content (such as <span>, which could be used to support internationalization requirements: <span lang="it">peccato</span>)

=== Conformance Classes Changes ===

None.

=== Risks ===

Without good author guidance, some authors will misunderstand the limitations of what can be achieved using ARIA. We already have [http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc evidence of that today].

== References ==

* [http://www.w3.org/TR/wai-aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0] (W3C Candidate Recommendation)
* [http://www.w3.org/WAI/PF/aria-implementation WAI-ARIA 1.0 User Agent Implementation Guide] (W3C Editor's Draft)
* [http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0012.html Action-970 (PF) Publish F2F Minutes Extract RE ARIA-Describedby]

__NOTOC__

ChangeProposal/Issue203

Jfoliot — Thu, 01 Mar 2012 08:58:02 GMT

Jfoliot: /* Rationale */

= Change Proposal =

All Media Elements should have the ability to have both short and longer textual descriptions associated to the element.

== Summary ==
This Change Proposal seeks to actually make 2 changes to the current specification:

* CP 203a - Allow media elements (<video> <audio>) to take the @alt attribute (short textual description)
* CP 203b - Allow media elements (<video> <audio>) to take the @longdesc attribute (long textual description)

Related to:

* https://www.w3.org/Bugs/Public/show_bug.cgi?id=12228
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=12794

__TOC__

== Rationale ==

WCAG 2 requires that authors [http://www.w3.org/TR/WCAG/#text-equiv "Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language."]

Currently, the draft HTML5 specification does not provide a native, programmatic means of associating both short and long textual descriptions to these assets, while still respecting the design need/requirement for not having those (redundant) textual descriptions on screen. Suggestions of placing that text inside of the <video> (or <audio>) element(s) does not suffice, as the specification clearly states:

"Note: In particular, this content is not intended to address accessibility concerns.
To make video content accessible to the blind, deaf, and those with other physical or
cognitive disabilities, authors are expected to provide alternative media streams and/or
to embed accessibility aids (such as caption or subtitle tracks, audio description tracks,
or sign-language overlays) into their media streams."
Source: http://www.w3.org/TR/html5/video.html#video

Proposal 203a - For providing the short textual description today, the current native mechanism for achieving this functionality, used on images, is the @alt attribute. The current spec states: "...the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled." [http://www.w3.org/TR/2011/WD-html5-20110525/embedded-content-1.html#attr-img-alt] It is a seemingly obvious and rational choice to extend this attribute to the video and audio elements, which, while not images, meet the larger WCAG definition of non-text content.

Proposal 203b - For providing a longer textual description on images, the native HTML mechanism today for achieving this is the @longdesc attribute. HTML4 defines @longdesc as: "This attribute specifies a link to a long description of the image. This description should supplement the short description provided using the alt attribute." [http://www.w3.org/TR/html401/struct/objects.html#adef-longdesc-IMG] If it is accepted that the @alt attribute can provide the short textual description on the media element in the same fashion that it currently does for the image element, then by extension it would be reasonable that those same media elements can reuse the same longer textual description mechanism for images: @longdesc

The following code example illustrates how these attributes could be applied to a simple video example:

<code>
<pre>
<video controls
alt="My Vacation Movie"
longdesc="path to longer textual description which relates to the Media asset">
<source src="vacation_movie.mp4" type="video/mp4">
<source src="vacation_movie.webm" type="video/webm">
<track src="vacation_captions_file.vtt" label="English captions" kind="captions">
</video>
</pre>
</code>

'''NOTE: This Change Proposal has a dependency on the resolution of [http://www.w3.org/html/wg/tracker/issues/30 Issue 30]'''

== Details ==

* Change to [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-video-element 4.8.6 The video element]
Content attributes:
NEW: add the following attributes: '''@alt, @longdesc'''

* Change to [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-audio-element 4.8.7 The audio element]
Content attributes:
NEW: add the following attributes: '''@alt, @longdesc'''

* Change to [http://www.w3.org/TR/2011/WD-html5-20110525/embedded-content-1.html#attr-img-alt 4.8.1 The img element]

Replace this:
<blockquote>
<p>"The image given by the src attribute is the embedded content; the value of the alt
attribute provides equivalent content for those who cannot process images or who have
image loading disabled.</p>

<p>The src attribute must be present, and must contain a valid
non-empty URL potentially surrounded by spaces referencing a non-interactive,
optionally animated, image resource that is neither paged nor scripted.</p>

<p>{class=note}Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs), single-page vector
documents (single-page PDFs, XML files with an SVG root element), animated bitmaps (APNGs,
animated GIFs), animated vector graphics (XML files with an SVG root element that use
declarative SMIL animation), and so forth. However, this also precludes SVG files with
script, multipage PDF files, interactive MNG files, HTML documents, plain text documents,
and so forth."</p></blockquote>

With this:

<blockquote>
<p>"The image given by the src attribute is the embedded content. The src attribute must be
present, and must contain a valid non-empty URL potentially surrounded by spaces referencing
a non-interactive, optionally animated, image resource that is neither paged nor scripted.</p>

<p>{class=note}Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs), single-page vector
documents (single-page PDFs, XML files with an SVG root element), animated bitmaps (APNGs,
animated GIFs), animated vector graphics (XML files with an SVG root element that use
declarative SMIL animation), '''''canvas''''', and so forth. However, this also precludes SVG files with
script, multipage PDF files, interactive MNG files, HTML documents,
plain text documents, and so forth.</p>
<p>'''''The the alt attribute provides an equivalent short label for any non-text content, so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.'''''"</p></blockquote>

* Change to [http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#media-element-attributes 4.8.10 Media elements]

Replace this:
<blockquote>
"The media element attributes, src, preload, autoplay, mediagroup, loop, muted, and controls,
apply to all media elements. They are defined in this section."</blockquote>

With this:
<blockquote>
"The media element attributes, src, '''''alt''', '''longdesc''','' preload, autoplay, mediagroup, loop, muted,
and controls, apply to all media elements. They are defined in this section."</blockquote>

NEW: Add the following definitions for these attributes:

<blockquote>
''' alt: The the alt attribute provides an equivalent short label for any non-text content, so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language. Also, when images are turned off or disabled, elements that support the alt attribute MUST render the short label defined by the alt attribute.'''
</blockquote>
<blockquote>
<p>'''longdesc: The longdesc attribute may be present. This attribute contains a link to a long description of the image. If present, it must contain a valid non-empty URL potentially surrounded by spaces.'''</p>

<p>'''Web authors are encouraged to use this attribute for long text alternatives that are either too long to be included in the main flow of the document or benefit from structured markup that cannot be included in an alt attribute.'''</p>

<p>'''To obtain the corresponding long text alternative link, the value of the attribute must be resolved relative to the element. The link must point to either a different document from the image or a fragment of the same document that does not contain the image. User agents should allow users to access long text alternatives in a device independent manner. Rendering examples are provided in the rendering section.'''</p>

<p>'''The longdesc IDL attribute must reflect the element's longdesc content attribute.'''</p>

<p>'''{class=note} When the long description is included in a separate Web page, this page can then be reused for all occurrences of the image on the Website. If the separate Web page contains any additional information besides the long description, the longdesc URL needs to contain a fragment address to the particular section on that page that contains the long description. This will provide users direct access to the description.'''</p>
</blockquote>

(NOTE: Location/placement of these definitions in the specification at the discretion of the editor)

== Impact ==

=== Positive Effects ===

* Satisfies the WCAG [http://www.w3.org/TR/WCAG/#text-equiv Guideline 1.1 "Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language"] by providing a programmatic means of associating both short and long textual descriptions to media elements.
* Re-uses existing, well known native HTML attributes that the majority of authors both know, use and understand. This will aid in rapid adoption and a short learning curve, resulting in a quick accessibility "win".
* Unlike other methods of supplying a short label to the media elements (for example aria-label), using @alt will (MUST) render text on screen when images are turned off or disabled.
* Unlike other methods of supplying a longer description for the media elements, @longdesc does not impose any visual encumbrance on the web page or page author.

=== Negative Effects ===

* None

=== Conformance Classes Changes ===

* Unknown

=== Risks ===

'''* This Change Proposal has a dependency on the resolution of [http://www.w3.org/html/wg/tracker/issues/30 Issue 30]'''

== References ==

__NOTOC__

ChangeProposals/Reference a W3C version of DOM Parsing and Serialization

Tross — Sat, 25 Feb 2012 00:16:10 GMT

Abateman2: Added note about Microsoft volunteering to edit and that this is a decision of the chairs.

== Change Proposal ==

== Summary ==
The innerHTML, outerHTML, and insertAdjacentHTML APIs were previously defined in the HTML5 specification.
Currently these APIs are defined in the DOM Parsing and Serialization specification outside of the W3C.
This proposal entails publishing the DOM Parsing and Serialization specification within the HTML WG
and updating the HTML5 specification to normatively reference this new version.

== Rationale ==
By moving the definition of innerHTML, outerHTML, and insertAdjacentHTML outside of the W3C, the W3C patent policy no longer applies to these APIs.
Creating a version of the DOM Parsing and Serialization specification in the HTML WG restores the application of the W3C patent policy to these APIs
while minimizing the editorial churn that would otherwise be associated with integrating these APIs back into the HTML5 specification.

== Details ==
Publish DOM Parsing and Serialization as currently defined at http://html5.org/specs/dom-parsing.html in the HTML WG.
Then update the current DOM Parsing and Serialization reference in HTML5 to point to the new spec.

Microsoft volunteers to provide an editor for this specification in the HTML WG. Of course, the chairs own the ultimate decision of who to appoint to edit documents in the working group (see http://www.w3.org/2005/10/Process-20051014/tr.html#DocumentsGeneral). The chairs may choose someone else if they have other volunteers.

[http://dev.w3.org/html5/spec/Overview.html#references References]

'''[DOMPARSING]'''<br/>
<del>
[http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization], Ms2ger. html5.org.
</del><br/>
<ins>
[http://www.w3.org/TBD DOM Parsing and Serialization], Ms2ger. W3C.
</ins>

== Impact ==
== Positive Effects ==
The W3C patent policy continues to apply to innerHTML, outerHTML, and insertAdjacentHTML.
Other de-facto APIs such as DOMParser also get standardized in the W3C.

== Negative Effects ==
None identified

== Conformance Classes Changes ==
None identified

== Risks ==
If a copy of DOMParsing and Serialization continues to be maintained outside of the W3C, the two may get out of sync.

ChangeProposals/CaretTracking

Cpritcha — Tue, 14 Feb 2012 14:52:31 GMT

Cpritcha: /* Rationale */

= Augment the Canvas 2D API to include caret navigation and selection =

== Summary ==
Augment the Canvas 2D API to allow caret, and selection position information to be conveyed to third-party applications, with a focus on Screen magnification products per WCAG and UAAG designed to support users with low vision. This in response to [http://www.w3.org/html/wg/tracker/issues/131 Issue 131].
__TOC__

== Rationale ==
The existing Canvas 2D API specification does not provide an API to allow an author to notify a screen magnifier as of location changes in the caret position and content selection boundaries. AI Squared, a leading screen magnifier vendor for Windows, has provided feedback on this issue. That feedback is located in the [http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases WhatWG use cases WIKI] set up by the HTML5 editor. The Canvas 2D API introduced fillText and strokeText mechanisms for the display of text. While authors may superimpose text fields onto canvas, using "color: transparent" and close alignment, the solution has varies drawbacks. This solution has been used with some success by pdf.js. It is not being used by other Canvas projects. While the method is an appropriate solution for static rendering of PDF, it lacks flexibility and accuracy when applied to other scenarios and requires precise font management and conditions. It is insufficient for rich text, embedded font layout, custom fonts, and arbitrary objects and glyphs. The scope of SVG and HTML does not include arbitrary text decoration or non-standard language, font styles or glyphs.

Based on the current canvas 2D API specification we have the following deficiencies in meeting the requirements of a screen magnifier vendor like AI Squared:

# ZoomText tracks alignment of objects based on information made available by the author and UA. ZoomText users can specify center, parent or edge alignment for text cursor, focus and window objects differently. In order to provide the correct alignment for the user we need a way to understand the role of a given path. the current scrollPathIntoView function does not indicate whether the path applies to a cursor nor does it associate an element in canvas fallback content which would provide the role of the corresponding object. Because of this deficiency, ZoomText can not identify the object type being scrolled into view.
# ZoomText may use parent alignment: we need to be able to retrieve the location of the parent element of the path. The goal of parent alignment is to keep the parent object in view (or partial view) while making sure the current object is displayed within the magnified view. scrollPathIntoView does not provide an association to the element in fallback content where the role of the object and its parent would be available.
# ZoomText often replaces the text cursor with that of a different shape based on the role of the element. ZoomText users will select different text cursors based on the role.
# Not all platforms move the caret with the selection point. In fact, Mac OSX allows the selection point (where the user is pointing during a selection drag) to move while the caret location is fixed. scrollPathIntoView does not provide this.
# Mac OS X has highlight options for highlighting the current caret position for keyboard+caret navigation built into the OS. This feature would work with Canvas if the information is exposed by the author, through the UA. The feature is part of VoiceOver.
# The current drawSystemFocusRing and drawCustomFocusRing functions address either caret or selection notification changes to the assistive technology.
# Some platforms are entirely browser-based, such as Google's Chrome OS. These platforms use additional accessibility APIs often under a private namespace. With Chrome OS, it is the chrome.* namespace. Event listeners on this namespace must be notified of positions in caret and selection for ATs to work at all on the platform.
# Some platforms have browser extensions which implement assistive technology techniques. These extensions can be used instead of an OS-based AT. These extensions should still follow WCAG and expose data; further, they need programmatic access to data on target sites. It's reasonable that an AT would be written in Canvas; it's also reasonable that the AT would work with an appropriately marked up Canvas-based application.

To address this issue government procurement standards, such as 508, require applications to support system font and color settings. If your application does not comply you fail purchasing requirements. It should be noted that, in our proposal, if no system setting has been set for focus ring then the drawFocusRing simply draws along the path as the author specified while at the same time updating the magnifier based on the focus ring.

== Details ==

I would like to resubmit the setCaretSelectionRect method from the modifications to the
[http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/att-0129/HTML_Canvas_2DContext20110415.html Canvas 2D Context API Specification], in the [http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection 2011 Issue 131 change proposal], for inclusion in section 9 Complex Shapes (paths) in light of the growing use of canvas for rich text editing. The changes are included here:

* Include the following definition of setCaretSelectionRect in the set of functions highlighted in green at the beginning of section 9 of the Editor's draft (http://dev.w3.org/html5/2dcontext/#complex-shapes-paths)
success = context . setCaretSelectionRect(element, x, y, w, h)
Returns true if the given element is focused or a document descendant of an element with focus. Otherwise, returns false.
* Include the following text for setCaretSelectionRect between the invocation processing specifications for [http://dev.w3.org/html5/2dcontext/#dom-context-2d-drawcustomfocusring drawCustomFocusRing] and [http://dev.w3.org/html5/2dcontext/#dom-context-2d-scrollPathIntoView scrollPathIntoView] in section 9:
The setCaretSelectionRect(element, x, y, w, h) method, when invoked, must run the following steps:

*If element does not have selected content and is not focused return false and abort these steps.
*If the element is not a descendant of the element with whose context the method is associated, then return false and abort these step.
*Transform the given point (x, y), the width w, and the height h according to the current transformation matrix.
*If the user agent supports a platform accessibility API the user agent must use the element, transformed coordinates and transformed bounding box, and provide it through the supported accessibility API implementation.
*Return true.

== Impact ==

The impact to the specification is minor and it minimizes the impact to authors while producing a more reliably accessible solution.

=== Positive Effects ===
* Provides for both screen magnifier tracking of caret and selection location changes on canvas separate from focus rings to allow a user agent to drive the appropriate platform accessibility APIs.
* Provides a vehicle to determine the associated role of the element being drawn on canvas in fallback content as well as vehicle to determine the role of its parent element.
* Changes the caret information provided to a screen magnifier to include width and height information to aid magnifiers in zooming around a caret or selection position.
* Caret and Selection position APIs are lite weight. The APIs support screen magnification without restricting the user's drawing ability. This also allows this same API to drive magnification zooming when the author wants to draw the magnifier zoom to other drawing constructs.
* Enables emerging assistive software, such as ChromeVox, to notify a magnifier of caret and selection changes so that the users can change the corresponding pointer cursor (it may be smaller for different drawing objects at different magnification levels as an example) and follow the point of user interaction during caret navigation and selection, often via keyboard.

=== Negative Effects ===

* Caret and Selection are not integrated with actual drawing. However, it is questionable that we could produce something that is rich enough for canvas

=== Risks ===
* Although outside the scope of this issue, this proposal does not address another need for screen magnification involving conveying screen screen coordinates of all content rendered from the fallback content on canvas. There is a separate change proposal to address this for [http://www.w3.org/wiki/Canvas_hit_testing Canvas Hit Testing Change Proposal].

== References ==

*[http://www.w3.org/html/wg/tracker/issues/131 Issue 131]
*[http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html Original Working Group Decision on Issue 131]
*[http://dev.w3.org/html5/2dcontext HTML Canvas 2D Context Editor's Draft]
*[http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection Original Caret, Selection, and FocusRing Change Proposal for Issue 131]
*[http://www.w3.org/wiki/Canvas_hit_testing New Canvas Hit Testing Change Proposal for Issue 131]
*[http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline New Focus Ring Text Baseline Proposal for Issue 131]
*[http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/att-0162/HTML_Canvas_2DContext20110217.html Modifications to 2D Context (earlier version but still applicable)]
*[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11342 Bug 11342 Request to expose text baseline in TextMetrics]
*[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11342 Bug 11239 Canvas support accessible caret tracking independent of Focus Ring tracking (with refrence to code to implement Bug 11342]
__NOTOC__

ChangeProposal/Issue194

Jfoliot — Mon, 13 Feb 2012 05:27:00 GMT

Jfoliot: /* Summary */

= Change Proposal =

Introduce a new attribute: @transcript

== Summary ==
This Change Proposal seeks to introduce a new attribute to the <video> element, @transcript, which would takes as a value either an URI to a separate page, or a fragment identifier to a location elsewhere on the same page. Creating a specific attribute removes any ambiguity of the linking mechanism – making it a DOM identifiable node. As an attribute of the video element, it provides a mechanism for linking to the transcript without forcing a visual encumbrance on the design aesthetic.

__TOC__

== Rationale ==

Raised from bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964

Full transcripts give people with disabilities a way to access audio/video
content. Transcripts are often provided as a separate resource, because they're
often too lengthy to be included on the same page as the audio/video they're
associated with.

A mechanism that creates an association between an audio/video element and a
full (off page) transcript would have many benefits. These include
discoverability for assistive technology users, programmatic identification for
search engine indexing, design aesthetic, and content syndication or
embedding..

== Details ==

A high-level prose description of the changes to be made follows:

Linking to an external transcript:
<code>
<video controls <span style="background-color:#ff9">transcript="_path_to_transcript_(relative or absolute)_"</span>>
<source="_path_to_WebM_file_" type="video/webm">
<source="_path_to_mp4_file_" type="video/mp4">
<track="_path_to_TTML_file_" kind="captions">
(etc.)
</video>
</code>

Linking to a transcript on the same page:
<code>
<video controls <span style="background-color:#ff9">transcript="#transcript"</span>>
<source="_path_to_WebM_file_" type="video/webm">
<source="_path_to_mp4_file_" type="video/mp4">
<track="_path_to_TTML_file_" kind="captions">
(etc.)
</video><br><br>
<div id="transcript">
-- Insert Transcript here --
</div>

</code>

<strong>Note:</strong> While authors <u>can</u> insert the transcript into the parent page of the video, and then use any number of hiding techniques to place it off screen, author Best Practices should discourage this, for the following reasons:

* transcripts benefit more than just non-sighted users - in fact users with cognitive disabilities are actually one of the main beneficiaries of full transcripts.

* full transcripts can often contain a large amount of text, which will add some weight [sic] to the page, slowing downloads and using un-needed bandwidth when a transcript is not required.

== Impact ==

=== Positive Effects ===

* A dedicated, programmatic linking mechanism that ensures access to a full transcript of the video is maintained
* Does not force content authors to place a visible link to the transcript on-screen, respecting design considerations often present

=== Negative Effects ===

* Requires that browsers and other user-agents provide a mechanism for users to discover the link to the transcript, and the ability to access the transcript on demand.
* Like @longdesc, some authors may misunderstand how to use the @transcript mechanism - this can be mitigated with good authoring instructions and examples.

=== Conformance Classes Changes ===

* Unknown

=== Risks ===
* Unknown

== References ==

__NOTOC__

ChangeProposals/movealt

Sfaulkne — Fri, 10 Feb 2012 10:03:00 GMT

Sfaulkne: /* New Information */

=Re-open Request for [http://www.w3.org/html/wg/tracker/issues/31 ISSUE-31: Author conformance requirements for the alt attribute on images]=

== Summary ==
This Re-open request and Change Proposal addresses the issue of Working Group (WG) location of guidance on alternative text. Currently there are two divergent versions of similar material among the set of HTML5 deliverables. While the previous decision by the HTML WG resulted in an additional document providing guidance on alternative text, the guidance on alternative text remaining in the main HTML WG specification continues to contain duplicative, in some cases inaccurate in other cases inadequate material despite multiple bugs having been filed to remove/modify or add that guidance [https://www.w3.org/Bugs/Public/show_bug.cgi?id=9216 9216], [https://www.w3.org/Bugs/Public/show_bug.cgi?id=9215 9215], [https://www.w3.org/Bugs/Public/show_bug.cgi?id=8827 8827], [https://www.w3.org/Bugs/Public/show_bug.cgi?id=8652 8652], [https://www.w3.org/Bugs/Public/show_bug.cgi?id=8645 8645], [https://www.w3.org/Bugs/Public/show_bug.cgi?id=7362 7262].

This proposal provides a rationale for re-opening the question of WG location of alt guidance, and change proposals for resolving current problems in guidance for alternative text in the main HTML5 specification and for moving primary conformance requirements on alternative text to the Web Content Accessibility Guidelines Working Group (WCAG WG).

The grounds for re-opening are:
# a pattern of rejected bugs relating to the content of the text alternative advice in HTML5
# The issue is still unresolved as evidenced by 2 sets of contradictory normative requirements, each of which duplicate in some part the superset of normative requirements and informative guidance contained within WCAG 2.0 and the Techniques for WCAG 2.0, while a subset of the normative requirements contained in the HTML5 specification contradict WCAG 2.0 documents.
#The majority of normative authoring requirements for alternative text currently contained within the HTML5 specification are not HTML5-specific, but are also useful and relevant for authoring content in other specifications besides HTML5. They should therefore not be prescribed within HTML5.
#Much of the normative requirements for alternative text currently in "HTML5: Techniques for providing useful text alternatives" are relevant for authoring content in other specifications. Accuracy, appropriateness, and effectiveness for meeting user needs across diverse contexts for alternative text are all important to ensuring equivalent access to information that is visually presented. The WCAG WG is more suited to development and vetting of the requirements and guidance of alternative text at this level, while the product of that development and vetting process can be equally available to developers using any specification.

== Rationale ==

The HTML 5 specification suite currently has two sets of advice about providing useful text alternatives. One is [http://www.w3.org/TR/html5/embedded-content-1.html#alt 4.8.1.1 Requirements for providing text to act as an alternative for images], the other is a separate closely related document [http://www.w3.org/TR/2011/WD-html-alt-techniques-20110525/ HTML5: Techniques for providing useful text alternatives].

A subjective summary of the genesis of these resources is that the HTML 5 draft long ago made the <code>alt</code> attribute an optional feature of the <code>img</code> element, because use cases could be presented for which a good value was unknown. Accessibility advocates objected that this renders the <code>img</code> element incomplete from a non-visual browsing perspective and deprioritizes accessibility in the HTML 5 conformance model. To partially address that concern while retaining a deterministic conformance model, content was introduced into the specification that detailed circumstances in which the <code>alt</code> attribute is required or particular values are valid; this is the section embedded in the specification referenced above. Accessibility advocates, including users with visual disabilities who rely on alternative text for access to visually presented content, however, noted that this did not adequately address the initial concern and did not present advice that uniformly and completely represents accessibility best practices. They attempted to improve this section through a detailed Change Proposal, but ultimately the difficulty in gaining traction on that in the specification led to the spinning off of the change proposal as a separate deliverable of the HTML Working Group, which is the second resource referenced above.

While a lot of good work has been done, the current state is that there are two obviously divergent versions of the same material among the set of HTML deliverables. While in general the HTML 5 specification focuses on defining the features of the HTML 5 language without overly prescribing authoring or user agent expectations, the section on text alternatives is a notable exception. The confusion it introduces on what constitutes a normative part of the HTML 5 conformance model is a part of the problem that has led to difficulty agreeing on the appropriate content of that section. Separating it would allow a clean conformance model for HTML 5. Note that separating this content does not relieve HTML 5 of the responsibility to provide the features necessary to author accessible content, it merely deconfounds the HTML 5 conformance model from the accessibility practices.

=== New Information ===
The majority of normative authoring requirements for alternative text currently contained within the HTML5 specification are not HTML5-specific; such advice is equally relevant to other document formats such as PDF, SVG, Microsoft Word, ODF and others. They should therefore not be prescribed within HTML5. Additionally, the majority of the normative requirements for alternative text currently in "HTML5: Techniques for providing useful text alternatives" are useful and relevant for authoring content in other specifications besides HTML5, and therefore should not be explicitly associated with HTML5, but rather be seamlessly available to authors of HTML5 and to other specifications through links and/or a common interface as needed.

Much of the normative requirements for alternative text currently in "HTML5: Techniques for providing useful text alternatives" are relevant for authoring content in other specifications. Accuracy, appropriateness, and effectiveness for meeting user needs across diverse contexts for alternative text all are important to ensuring equivalent access for people with visual disabilities to information that is visually presented. These requirements need to be carefully developed and and vetted among accessibility experts, including users with disabilities. Requirements and guidance needs to be assigned to normative or informative levels, according to extensive experience regarding which guidance is more fundamental and/or more well-tested, and which is more advisory or even experimental. Furthermore, as guidance on alternative text continues to evolve, it requires ongoing vetting and maintenance by a Working Group charged with this scope of work, and chartered to produce periodic updates of accessibility guidance that is relevant across different technical specifications including HTML5. The WCAG WG is more suited to development, vetting, and ongoing maintenance of guidance of alternative text; and the products of that ongoing development, vetting, and maintenance can be equally available to developers using any specification.

For example take the following from the [http://dev.w3.org/html5/spec/the-img-element.html#a-phrase-or-paragraph-with-an-alternative-graphical-representation:-charts-diagrams-graphs-maps-illustrations HTML5 specification].

4.8.1.1.3 A phrase or paragraph with an alternative graphical representation: charts, diagrams, graphs, maps, illustrations
Sometimes something can be more clearly stated in graphical form, for example as a flowchart, a diagram, a graph, or a simple map showing directions.
In such cases, an image can be given using '''the img element''', but the lesser textual version must still be given, so that users who are unable to view
the image (e.g. because they have a very slow connection, or because they are using a text-only browser, or because they are listening to the page
being read out by a hands-free automobile voice Web browser, or simply because they are blind) are still able to understand the message being conveyed.
The text must be given in the '''alt attribute''', and must convey the same message as the image specified in the '''src attribute'''.
It is important to realize that the alternative text is a replacement for the image, not a description of the image.

The only HTML specific aspects of the above are (bolded) references to the img element and its alt/src attributes. The rest of what is specified relates equally to many document formats available from the web. It is the mechanics of providing text alternatives that is an integral part of HTML and rightly prescribed in the HTML5 specification. The requirements for what an author is to provide as a text alternative for a graphical object is not unique to HTML and therefore the argument for its inclusion in the HTML specification is considerably weaker and the argument for it to be normatively specified in HTML5 is especially weak.

The HTML WG [http://lists.w3.org/Archives/Public/public-html/2011Apr/0453.html decision on issue 31] stated:

"This issue can be reopened if new information come up. Examples of
possible relevant new information include:
*Identification of a systemic pattern of problems based on specific
bug reports and their ultimate resolution and identify a solution
that specifically addresses the underlying causes.
* Publication of a new version of WCAG that contains sufficient
concrete examples relevant to HTML5 which would serve as a suitable
reference."

The following bugs indicate such a pattern:
* [https://www.w3.org/Bugs/Public/show_bug.cgi?id=9215 request for addition of webcam example] - rejected
* [https://www.w3.org/Bugs/Public/show_bug.cgi?id=9216 request for an addition of a Captcha example] - rejected
* [https://www.w3.org/Bugs/Public/show_bug.cgi?id=13651 request to limit the length of conforming text alternatives for figcaption] - rejected
* [https://www.w3.org/Bugs/Public/show_bug.cgi?id=9077 request to change the conformance requirements for decorative images] - rejected
* [https://www.w3.org/Bugs/Public/show_bug.cgi?id=14937 request to not allow the title attribute antipattern to be used for images] - rejected

This change proposal resolves all of these issues as all of the issues are resolved in [http://dev.w3.org/html5/alt-techniques/ HTML5: techniques for providing useful text alternatives]:

* [http://dev.w3.org/html5/alt-techniques/#sec10 conformance requirements and Webcam advice provided]
* [http://dev.w3.org/html5/alt-techniques/#sec13 conformance requirements and Captcha advice provided]
* [http://dev.w3.org/html5/alt-techniques/#m5 advice on alternative text length provided]
* [http://dev.w3.org/html5/alt-techniques/#sec6 conformance requirements and advice on images that may be considered decorative]
* [http://dev.w3.org/html5/alt-techniques/#secm7 conformance requirements on title attribute usage]and advice on how to [http://dev.w3.org/html5/alt-techniques/#m6 markup captions for images]

We emphasize that WCAG 2.0 is not a static specification nor a single document
by design. Rather, the [http://www.w3.org/TR/WCAG20/#intro-related-docs Web Content Accessibility Guidelines] expressly specifies, [http://www.w3.org/WAI/intro/wcag20#main Understanding WCAG 2.0],
reiterates that these two documents are to be taken together along with the
continually evolving [http://www.w3.org/TR/WCAG20-TECHS/ Techniques for WCAG 2] as constituting "WCAG 2.0." An update to any of them constitutes
and "update to WCAG" By design WCAG is a "living specification" because we
accomodate technological development by continually adding and adjusting WCAG
techniques

Thus, relocating the HTML5 techniques document to the WCAG working group
fulfills the second revisiting issue prerequisite: "Publication of a new
version of WCAG that contains sufficient concrete examples relevant to HTML5
which would serve as a suitable reference." As all WCAG techniques constitute
an update to WCAG 2.0. Furthermore, relocating this document to WCAG will
ensure its ongoing maintenance in the ongoing work of the [http://www.w3.org/WAI/GL/wiki/Techniques/HTML5 Joint PF and WCAG Task Force on HTML 5 Techniques].

== Details ==
Remove the following non- HTML specific normative requirements from HTML5 specification as they are are equally applicable to any document format published on the web that can include non text objects:
* 4.8.1.1.1 General guidelines
* 4.8.1.1.2 A link or button containing nothing but the image
* 4.8.1.1.3 A phrase or paragraph with an alternative graphical representation: charts, diagrams, graphs, maps, illustrations
* 4.8.1.1.4 A short phrase or label with an alternative graphical representation: icons, logos
* 4.8.1.1.5 Text that has been rendered to a graphic for typographical effect
* 4.8.1.1.6 A graphical representation of some of the surrounding text
* 4.8.1.1.7 A purely decorative image that doesn't add any information
* 4.8.1.1.8 A group of images that form a single larger picture with no links
* 4.8.1.1.9 A group of images that form a single larger picture with links
* 4.8.1.1.10 A key part of the content
* 4.8.1.1.11 An image not intended for the user

===Instead:===
* Link to the WCAG 2.0 normative requirements for non text objects: [http://www.w3.org/TR/WCAG/#text-equiv Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
* Link to[http://dev.w3.org/html5/alt-techniques/ HTML5 techniques for providing useful text alternatives]
* Link to the general WCAG 2.0 text alternative techniques in order to provide seamless access to comprehensive and technology-neutral guidance on provision of alternative text that meets the requirements of people with visual and other disabilities.
* Make [http://dev.w3.org/html5/alt-techniques/ HTML5 techniques for providing useful text alternatives] a WAI/HTML WG deliverable.
* Remove normative aspects of the techniques document.

==Impact==

===Positive Effects:===

- Remove duplicative and/or inadequate requirements;
- Allow development, vetting, and maintenance of guidance on alternative text under an appropriately scoped Working Group already chartered for this scope and for ongoing maintenance of accessibility guidance;
- Provide guidance on alternative text that is technology-neutral in a location that can be made equally available to all relevant specifications.

===Negative Effects:===

- None.

ChangeProposals/CaretSelectionRevised

Rschwer — Thu, 09 Feb 2012 14:59:32 GMT

Rschwer: /* Rationale */

= Modify existing Canvas 2D API to include APIs that allow a screen magnifier to track caret and selection change movements =

== Summary ==
Modify the Canvas 2D API to properly handle caret, and selection position to assist screen magnification products to support users with low vision in using canvas. This in response to [http://www.w3.org/html/wg/tracker/issues/131 Issue 131].
__TOC__

== Rationale ==
The existing Canvas 2D API specification does not provide an API to allow an author to notify a screen magnifier as of location changes in the caret position and content selection boundaries. AI Squared, a leading screen magnifier vendor for Windows, has provided feedback on this issue. From the [http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases WhatWG use cases WIKI] we have the following use cases of product that employ text and rich text editing:

# [https://www.lucidchart.com/documents/edit?demo&noShowMngr#4c01-2f20-4fc7fdeb-a501-27510a78454f?demo=on Lucidart Drawing Tool] Is a diagramming tool that allows an author to edit text labels for drawing objects just like Visio and PowerPoint. The caret is drawn using a separate canvas element with no means to provide for caret and selection tracking during editing.
# [http://listarchives.libreoffice.org/global/design/msg03226.html LibreOffice uses HTML5 canvas for its office editors] is an HTML5 Canvas office suite with multi-language support. The Office editors need caret and selection tracking to allow for blind access.

In some cases authors may superimpose a text field onto a canvas and allow the user to enter text there and benefit from operating system features such as built in Input Method Editors. This method is used for text selection by the Mozilla PDF.js project. While the method is an appropriate solution for simple text entry, such as providing labels for a drawing object, it lacks flexibility and accuracy when applied to other text editing scenarios and is insufficient for rich text editors which embedded font layout, custom fonts, and arbitrary objects and glyphs. The scope of SVG and HTML does not include arbitrary text decoration or non-standard language, font styles or glyphs.

Based on the current canvas 2D API specification we have the following deficiencies in meeting the requirements of a screen magnifier vendor like AI Squared:

# ZoomText tracks alignment of objects based on information made available by the author and UA. ZoomText users can specify center, parent or edge alignment for text cursor, focus and window objects differently. In order to provide the correct alignment for the user we need a way to understand the role of a given path. the current scrollPathIntoView function does not indicate whether the path applies to a cursor nor does it associate an element in canvas fallback content which would provide the role of the corresponding object. Because of this deficiency, ZoomText can not identify the object type being scrolled into view.
# ZoomText may use parent alignment: we need to be able to retrieve the location of the parent element of the path. The goal of parent alignment is to keep the parent object in view (or partial view) while making sure the current object is displayed within the magnified view. scrollPathIntoView does not provide an association to the element in fallback content where the role of the object and its parent would be available.
# ZoomText often replaces the text cursor with that of a different shape based on the role of the element. ZoomText users will select different text cursors based on the role.
# Not all platforms move the caret with the selection point. In fact, Mac OSX allows the selection point (where the user is pointing during a selection drag) to move while the caret location is fixed. scrollPathIntoView does not provide this.
# The current drawSystemFocusRing and drawCustomFocusRing functions address either caret or selection notification changes to the assistive technology.

To address this issue government procurement standards, such as 508, require applications to support system font and color settings. If your application does not comply you fail purchasing requirements. It should be noted that, in our proposal, if no system setting has been set for focus ring then the drawFocusRing simply draws along the path as the author specified while at the same time updating the magnifier based on the focus ring.

== Details ==

I would like to resubmit the setCaretSelectionRect method from the modifications to the
[http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/att-0129/HTML_Canvas_2DContext20110415.html Canvas 2D Context API Specification], in the [http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection 2011 Issue 131 change proposal], for inclusion in section 9 Complex Shapes (paths) in light of the growing use of canvas for rich text editing. The changes are included here:

* Include the following definition of setCaretSelectionRect in the set of functions highlighted in green at the beginning of section 9 of the Editor's draft (http://dev.w3.org/html5/2dcontext/#complex-shapes-paths)
success = context . setCaretSelectionRect(element, x, y, w, h)
Returns true if the given element is focused or a document descendant of an element with focus. Otherwise, returns false.
* Include the following text for setCaretSelectionRect between the invocation processing specifications for [http://dev.w3.org/html5/2dcontext/#dom-context-2d-drawcustomfocusring drawCustomFocusRing] and [http://dev.w3.org/html5/2dcontext/#dom-context-2d-scrollPathIntoView scrollPathIntoView] in section 9:
The setCaretSelectionRect(element, x, y, w, h) method, when invoked, must run the following steps:

*If element does not have selected content and is not focused return false and abort these steps.
*If the element is not a descendant of the element with whose context the method is associated, then return false and abort these step.
*Transform the given point (x, y), the width w, and the height h according to the current transformation matrix.
*If the user agent supports a platform accessibility API the user agent must use the element, transformed coordinates and transformed bounding box, and provide it through the supported accessibility API implementation.
*Return true.

== Impact ==

The impact to the specification is minor and it minimizes the impact to authors while producing a more reliably accessible solution.

=== Positive Effects ===
* Provides for both screen magnifier tracking of caret and selection location changes on canvas separate from focus rings to allow a user agent to drive the appropriate platform accessibility APIs.
* Provides a vehicle to determine the associated role of the element being drawn on canvas in fallback content as well as vehicle to determine the role of its parent element.
* Changes the caret information provided to a screen magnifier to include width and height information to aid magnifiers in zooming around a caret or selection position.
* Caret and Selection position APIs are lite weight. The APIs support screen magnification without restricting the user's drawing ability. This also allows this same API to drive magnification zooming when the author wants to draw the magnifier zoom to other drawing constructs.
* Enables emerging rich text editors, such as LibreOffice, to notify a magnifier of caret and selection changes so that the users can change the corresponding pointer cursor (it may be smaller for different drawing objects at different magnification levels as an example) and follow the point of user interaction during rich text editing.

=== Negative Effects ===

* Caret and Selection are not integrated with actual drawing. However, it is questionable that we could produce something that is rich enough for canvas

=== Risks ===
* Although outside the scope of this issue, this proposal does not address another need for screen magnification involving conveying screen screen coordinates of all content rendered from the fallback content on canvas. There is a separate change proposal to address this for [http://www.w3.org/wiki/Canvas_hit_testing Canvas Hit Testing Change Proposal].

== References ==

*[http://www.w3.org/html/wg/tracker/issues/131 Issue 131]
*[http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html Original Working Group Decision on Issue 131]
*[http://dev.w3.org/html5/2dcontext HTML Canvas 2D Context Editor's Draft]
*[http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection Original Caret, Selection, and FocusRing Change Proposal for Issue 131]
*[http://www.w3.org/wiki/Canvas_hit_testing New Canvas Hit Testing Change Proposal for Issue 131]
*[http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline New Focus Ring Text Baseline Proposal for Issue 131]
*[http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/att-0162/HTML_Canvas_2DContext20110217.html Modifications to 2D Context (earlier version but still applicable)]
*[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11342 Bug 11342 Request to expose text baseline in TextMetrics]
*[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11342 Bug 11239 Canvas support accessible caret tracking independent of Focus Ring tracking (with refrence to code to implement Bug 11342]
__NOTOC__

ChangeProposals/ARIA Processing

Cooper — Thu, 09 Feb 2012 02:16:29 GMT

Cooper: Tweaks from http://www.w3.org/mid/20120628192019.GA3590@sonata.rednote.net believe this leads us to a consensu-ready proposal

= Change Proposal: Add role attribute and enhance ARIA lexical processing guidance =

== Summary ==

Complete section [http://dev.w3.org/html5/spec/wai-aria.html#wai-aria 3.2.7 WAI-ARIA] to provide complete language support by introducing appropriate attributes and their definitions.

== Rationale ==

Lexical processing requirements for ARIA role, state, and property attributes are vague in HTML. While they are defined in other places, authors must know to follow a series of links to find all the requirements. This proposal provides more explicit references to additional processing requirements.

This change proposal provides the data needed to address [http://www.w3.org/html/wg/tracker/issues/199 Issue 199: Define complete processing requirements for ARIA attributes].

== Details ==

=== Clarify the existing ARIA section ===

People seemed to be misreading the relationship of the parts of the section so this editorial change should help to distinguish them better. Add the following structure to [http://dev.w3.org/html5/spec/wai-aria.html#wai-aria 3.2.7 WAI-ARIA] to accommodate the remaining additions.

# Before the paragraph beginning "The following table defines the strong native semantics..." add a header "Strong Native Semantics".
# Before the paragraph beginning "Some [http://dev.w3.org/html5/spec/infrastructure.html#html-elements HTML elements] have native semantics that can be overridden" add a header "Implicit ARIA Semantics".

=== Define ARIA attributes[http://dev.w3.org/html5/spec/global-attributes.html#global-attributes ] ===

==== ARIA Role Attribute ====

Add a new section to [http://dev.w3.org/html5/spec/wai-aria.html#wai-aria 3.2.7 WAI-ARIA] before the header "Strong Native Semantics" proposed above. The new section header is "ARIA Role Attribute" with the following content:

<blockquote>
<p>Every <span title="HTML elements">HTML element</span> may have an ARIA <code title="attr-aria-role">role</code> attribute specified. This is an <span>ARIA Role attribute</span> as defined by the Accessible Rich Internet Applications (WAI-ARIA) specification [http://www.w3.org/TR/wai-aria/roles#role_definitions Section 5.4 Definition of Roles].</p>

<p>The attribute, if specified, must have a value that is a <span>set of space-separated tokens</span> representing the various WAI-ARIA roles that the element belongs to.</p>

<p>[Implementer only section] The WAI-ARIA role that an <span title="HTML elements">HTML element</span> has assigned to it is the first non-abstract role found in the list of values generated when the <code title="attr-aria-role">role</code> attribute is <span title="split a string on spaces">split on spaces</span>.</p>
</blockquote>

==== State and Property Attributes ====

Add a new section to [http://dev.w3.org/html5/spec/wai-aria.html#wai-aria 3.2.7 WAI-ARIA] before the header "Strong Native Semantics" proposed above and after the section "Role Attribute" proposed above. The new section header is "State and Property Attributes". The section should have the following content (known to need wording enhancement to improve readability; expectation is the implementing editor will wordsmith and check with the group before finally committing to the spec):

<blockquote>
<p>Every <span title="HTML elements">HTML element</span> may have ARIA state and property attributes specified. These attributes are defined by the Accessible Rich Internet Applications (WAI-ARIA) specification in [http://www.w3.org/TR/wai-aria/states_and_properties#state_prop_def Section 6.6, Definitions of States and Properties (all aria-* attributes)].</p>

<p>These attributes, if specified, must have a value that is the ARIA value type in the "Value" field of the definition for the state or property, mapped to the appropriate HTML value type according to [http://www.w3.org/TR/wai-aria/appendices#typemapping Section 10.2 Mapping WAI-ARIA Value types to languages] using the HTML 5 mapping.</p>

<p>ARIA State and Property attributes can be used on any element. They are not always meaningful, however, and in such cases user agents might not perform any processing aside from including them in the DOM. State and property attributes are processed according to the requirements of the sections [Strong Native Semantics] and [Implicit ARIA semantics], the [http://www.w3.org/TR/2010/WD-wai-aria-implementation-20100916/ WAI-ARIA User Agent Implementation Guide] [ARIA-IMPLEMENTATION], and the [http://www.w3.org/TR/wai-aria/ Accessible Rich Internet Applications 1.0] [ARIA] specification.</p>
</blockquote>

== Impact ==

=== Positive Effects ===

* Provides an explicit hook for ARIA in HTML 5.
* Allows forwards compatibility of ARIA roles by not disallowing unrecognized values.

=== Negative Effects ===

* Does not explicitly permit custom roles, but does not define consequences for using them aside from noting that such roles could later be defined by ARIA.

=== Conformance Classes Changes ===

This change proposal should have the effect only of clarifying lexical processing for ARIA without introducing conformance changes. It is possible conformance checkers with incorrect processing due to earlier ambiguity would need to be updated.

=== Risks ===

Implementers must use several specifications to arrive at a complete implementation model for ARIA in HTML 5. This increases the risk that implementations will be incomplete or erroneous.

== References ==

This change proposal was originally drafted by Michael Cooper, and reflects an attempt to harmonize with [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-199 Ted O'Connor's counter proposal] according to discussion of this and [http://lists.w3.org/Archives/Public/public-html/2012Mar/0613.html Ian Hickson's critique] in the [http://www.w3.org/2012/05/03-html-wg-minutes#item03 3 May 2012 HTML WG Face to Face discussion] of the topic.

ChangeProposals/Text Alternatives Ownership

Cooper — Tue, 07 Feb 2012 17:31:24 GMT

Cooper:

= Change Proposal: Make "Techniques for providing useful text alternatives" a WCAG deliverable =

== Summary ==

This change proposal is to transfer the deliverable [http://www.w3.org/TR/2011/WD-html-alt-techniques-20110525/ HTML5: Techniques for providing useful text alternatives] to the [http://www.w3.org/WAI/GL/ Web Content Accessibility Guidelines Working Group]. This would reduce confusion both within and outside W3C about the provenance of accessibility authoring advice and more clearly separate authoring guidelines from lexical processing requirements for images.

This Change proposal constitutes a reopen request for [http://www.w3.org/html/wg/tracker/issues/31 Issue 31]. Rationale is provide in the rationale section.

This draft change proposal appears to be superseded by [[ChangeProposals/movealt | Re-open Request for ISSUE-31: Author conformance requirements for the alt attribute on images]]. Accordingly it is not currently planned to submit this change proposal.

== Rationale ==

'''Disputed content: '''In general, the HTML 5 specification focuses on defining the features of the HTML 5 language from a lexical processing perspective overly prescribing authoring requirements or user agent presentation expectations. But the section on text alternatives is a notable exception, providing authoring guidance for a specific set of situations and entwining those with the conformance model. This overly restricts authors' ability to meet accessibility needs in certain situations while leaving other situations undefined, introducing confusion on what constitutes a normative part of the HTML 5 conformance model. This in turn has led to difficulty agreeing on the appropriate content of that section, and led to the creation of an alternate version [http://www.w3.org/TR/2011/WD-html-alt-techniques-20110525/ HTML5: Techniques for providing useful text alternatives].

'''Provenance of accessibility advice: '''The content of this document is focused on conformance to Web Content Accessibility Guidelines 2.0, not on the lexical aspects of providing text alternatives in HTML. Its status as an HTML deliverable confuses readers about the provenance of the advice. The advice about good text alternatives for accessibility first is applicable to any content technology, not just HTML, and second, as accessibility guidance, is best maintained by people professionally focused on accessibility issues.

'''External references: '''Some external organizations (including the US Access Board, the European Commission, and ISO JTC 1/SC 35) have been looking to W3C as a source of guidance for advice on text alternatives but had difficulty because of these provenance considerations. ISO in fact is engaged in the creation of an alternate document that may offer conflicting advice from that of W3C, and the fact that the W3C document is not maintained by the Web Accessibility Initiative is a reason that W3C's document is not considered as authoritative as hoped.

[http://lists.w3.org/Archives/Public/public-html/2011Apr/0453.html Decision on ISSUE-31] "Identification of a systemic pattern of problems based on specific bug reports and their ultimate resolution and identify a solution that specifically addresses the underlying causes." and "Publication of a new version of WCAG that contains sufficient concrete examples relevant to HTML5 which would serve as a suitable reference."

WCAG is not Member-restricted group, i.e., it operates in public. Work on techniques for HTML 5 is being done via a joint task force with the PFWG [http://www.w3.org/WAI/GL/wcag-pf-html5-task-force HTML 5 Techniques for WCAG 2.0] which also operates in public and has recruited broad membership.

== Details ==

# Remove [http://www.w3.org/TR/2011/WD-html-alt-techniques-20110525/ HTML5: Techniques for providing useful text alternatives] from the set of deliverables of the HTML Working Group.
# Request the [http://www.w3.org/WAI/GL/ WCAG Working Group] take over development of [http://www.w3.org/TR/2011/WD-html-alt-techniques-20110525/ HTML5: Techniques for providing useful text alternatives]. The possibility of this has been raised with the WCAG Working Group and it is expected that the group will accept the deliverable, most likely in the form of an "application note" for WCAG 2.0. The document would focus on general guidance for authoring useful text alternatives in various situations. HTML-specific techniques would be removed from this document and published in [http://www.w3.org/TR/WCAG20-TECHS/ Techniques for WCAG 2.0].

== Impact ==

=== Positive Effects ===

* Clarifies that proper implementation of text alternatives in pages is a question of HTML conformance, while proper values for text alternatives is a question of WCAG conformance.
* Provides a simpler background to frame discussion on other outstanding issues related to text alternatives.
* Makes a general purpose resource more maintainable and referenceable by other content languages for which it is also applicable.

=== Negative Effects ===

* Some may be concerned about introducing a reference to an external resource.

=== Conformance Classes Changes ===

* Authoring tools may need to remove advice about conformance implications of providing certain kinds of text alternatives.

=== Risks ===

None found.

== References ==

References are provided inline.

ChangeProposals/outlinenone

Sfaulkne — Wed, 01 Feb 2012 15:00:15 GMT

Sfaulkne: /* Remove CSS authoring advice that promotes inaccessible content */

= Remove CSS authoring advice that promotes inaccessible content =

by Steve Faulkner. [mailto:faulkner.steve@gmail.com faulkner.steve@gmail.com]

updated: 2/2/2012

== Summary ==

The HTML5 specification [http://dev.w3.org/html5/spec/editing.html#element-level-focus-apis advises use] of CSS outline:none, in cases where authors find the default focus indicator "unsightly". This advice is unecessary and promotes a well known anti-pattern that makes it very difficult for keyboard only users to navigate and interact with web content.

__TOC__

== Rationale ==

The specification discourages the use of the Javascript element.blur() method to "hide the focus ring" presumably because of its negative usability /accessibility effects. Yet the spec then advises instead to use a method that is known and widely documented as a usability /accessibility issue for keyboard only users. The specification even [http://dev.w3.org/html5/spec/editing.html#element-level-focus-apis acknowledges this]:

Instead, use a CSS rule to override the 'outline' property. '''(Be aware, however, that this makes the page significantly less usable for some people,'''
'''especially those with reduced vision who use focus outlines to help them navigate the page.)'''

Note the quoted spec text above incorrectly states that use of outline:none 'especially' affects those with 'reduced vision'. The use of outline:none has a major effect upon all keyboard only users regardless of visual impairment.

There is ample documented evidence of focus outline being a major accessibility issue:

[http://www.access-board.gov/sec508/standards.htm#Subpart_b Section 508 requirement]:

(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus
changes. The focus shall be programmatically exposed so that Assistive Technology can track focus and focus changes.

[http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible WCAG 2.0 requirement]:
2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

The issue has been widely documented:
* [http://24ways.org/2009/dont-lose-your-focus Don't Lose Your :focus]
* [http://accessites.org/site/2007/05/keyboard-friendly-link-focus/ keyboard friendly link focus]
*[http://www.456bereastreet.com/archive/200905/do_not_remove_the_outline_from_links_and_form_controls/ Do not remove the outline from links and form controls]
* [http://www.456bereastreet.com/archive/201104/keyboard_accessibility_again/ Keyboard accessibility (again)]
*[http://webaim.org/blog/plague-of-outline-0/ The plague of outline:0]
* [http://www.abilitynet.org.uk/webarticle180 Focus on keyboard users]
* It even has its own web site [http://outlinenone.com/ '''outlinenone.com''']

The HTML5 editor reasons for including the advice, as stated in the [https://www.w3.org/Bugs/Public/show_bug.cgi?id=13023#c2 bug rejection]:

Rationale: Authors want to do this. If they're going to do it anyway, let's at
least push them towards doing it the way that is trivially made accessible
rather than what they do now (which is to move the focus around).

Problem with the rationale is that no evidence has been given that the frequency of use of the issue his advice is supposed to be fixing actually has any significant impact on users, while the opposite is true for his supposed solution. At the very least before we start advocating the use of a method that has signifcant negative impacts on users with disabilities, we have to ensure that original issue is signifcant and is the only available option to reduce the harm caused by the use of .blur(). Furthermore there has been no evidence to show that the outline method "is trivially made accessible".

== Details ==
'''Remove''' the following from the HTML5 specification:

<p>Do not use this method to hide the focus ring if you find the
focus ring unsightly. Instead, use a CSS rule to override the
'outline' property. (Be aware, however, that this makes the page
significantly less usable for some people, especially those with
reduced vision who use focus outlines to help them navigate the page.)</p>
<div class="example">
<p>For example, to hide the outline from links, you could use:</p>
<pre>:link:focus, :visited:focus { outline: none; }</pre>
</div>

'''Replace''' the above text with:

<p>Do not use this method to hide the focus ring. Do not use any other method that hides the focus
ring from keyboard users,in particluar do not use a CSS rule to override the 'outline' property. Removal
of the focus ring leads to serious accessibility issues for users who navigate and interact with interactive
content using the keyboard.</p>

== Impact ==

=== Positive Effects ===

* Removes advice from spec that will encourage authors to make web content less accessible.

=== Negative Effects ===

Some time to make the edits.

=== Conformance Classes Changes ===

None

=== Risks ===

None

== References ==

*[http://www.w3.org/html/wg/tracker/issues/193 ISSUE-193]
*[https://www.w3.org/Bugs/Public/show_bug.cgi?id=13023 Bug 13023]

__NOTOC__

[[Category:ChangeProposal]]
[[Category:Issues]]

FlowContentInObject

Lsilli — Mon, 30 Jan 2012 12:10:03 GMT

Lsilli: /* Rebutting block element nesting problems claims */

[[Category:ChangeProposal]]
[[Category:Issues]]





[[User:Lsilli|Leif Halvard Silli]] 15:26, 9 February 2012 (UTC) ''(Rebuttal-section: 28th of March 2012.)''

= Change Proposal for ISSUE-158: =
== Content model of <code>object</code> should be [http://dev.w3.org/html5/spec/content-models#flow-content-0 flow content] + [http://dev.w3.org/html5/spec/content-models.html#interactive-content-0 interactive content]==

* Submitted to the HTMLwg [http://lists.w3.org/Archives/Public/public-html/2012Feb/0083 on February the 9th 2012].
* There are [[#Corrections]] since the submission, see References section, bottom of the page.

== Summary ==

The content model of the <code>object</code> element should change from [http://dev.w3.org/html5/spec/content-models.html#transparent-content-models transparent] to [http://dev.w3.org/html5/spec/content-models#flow-content-0 flow content] + [http://dev.w3.org/html5/spec/content-models.html#interactive-content-0 interactive content]. That it is not transparent but instead flow content means that it doesn't inherit the content model of its parent. That the content model also is interactive content means that it can contain interactive content even if its parent element is interactive too.

This would '''— A —''' allow block elements as children of <code><object></code> when <code>object</code> is child of <code><p></code> or inline element — like in this example:
<pre><p>Mug shot of Frank Sinatra
<object data=mugshot >
Black and white photo of a young Frank Sinatra.
The data stamped on the photo are:
<dl>
<dt>Location: <dd>Bergen County Sheriff's Office
<dt>Date: <dd>11.27.38
<dt>Number: <dd>42799
</dl>
</object>
</p></pre>

And '''— B —''' allow interactive elements as children of <code>object</code> whose parent is interactive — as in this example:
<pre><p>Mug shot of Frank Sinatra
<a href=link-to-sinatra-page >
<object data=mugshot >
<a href=description>external description</a>
</object>
</a>
</p></pre>

'''NOTE:''' There is — seemingly — a exception to the nested anchors example: If the very <code>object</code> itself had been interactive (such as if the <code>usemap</code> attribute had been present), then <code>object</code>’s parent could not have been an interactive element. However, that is not really related to this change proposal, but instead depends on the fact that a (direct) child of the <code>a</code> element is not allowed to be interactive.

__TOC__

== Rationale ==

===For block content as children of <code>object</code> as children of <code>p</code>===

If structured fallback as child of <code>object</code> is necessary, then:

# <code>object</code> is thought of as an alternative to the <code>longdesc</code> attribute and the <code>aria-describedby</code> attribute, because it - unlike the <code>img</code> element - allows mark-up in its fallback. (An <code>aria-describedby</code> could even point to <code>object</code>’s fallback.) There should therefore not be puristic restrictions on the content model.
# HTML5's restrictions on nesting of <code>p</code> elements and on what <code>p</code> elements may contain, are due to, quote: “[http://dev.w3.org/html5/spec/introduction.html#restrictions-on-content-models-and-on-attribute-values peculiarities of the parser]” that causes <code>p</code> to be auto-closed. However, in case of <code>object</code>, then these peculiarities do not exist: The HTML5 parser does, without parsing issues, accept block content inside <code>object</code> even when these block elements could not have been children of the parent.
# Authors will add such content in anyway. Example: HTML5 includes [http://dev.w3.org/html5/spec/the-param-element#the-param-element an code example] where the fallback includes a <code>p</code> element despite that, in that example, the parent of the <code>object</code> element is an <code>p</code> as well. But for the author of this very change proposal, not a single HTML Working Group member has made it a problem of this break against the current HTML5 syntax rules.
# HTML5 describes how to implicitly (that is: without the use of the explicit <code>p</code> — paragraph — element) nest paragraphs and it uses an object element to examplify it - see [http://dev.w3.org/html5/spec/content-modelsl#paragraph the last example in HTML5's description of paragraphs]. Hence, the very model — a paragraph inside a object inside another paragraph — is already known by HTML5.

===For interactive content as child of an <code>object</code> whose parent is interactive===

# It works in the parser(s): [http://malform.no/messages/issue-158/file-1 test file]. Tested in the gui browsers IE9, Firefox, Webkit, Opera, the text browsers Lynx, W3M, elinks, links. Based on earlier evidence. With regard to gui browsers, they will normally display what the e.g. the <code>data</code> attribute points to, and this works without a hitch. However, with regard to the test file, then it tests what happens when the fallback is displayed. One thing that works nicely when fallback is displayed, is keyboard navigation (tabbing) from link to link.
# It should not require parser changes because test shows that it works and because, even by now, the HTML5 spec permits an ''image map object'' to contain <code>area</code> elements — and thus logically also <code>a</code> and other interactive elements: <br><code><object usemap=#map data=img><br><map name=map><area href=link alt=link ><br></map></object></code>
#* '''NOTE:''' For some reason, HTML5 currently does not consider the <code>area</code> element as interactive content. And this despite that it is possible — [http://malform.no/messages/issue-158/file-2.html see demo that works in Webkit, Opera and Firefox 3.6 and IE9] — to style <code>area</code> elements to look like links. ([https://bugzilla.mozilla.org/show_bug.cgi?id=725921 A bug has been filed to make it work in Firefox post version 4 as well].) And also despite that HTML5's WAI-ARIA sections [http://dev.w3.org/html5/spec/wai-aria.html#table-aria-strong states that <code>area</code> has a strong link role]. The validator even accepts that a <code>map</code> element is nested inside and <code>a</code> element — which doesn't immediately make sense. Hence, it is possible that HTML5 has a bug in this regard. ''In fact,'' a bug to classify area as interactive content [https://www.w3.org/Bugs/Public/show_bug.cgi?id=15948 has now been filed]. '''But let it therefore anyway be said''' that, in the case of <code><object usemap=* data=*></code>, then the HTML5 parser (at least in [http://validator.w3.org/nu/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%3Bbase64%2CPCFET0NUWVBFIGh0bWw%2BPHRpdGxlPjwvdGl0bGU%2BPG9iamVjdCBkYXRhPWEgdXNlbWFwPSNiID48YSBocmVmPWFiYz5hYmM8L2E%2BPC9vYmplY3Q%2BPG1hcCBuYW1lPWI%2BPGFyZWEgaHJlZj1jIGFsdD0iZCIgPjwvbWFwPg%3D%3D&showsource=yes Validator.w3.org/nu’s interpretation], fully accepts a link a child of an <code>object</code> that is used as image map.
# It has always been permitted (e.g. in HTML4 and XHTML1). But note that per HTML4 and XHTML1, then it is permitted to wrap an anchor element ''around'' <code>object</code> even when the object is interactive: This CP does not at all touch that aspect of HTML5.
# In most situations, the fallback link will not be “parsed” by the user — because in most cases, fallback is not what most users get. Thus the potential confusion is hidden and only revealed to them it could benefit, such as text browser and screen readers.
# It offers an alternative to @longdesc and @aria-describedby — when either of them does not work (e.g in a text browser)
# It would work well in tandem with @aria-describedby (which could point to the content of <code>object</code>)
# It simplifies the content mode of object: Authors don't have to wast time on learning that interactive content sometimes aren't permitted — instead it will always be permitted. (As told, the only limitition will that, if the very <code>object</code> element is interactive, then it may only occur in contexts where interactive content i spermitted. ''Currently, HTML5 considers presence of the <code>usemap</code> attribute as the only way to turn the <code>object</code> element itself into [http://dev.w3.org/html5/spec/content-models.html#interactive-content-0 interactive content].'')

== Details ==

Exact spec text for the sections to be changed: Replace this line:<blockquote>[http://dev.w3.org/html5/spec/the-object-element#the-object-element Zero or more param elements, then, transparent.]</blockquote> with this line:<blockquote>Zero or more param elements, then, flow content and interactive content.</blockquote>

Additional, optional changes: At the HTML editor's discretion, it is suggested that HTML5's [http://dev.w3.org/html5/spec/content-models.html#paragraphs section on paragraphs] is updated with an example to reflect this change. (See in particular the last example(s).) And also, examples to demonstrate the permitted anchor nesting.

== Impact ==

=== Positive Effects ===

The flow content model change and the interactive content model change has these benefits:
* Separation of concerns: It becomes more straight forward to add fallback content to <code>object</code>. For exacmple: Even when inside a <code>p</code> element, authors can just fill it with content without having to re-author the page first (that is: they don't need to make changes to the parent element in order to add the most optimal fallback content).
* How the HTML5 parser works and what is conforming for authors to do, becomes more congruent.
* Useless warnings during conformance checking is avoided.

=== Negative Effects ===

* In some legacy versions of one parser engine (Trident), block elements inside <code>object</code> is difficult to use — it depents on the parent element of the <code>object</code> what works. (There was also an issue in Firefox 9 — but this got fixed in Firefox 10, see below).
*# Counter argument: Trident is being updated — this is already an issue of the past roughly since at least IE8.
*# Counter argument: The [http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1313 issue in Firefox 9] (that the content of <code>object</code> occurs at the then of the paragraph instead of where it should occure), has nothing to do with the content model of <code>object</code>. Additionally, that issue was fixed with Firefox 10.
*# Counter argument: In both IE legacy and Firefox legacy's case, a wrapper in the form of a <code>span</code> element is a solution.

=== Conformance Classes Changes ===

Only authoring and validation will be affected. Parsing is unchanged (at least as far as this CP author is able to see).

=== Risks ===

# Relevant ATs are known for not supporting fallback of <code>object</code> very well, and so authors could use this method without getting the expected results.
#* Counter argument: This is not i particular related to the issue of the content model of <code>object</code>, but more of a general problem that UA and AT have to fix. In fact, the problem is unrelated to what the parent element is. It is only to the extent that this CP makes it simpler — and thus more attractive — to use <code>object</code>, that this has any relevance.
#* Counter argument: There is a drive (see Jonas Sicking's change proposal for the longdesc issues) towards making <code>aria-describedby</code> reveal not only the plain text version of the element(s) it points but also semantic mark-up — if successfull, then one can use this method to reveal the fallback of <code>object</code> as well.
# It promotes use of <code>aria-describedby</code> for presenting the fallback of <code>object</code> <br>(by letting the attribute point to the very object element itself — or directly to the fallback).
#* Counter argument: No. Until further, aria-describedby will turn the fallback into a text string — and thus work against the use fo structure in the fallback. This CP could just as well encourage AT to present the fallback with its mark-up semantics, without any look at ARIA. Futher more, if such side effects exist, then they exist even without this CP — and it is only to the extent that this CP makes <code>object</code> more attractive to use, that it bears any relevance.
# When <code>object</code> is used for non-interactive images in need of a long description, <br>then this change negatively impact the case for the inclusion of the <code>longdesc</code> attribute.
#* Counter argument: In any case, the change of this CP should be evaluated on its own merit.
#* Counter argument: No. This change is only about the content model. Regardless of this change proposal, one ''can'' include a link inside the fallback of e.g. <code><object data=image></object></code>. All this CP does is that it makes it simpler for authors to add structured and interactive content inside the fallback. To the extent that ATs will be able to render structured and interactive fallback inside <code>object</code>, then it would probably be possibel to use this method instead of using <code>longdesc</code> — however, that issue is nevertheless not related to this CP. The AT issues with fallback inside <code>object</code> — that they natively (that is: without ARIA) often support it badly — are not affected by this change proposal.

== Rebuttal of the [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-158 Counter Change Proposal - CCP] ==

The CCP was also [http://lists.w3.org/Archives/Public/public-html/2012Mar/0462.html rebutted in public-html] — please consider that message part of this rebuttal section.

=== Rebutting block element nesting problems claims ===

# '''Contrary to what the CCP says, the CP proposes a natural solution:''' The CCP portrays what the CP suggests w.r.t. block elements inside <code>object</code> inside <code>p</code> elements as essentally against the very nature of HTML. However, HTML4/XHTML1 have always allowed <code>p</code> inide <code>p</code> and <code>h1</code>-<code>h6</code> elements, as long as the “misnested” element (the <code>p</code> in the <code>p</code> or in some other “illegal” place) is wrapped inside a <code>button</code>, <code>object</code> or <code>map</code> element.
# '''Authors’ most trusted source tells authors that what this CP proposes, is legal.''' The CCP claims, without documentation, that the block element nesting aspects of the CP goes against “numerous educational materials”. By contrast, it is very simple to document that the most respected authority, the W3C HTML4/XHTML1 validator, tells you to that you ''can'' wrap a <code>p</code> in a <code>p</code> or a in a <code>h1-h6</code> element, as long as you use <code>button</code>, <code>object</code> or <code>map</code> as wrapper: [http://validator.w3.org/check?uri=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%3Bbase64%2CPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEvL0VOIj4NCjx0aXRsZT5EZW1vIG9mIEhUTUw0J3MgY29udGVudCBtb2RlbDwvdGl0bGU%252BDQoNCg0KPCEtLSBUaGlzIGlzIHZhbGlkOiAtLT4NCjxoMT48b2JqZWN0IGRhdGE9aW1hZ2UgPjxkaXY%252BIEhlYWRpbmcgdGV4dCA8L2Rpdj48L29iamVjdD48L2gxPg0KDQo8IS0tIFRoaXMgaXMgaW52YWxpZDogLS0%252BDQo8aDE%252BPGRpdj4gSGVhZGluZyB0ZXh0IDwvZGl2PjwvaDE%252BDQoNCjwhLS0NCg0KICAgICBNZXNzYWdlIGZyb20gdGhlIHZhbGlkYXRvciBmb3IgdGhlIGFib3ZlIGgxIGVsZW1lbnQ6DQoNCiAgICAgZG9jdW1lbnQgdHlwZSBkb2VzIG5vdCBhbGxvdyBlbGVtZW50ICJESVYiIGhlcmU7IA0KICAgICBtaXNzaW5nIG9uZSBvZiAiT0JKRUNUIiwgIk1BUCIsICJCVVRUT04iIHN0YXJ0LXRhZw0KDQotLT4NCg%253D%253D&charset=%28detect+automatically%29&doctype=Inline&ss=1&group=1&user-agent=W3C_Validator%2F1.3 Try this document in the validator] (look at the source code at the bottom of the validator page).
# '''The CP ''does'' list substantial benefits of the nesting change:''' The CCP claims that the CP fails to “explicate any particular benefit to this change”. However, this is not true. The benefits are listed above - a brief recap:
## We increase the utilty of <code>object</code> when it comes to accessibility, by allowing e.g. a diagram image to fallback to a table — without having to alter the possible <code>p</code> parent of the <code>object</code> element. <br>'''Examples:'''
##* '''a)''' A browser that doesn't render images, can render the table instead of the image of the object element. This should nicely with e.g. @<code>[http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/describedat.html aria-describedAT]</code>: Image supporting ATs with ARIA support can visit the external description, while AT without image or ARIA support, such as text browsers, can use the fallback. Another “image-less” browser is search engines — with the table in the fallback, the page page can contain more indexable data.
##* '''b)''' Depending on the effects and outcome of [http://dev.w3.org/html5/status/issue-status.html#ISSUE-184 ISSUE-184], ATs mights be able to render the table, despite that the fallback is essentially hidden.
## We don't disturb authors by unuseful validity contraints that could, possibly, lead them to not add the fallback that is most optimal for the users. We know from @<code>alt</code> attribute validaton that authors tend to just add an empty attribute, in order to be valid. Thus we can be pretty sure that the current rules will impact negatively on what authors place in <code>object</code>’s fallback: They might remove content instead of altering the parent element. Thus, by removing the need to alter the parent element, we remove that particular obstacle;
## We also avoid giving a false impression: The CCP tries to uphold a simplistic image of HTML. But HTML isn't quite as simplistic as the CCP wants it to be. Let's deal with it. Heck, the CCP admits that what the CP proposes, is compatible with the HTML5 parser. ''In fact, I would be as bold as to claim that the CCP faviours HTML teachers rather than HTML authors.'' Because, the CP does not propose a difficult rule, even if it perhaps — from a HTML teacher's point of view — complicates thing a little bit.
# '''The purpose of the CP is ''not'' to allow “tricks”''': The CCP mentions that <code>object</code> makes it ''“possible to trick the parser into making the second paragraph a descendant of the first by wrapping the second”''. However, the claim that the CP is about “tricks“, have allready been [http://www.w3.org/mid/20120315071937899996.cb1049ef@xn--mlform-iua.no refuted on public- html]: The goal with the CP is ''not'' “tricks”. The “tricks“ were easy to do in HTML4, where @<code>data</code> and @<code>type</code> were not required — thus one could easy and lazily “circumvent” the content models. But in HTML5, these attributes are required, and thus it requires a active misuse from the authors’s side if the goal is to '''both''' take advantage of the HTML5 parser's treatment of <code>object</code> while '''also''' staying ''— formally —'' valid.
#* In fact, depending on the purpose with that kind of “circumvention” of the content model, then it is already possible: One can add a valid but still fake (read: unsupported) value in the @<code>type</code> attribute (in combination with no @<code>data</code> attribute) — without this trick, the fallback will not display to the average user. Because, who would use the <code>object</code> to perform “tricks“ unless the intention is that everyone — and not just those who are served the fallback — experiences the “trick”? To use the object element for its fallback features, is indeed to use it for the wrong reasons — but neither this CP nor HTML5 prevents that kind of abuse. If there ''are'' bad effects of this change, then it can be solved by restricting which values of the @<code>type</code> attribute that should be permitted — that's the right place to fix the problem.
# '''The CP does not argue against authoring conformance criteria:''' That the CP says that authors will do this anyway is not a main argument but a subsequent argument. The main argument is that authors will add structured content, including <code>p</code> inside <code>p</code> ''with the best intentions'': Good, strucktured fallback for the users. Heck, as I document above, HTML5 itself includes one such example. And thus, the CP argues, that we should not make things difficult for authors, by telling them that they do something wrong when what they do doesn't create problems anyhow.
# '''The <code>object</code> element is not unique within HTML5:''' This CP’s proposed content model for <code>object</code> differs from that of the new media elements — <code>video</code>, <code>audio</code>, <code>canvas</code>. The new media elements work the same way that the CCP would like the <code>object</code> to (be considered to) be working: If one does e.g. add a <code>p</code> in a <code>video</code> which has <code>p</code> as its parent (<code><p><video><p></video></code>), then the inner <code>p</code> will be moved outside of both the <code>video</code> element and the outer <code>p</code> element, thus resulting in a DOM with two ''parallel'' — also known as ''adjacent'' — <code>p</code> elements. However, this does not prevent authors from adding <code>p</code> inside <code>video</code>: All it takes is that authors makes sure the parent of the media element is something ''other'' than the <code>p</code> element. Whether this is any intuitive, can be debated, but at least authors can see — visually — what happens in the DOM. Thus, for the new media elements, the authoring requirements are about more than theoretical purity: The HTML5 parser works that way. Note, by the way, that for <code>video</code> adn <code>audio</code>, then — unlike for <code>object</code> — the fallback, quote: “[http://www.w3.org/TR/html5/the-iframe-element.html#the-video-element is not intended to address accessibility concerns]”, and so the limited content model should not hamper accessibility. (But w.r.t. the <code>canvas</code> element, then it seems entirly possible that affectst what authors place in the fallback.). So — once more — ''<code>object</code>’s content model from the HTML5 parser’s point of view, differs from that of the new media elements.'' '''However, the <code>object</code> is not the sole element that the HTML5 ''parser'' treats this way:''' In addition to <code>object</code> then both <code>button</code> and the obsolete but still used (in internet banking that dependens on Java applets) <code>applet</code> element have the same effect on the DOM. Common to these elements is that ''— A —'' <code>p</code> inside e.g. <code>object</code> inside <code>p</code> does work and ''— B —'' authors ''can see'' that that is how it works. <br> ''Which model is best, the <code>object</code> model or the <code>video</code> model?'' And is that the right question? This CP consider that, when there are use cases, the authoring requirements should reflect how the HTML5 parser works and not operate with rules which prescribe things to be authored in ways which the HTML5 parser does not require.

=== Rebuttal of interactivity change claims ===

# '''The CP does not encourage authors to do anything “highly confusing“:''' The CCP cites the introduction to HTML5, which takes as example that <code>button</code> is not allowed to contain <code>textarea</code>. And yes, a <code>textarea</code> as child <code>object</code> that in turn was the child of a <code>button</code>, might easily be a highly confusing thing. However, [http://lists.w3.org/Archives/Public/public-html/2012Mar/0462.html like I stated in public-html], for someone to do that specific thing, would require the author to misuse the fallback: The fallback should be a replacement for the media that the <code>object</code> is embedding. That the fallback really ''does'' fit as fallback, is for the author to decide. But most would probably agree that it is almost never the case that a <code>textarea</code> is useful as fallback for any thing that <code>object</code> can represent. So, once again, we see that the CCP’s claims presupposes ''a lot more'' than just those things that are in the CP: The CCP presupposes that the author has no sense or understanding for what fallback means — that it is supposed to reflect that which it is fallback for.
# '''HTML5 ''itself'' includes code examples where there are a link inside an interactive element:''' When <code>video</code> or <code>audio</code> include the @<code>controls</code> attribute, then they are considered “[http://www.w3.org/TR/html5/the-iframe-element.html#the-video-element Interactive content]“. (Ironically, this means that if the controls are added via JavaScript, then it is not considered interactive. But anyway:) If one were to read very ''literally'' what [http://www.w3.org/TR/html5/introduction.html#introduction HTML5’s introduction] says about, quote “the way interactive content cannot be nested”, then one ought to think that HTML5 never provides examples of interactive content inside interactive elements. ''However,'' HTML5 does permit links ''inside'' <code>object</code> even if it has the @<code>usemap</code> attribute. And, equivalently, when the @<code>controls</code> attribute is present on <code>video</code> and <code>audio</code> then one should think that it would be ''non-concorming'' to place a link for downloading the video file in those media element’s fallback. However, there appears to be no such rule: These elements are still considered transparent. Hence, the HTML5 editor includes two code examples for the <code>video</code> element which do ''precisely'' include a link, despite the presence of the @<code>controls</code> attribute. ''See [http://www.w3.org/TR/html5/sections.html#the-footer-element 4.4.9 The footer element] and [http://www.w3.org/TR/html5/the-iframe-element.html#the-object-element 4.8.4 The object element].''
# '''It is the default that matters:''' When HTML5’s introduction talks about “highly confusing”, then it links it to the default behaviour: ''”This is because <em><u>the default behavior</u></em> of such nesting interactive elements would be highly confusing to users.“'' This thinking ought to be in line with the CP, which focuses presicely on the default behavior: The default is that the user does not see the fallback.

=== Rebuttal of invariant break claims related to “rich fallback” ===

# '''The CP does not break “a basic invariant of fallback content”.''' <br>The CCP [http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-158#Rich_fallback_content_and_content_models currently says], and I quote — the emphasis is mine: <br><br> ''“If fallback content is equivalent in this way, it should be possible to remove the surrounding <object> (and its <param> children) without changing the meaning or conformance of the document. <em><u>If we adopt the Content model of object should be flow content + interactive content Change Proposal, this would no longer be the case. We will have broken a basic invariant of fallback content.</u></em>“''<br><br> The CCP’s claims here appears taken out the air — although it is not at all clear what exactly it tries to say. But my guess is that it tries to claim that the current restrictions — the fact that e.g. a <code>table</code> is not possible in the fallback if the <code>object</code>’s parent is a <code>p</code> element — will prevent the author from adding something in the fallback that isn't usefull as fallback. With that as my interpretatation, ''here is my response:''<br><br>
## Firstly, as I have already said previously in this CP, the HTML5 spec ''does'' include the idea of nested paragraphs. It allows it by exending the definition of what at paragraph is: It is not just the <code>p</code> that is is a paragraph. And so, authors can nest paragraphs. They just can't use the <code>p</code> to do the nesting.
## Consequently, the way HTML5 defines it, it does not matter whether the paragraph is represented by a <code>li</code>, <code>p</code> or a <code>div</code>. And so, even today, authors can embed e.g. a table in <code>object</code> — it is just that they must, in order to be valid, take care to change the parent <code>p</code> into e.g. a <code>div</code>.
## And so, with or without the CP, it remains possible to add fallback that isn't suitable as fallback. The CP does not impact on that at all: The CP ''only'' makes it ''simpler'' to embed e.g. a <code>table</code> in the fallback. Because, whether a <code>table</code> is suitable as fallback for the <code>object</code>, does not — in real life — depend on whether the parent of the <code>object</code> is a <code>p</code> or a <code>div</code>. In fact, it would be unfortunate if authors thought there was such an interdependence. And the ''good thing'' about the CP is that it ''removes'' the possibility that the author doesn't add proper fallback because <code>object</code>'s parent tag doesn't allow it.<br><br>
# The current state of affairs has a problem that sofar has not been taken up: It might trigger authors not only to change the parent <code>p</code> to a <code>div</code> — they might even remove the parent element altogether, as shown in [http://www.w3.org/TR/html5/content-models.html#paragraphs HTML5’s secton on paragraphs]. When the parent element is removed, a CSS styling hook is removed as well — which is yet another negative experience, solely for the goal of being “valid”.

== References ==

* [http://malform.no/messages/issue-158/file-1 Test file nested anchors] (<code><a href=*>Foo<object><a href=*>foo</a></object></a></code>).

===Corrections===

Corrections since the submission to the HTMLwg:

# Deleted the mention of the <code>tabindex</code> attribute in the [[#Summary]] section
#* Why: The text wrongly indicated that the HTML5 spec considers that presence of <code>tabindex</code> attribute turns an element into [http://dev.w3.org/html5/spec/content-models.html#interactive-content-0 interactive content]. But the correct thing is that HTML5 does not consider that the <code>tabindex</code> attribute has any such effect: It is [http://dev.w3.org/html5/spec/content-models.html#interactive-content-0 only when the <code>usemap</code> attribute is present], that HTML5 considers <code>object</code> ''interactive content''.)
# Added a new sentence at the bottom of the [[#Rationale]] section: ''Currently, HTML5 considers presence of the usemap attribute as the only way to turn the object element itself into interactive content.''
#* Why: For clarification.
# Added author signature on top of the page.
#* Why: For clarificaiton
# Added the word ''“for”'' in this heading: [[#For interactive content as child of an object whose parent is interactive]].
#* Why: For congruence with the preceding heading.
# Added a ''NOTE point'' under list item 2 inside the rationale section [[#For interactive content as child of an object whose parent is interactive]].
#* Why: Because I took for granted that HTMl5 considers the <code>area</code> elemetn to be interactive content, however at the time of this writing, <code>area</code> [http://dev.w3.org/html5/spec/content-models.html#interactive-content-0 is not listed by HTML5 as interactive content].
# Replaced, in the rationale section ([[#For interactive content as child of an object whose parent is interactive]]) a referenc to Webkit with a cross browser reference: «see demo that works in Webkit, Opera and Firefox 3.6 and IE9» + a link to [http://malform.no/messages/issue-158/file-2.html a file which demoes this] plus a link to [https://bugzilla.mozilla.org/show_bug.cgi?id=725921 a bug in Firefox].
#* Why: To demonstrate its broad support.
# Add this sentence: ''In fact,'' a bug to classify area as interactive content [https://www.w3.org/Bugs/Public/show_bug.cgi?id=15948 has now been filed].
#* Why: It is relevant.

* Note that pure typos are corrected as they are discovered — check the page history.

* 28th of March: Added rebuttal secton of the Counter Change Proposal.

__NOTOC__

ISSUE-187-CP

Jkosek — Fri, 20 Jan 2012 21:36:34 GMT

Jkosek: /* Summary */

IncludeRB

Lsilli — Thu, 05 Jan 2012 14:05:35 GMT

Lsilli: /* Change Proposal for ISSUE-172: Include the rb element */

= Change Proposal for [http://www.w3.org/html/wg/tracker/issues/172 ISSUE-172]: Include the rb element =
[[User:Lsilli|Leif Halvard Silli]] 03:12, 23 January 2012 (UTC)

== Summary ==

This proposal requests:

#'''that the [http://www.w3.org/TR/ruby/#rb rb element], which is currently [http://dev.w3.org/html5/spec/obsolete.html#rb considered obsolete], is included''' — for the following reasons:
#* '''legacy documents:''' <code>rb</code> inclusion makes legacy mark-up ([http://addruby.com/var/84016_XMJG4M3BM31BB717PM5AXCXFVXA7GDY8171CBATKXNKEJYJJZJFWJNRMXRSVJWBY.html?ts=1325865039 in the wild] and per [http://www.w3.org/TR/xhtml11/xhtml11.html#a_changes XHTML 1.1] where <code>rb</code> is [http://validator.w3.org/check?uri=data%3Aapplication%2Fxhtml%2Bxml%3Bcharset%3Dutf-8%2C%3C%21DOCTYPE+html+PUBLIC+%22-%2F%2FW3C%2F%2FDTD+XHTML+1.1%2F%2FEN%22+%22http%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml11%2FDTD%2Fxhtml11.dtd%22%3E%3Chtml+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22+xml%3Alang%3D%22en%22+lang%3D%22en%22%3E%3Chead%3E%3Ctitle%3E%3C%2Ftitle%3E%3C%2Fhead%3E%3Cbody%3E%3Cp%3E%3Cruby%3EWWW%3Crt%3EWorld+Wide+Web%3C%2Frt%3E%3C%2Fruby%3E%3C%2Fp%3E%3C%2Fbody%3E%3C%2Fhtml%3E&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.2 is mandatory]) HTML5-compatible.
#* '''legacy tools:''' <code>rb</code> inclusion allows tools to operate with largely identical ruby modes for XHTML 1.1 simple ruby and (simple) HTML5 ruby (instead of operating two modes that differ greatly) and, as well, allows authors to use XHTML 1.1 tools to create HTML5-compatible ruby content.
#* '''native wrapper:''' that <code>rb</code> only belongs in the ruby ''format'', allows tools to auto-insert it together with the parent <code>ruby</code> element, something which is often practical compared with manually adding a wrapper as an afterthought. For contrast, the [http://www.w3.org/International/wiki/Rb#Approach_3 current HTML5 alternative] will never offer the same feasibility, since:
#*# the alternative wrapper (e.g. <code>span</code>) is not part of the format, and thus ''one would have to manually add it'' (for a contrast, when the editor [http://www.oxygenxml.com/ oXygen] inserts the ruby element in an XHTML 1.1. document, then the <code>rb</code> element gets automatically added so that the author can start to type inside it, much like many editors, when inserting a <code>dl</code> or a <code>table</code>, also inserts the required children elements);
#*# when deleting (with a browser based WYSIWYG tool) the content of a non-native wrapper, the wrapper itself will often be deleted too (this in order to prevent littering the code with stray, empty elements — [http://xstandard.com/en/articles/wysiwyg-editors-and-bad-markup/ XStandard does this, see the heading “Emtpy Tags”]), whereas an empty element that is part of the format itself, could just remain in the code, ready to be refilled with content.)
#* '''CSS2 selector''': the <code>rb</code> element makes a cross browser CSS2 selector (<code>rb{}</code>) that, as well — and <em>unlike e.g. <code>span{}</code> — </em> only selects ruby base text. In order to offer a similar feature without inclusion of <code>rb</code>, HTML5's editor has proposed extending the ''old and largely unimplemented'' [http://www.w3.org/TR/css3-content/#wrapping CSS3 Generated and Replaced Content Module] with, quote “[https://www.w3.org/Bugs/Public/show_bug.cgi?id=10830#c5 a pseudo-element that can style certain spans of descendants); the flip side of <code>::outside</code>]. His proposed “flip side of [http://www.w3.org/TR/css3-content/#wrapping ::outside]” does, however (according to [http://www.caniuse.com CanIuse.com]) have zero implementation. And that the editor as well questions the need to select the ruby base text at all, doesn't make this option any more credible. '''Note:''' For simple ruby, it is not uncommon (examples: [http://hiragana.jp/ one], [http://www.useragentman.com/shared/css/ruby/screen.css two] ([http://www.useragentman.com/blog/2010/10/29/cross-browser-html5-ruby-annotations-using-css/ two a])) to use <code>ruby{display:inline-table}</code> in combinatino with <code>rb{display:table-row-group; /* or similar, from CSS tables */}</code>. And it might be that removing the <code>rb</code> makes the styling less robust, but other than that, it seems to work also without <code>rb</code>
#*'''CSS2 backup styling''': HTML5 [http://dev.w3.org/html5/spec/rendering.html#phrasing-content-1 prescribes] the style rules <code>ruby{display:ruby;}rt{display:ruby-text;}</code>, which stem from the [http://www.w3.org/TR/css3-ruby/ CSS3 ruby module], but which none of the common browsers fully support yet (no, [http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1296 not even Webkit or IE], despite that they have some ruby support). Thus, if one wants it to look ruby in Opera and Firefox, then one must hack up som backup CSS that works, and a wrapper element for the ruby base text may then come in handy — even if it is not impossible to make it work without it: [http://malform.no/messages/issue-172/opera-firefox demo of styling that works in Opera + Firefox].
#* '''metadata readiness:''' A wrapper around the ruby base words makes the ruby base text ready to be ''independtly'' language tagged (<code><rb lang="*"></code>), to become ARIA “styled” (e.g. <code><rb aria-hidden="true"></code>) and to receive a HTML class-name (<code><rb class="important"></code>) ''without affecting whether <code><ruby></code>, <code><rt></code> or <code><rp></code>''.
#'''that the content model of <code>ruby</code> is changed to make it non-conforming to let <code><rt></code> occur adjacent to <code><rb></code> more than once per <code>ruby</code> element''' — for the following reasons
#*'''source order is important''':
#**The HTML5 content model breaks with the content model of XHTML1.1. by requiring that one do
#***<code><ruby><rb><span style="color:red;background:white;">W</span></rb><rt><span style="color:red;background:white;">World</span></rt><rb><span style="color:red;background:white;">W</span></rb><rt><span style="color:red;background:white;">Wide</span></rt><rb><span style="color:red;background:white;">W</span></rb><rt><span style="color:red;background:white;">Web</span></rt></ruby></code><br>
#**By contrast, XHTML 1.1 requires that one do the following, '''which''' ''as one can see,'' '''allows words and letters to be written in source order:'''
#***<code><ruby><rbc><rb><span style="color:red;background:white;">W</span></rb><rb><span style="color:red;background:white;">W</span></rb><rb><span style="color:red;background:white;">W</span></rb></rbc><rtc><rt><span style="color:red;background:white;">World</span></rt><rt><span style="color:red;background:white;">Wide</span></rt><rt><span style="color:red;background:white;">Web</span></rt></rtc></ruby></code>
#**HTML5's break from the source order found in XHTML 1.1, creates problems for every parser/reader that needs to detect words more that visually. <br>Problem examples: A user trying a find-in-page search in the browser for 'WWW' when the above code is used, will not locate the 'WWW' that the user can see. For the same reason, it creates problems in screen readers, in online translations services like Google Translate, in copy-and-paste and selections - and so on and so forth. It is even hard to author, since the user cannot type the letters/words that belong together in one chunck — the author has instead type one ruby base letter and then a ruby text letter/word etc, which is cumbersome and prone to error — it is comparable to a table model where the author has to work with cells on two rows simultaneously.
#**The content model of this change proposal, requires that the above example be written like this:
#*** <code><ruby><rb><span style="color:red;background:white;">W</span></rb><rb><span style="color:red;background:white;">W</span></rb><rb><span style="color:red;background:white;">W</span></rb><rt><span style="color:red;background:white;">World</span></rt><rt><span style="color:red;background:white;">Wide</span></rt><rt><span style="color:red;background:white;">Web</span></rt></ruby></code><br>or this (NOTE: <code>rtc</code> is not made conforming, as of yet, due to legacy parser problems):
#*** <code><ruby><rbc><rb><span style="color:red;background:white;">W</span></rb><rb><span style="color:red;background:white;">W</span></rb><rb><span style="color:red;background:white;">W</span></rb></rbc><rt><span style="color:red;background:white;">World</span></rt><rt><span style="color:red;background:white;">Wide</span></rt><rt><span style="color:red;background:white;">Web</span></rt></ruby></code>.
#'''that the <code>rbc</code> element is included as a ruby base wrapper''', for the following reaasons:
#*The rbc is very helpful when styling a ruby elemnet — it becomes <strong>almost impossible</strong> to style ruby cross browser unless it is included. And yet, it is made optional, to allow authors to “type less”
#'''that the HTML5 parser is updated to handle <code>rtc</code>''', for the following reasons:
#* currently, Gecko and Trident will auto-close any element as soon as the parser sees <code>rp</code> or <code>rt</code>. This prevents the introduction of <code>rtc</code>.
#* without <code>rtc</code>, double sided ruby is more or less impossible to achieve.

<br>
__TOC__

== Rationale ==

* The inclusion of <code>rb</code> addresses the problem that the alternative — exclusion of <code>rb</code> — encourages ad-hoc solutions with regard to marking up or styling the ruby base text.
* The inclusion or <code>rb</code> allows thought-free, direct transition to/from e.g. XHTML 1.1. and HTML5. (Thought free = automatic: The author — or the authoring tool — does not have to ponder about which element to use.)
* A dedicated wrapper element offers thought-free simplicity with regard to adding CSS, ARIA, a language tag or semantic meta data to the ruby base word — and without effects on <code><ruby></code>, <code><rt></code> or <code><rp></code>.
* The change of the content model, addresses the need words/compounds to appear as words/compounds also in the source, in order to be compatible non-visual parsing (screen readers, find-in-page, translation services etc), which over all needs to work with text that is just as logical in the source as in the display.
* The inclusion of <code>rbc</code> allows advanced ruby to be styled more simply.
* Preparing the HTML5 parser to handle <code>rtc</code>, allows the <code>rtc</code> elemetn to be introduced in HTML6, and thereby allowing double sided ruby.

== Details ==

# A set of edit instructions:
* Inside “[http://dev.w3.org/html5/spec/text-level-semantics.html Text-level semantics]”: Add a new section about the <code>rb</code> element.
* Inside “[http://dev.w3.org/html5/spec/text-level-semantics.html Text-level semantics]”: Add a new section about the <code>rbc</code> element.
* Inside “[http://dev.w3.org/html5/spec/rendering.html Rendering]”: Add a new note about the default CSS styling of rb (<code>rb{display:ruby-base}</code>)
* Inside “[http://dev.w3.org/html5/spec/rendering.html Rendering]”: Add a new note about the default CSS styling of rbc (probably <code>rb{display:ruby-base-container}</code>)
* Inside “[http://dev.w3.org/html5/spec/obsolete.html#rb Obsolete features], delete the <code>rb</code> element.
* About the HTML5 parser:
*# With the exepction of the <code>ruby</code> element itself, and the <code>rtc</code> element, let the parser auto-close the current element (be it <code>rb</code>, <code>rt</code>, <code>span</code> or whatever), when the parser sees a <code>rp</code> or a <code>rt</code> element. This is ''almost'' what Geck and Webkit currently do, with the exception that they also auto-closes <code>rtc</code>.
* As authoring requirements:
*# Say that <code>rb</code> SHOULD be manually closed by the author, in order to accommodate legacy UAs (that do not auto-close it).
*# Say that the <code>rb</code> element is optional but RECOMMENDED (for styling, ARIA, language-tagging, semantic-web purposes (RDFa and Microdata)).

== Impact ==

=== Positive Effects ===

* Offers simple transition from existing (simple) ruby mark-up to HTML5. E.g. simple to define cross-language 'microformats' that includes ruby if HTML5 and the the other language includes the same elements. And simple to make tools - and build on existing tools - that work in HTML5 as well as XHTML1.1.
* Offers simple, thought-free mark-up of ruby base text: Simple to add Language tagging, ARIA attributes, RDFa/Microdata attributes etc of the ruby base text.
* Simple, direct styling of ruby base text
* Future readiness (for advanced ruby): The <code>rb</code> is necessary in advanced ruby.
* Most authors and authoring tools will continue to use <code>rb</code> - no need to learn something new.
* Instead of forbidding <code>rb</code>, with difficult to explain reasons as justification and yet with effects on authors and authoring tools, allowing <code>rb</code> instead benefit those authors, those parsers and those authoring tools that already use/implement it, thereby avoiding to needlessly bother them.
* Authors don't have to wait for new CSS features to be invented (and deployed) before they get a CSS selector that is dedicated to styling ruby base text — and only ruby base text!
* Change of content model assures that text is meaningful both in source and in display, and thus simplifying treatment of ruby in AT, translation services, find-in-page features, spell-checkers etc
* Simpler styling and more efficient meta data tagging or ruby base, due to inclusion of <code>rbc</code> (tag one element instead of all the <code>rb</code> elements)
* Preparedness for the future, due to the change in the HTML5 parser so that it doesn't auto-close the <code>rtc</code> element.

=== Negative Effects ===

* <code>rb</code> is not well supported in all legacy HTML parsers (the Trident parser), hence authors have to be aware of the need to use helping scripts (Modernizr, HTML5shiv etc) and helping CSS in order to get good styling.
** Counter argument: For when this causes problems, authors have the option of either dropping the <code>rb</code> (if it helps) and/or adding an additional wrapper, such as <code>span</code>
** Counter argument: If — as in legacy IE versions — the <code>rb</code> renders as an empty element, then no harm happens. Effectively, it means that the ruby base text is rendered without a wrapper - equivalent to dropping the <code>rb</code>.
** Counter argument: Why would the lacking support in legacy HTML parsers be any more important to consider when it comes to <code>rb</code> compared to other, new HTML elements?
** Counter argument: Since there actually is ''some'' support of <code>rb</code> in legacy UAs (at least, it is treated as <code>span</code>), it could be argued that it is simpler to include <code>rb</code> compared to the inclusion of many ''completely new'' HTML elements in HTML5.
** IE since IE9 supports <code>rb</code> natively.
* Due to little visual feedback when <code>rb</code> is supported in contrast to when it is not supported, authors may think that <code>rb</code> works, while it in reality doesn't.
** Counter argument: This can be said about legacy parsers with regard to many new element. And since it hasn't been held against the any other, new element in HTML5, it seems unjustified to hold it against <code>rb</code>.
*Some pages that are authored accorind to the current content model, will become invalid due to this CP's requrement that no more than a single adjacent pair of <code>rb</code> and <code>rt</code> occur in the same <code>ruby</code> element.
** The benefits of fixing the page is more important thant this slight annoyance.
* Change of content model affects how one browser (Webkit) with partial support for <code>ruby</code> display the ruby
** This is true. However, the source order is so important that it is worth it.
* Use of the <code>rbc</code> element affects how one browser (Webkit) with partial support for <code>ruby</code> display the ruby
** Counter argument: This is '''not''' true. It is the change of the content model that can cause this. The inclusion <code>rbc</code> instead allows authors to style the ruby so that it looks fine also in <code>webkit</code>.
** Counter argument: Actually, in Trident, the <rbc> does no harm.

=== Conformance Classes Changes ===

* It becomes conforming to to use the <code>rb</code> element inside <code>ruby</code>
* The HTML5 parser must auto-close the <code>rb</code> element — and any ather element except <code>ruby</code> and <code>rtc</code> — when it sees <code>rt</code> or <code>rp</code>
* Until UAs offers broad support auto-closing, it becomes RECOMMENDED to manually close the <code>rb</code> element.
* The <code>rbc</code> element becomes valid
* Only a single adjacent pair of <code>rb</code> and <code>rt</code> is conforming

=== Risks ===

* If the author fails to manually close the <code>rb</code> element, then legacy UAs may place the rest of the ruby content inside the <code>rb</code> element, ''causing the mark-up to malfunction in legacy parsers''.
** ''Counter argument:'' In existing usage, the <code>rb</code> seems to almost always be closed.
** ''Counter argument:'' This is a temporal problem - UAs willl update. (Currently released versions of Gecko and Webkit plus IE10 do it.)

* Authors who do close the <code>rb</code> element, ''might think that closing the <code>rb</code> will guarantee that it works in legacy UAs''.
** ''Counter argument:'' Why? It is already well known that legacy versions of e.g. Firefox and IE do not handle unknown elements well, and that one must just various tricks in order to make new HTML5 elements work in legacy UAs.

* If authors are required to use <code>span</code> instead, then they know that <code>span</code> does not get auto-closed, whereas ''for <code>rb</code>, they have to learn that while it is intended to auto-close, it does so far not get auto-closed''.
** ''Counter argument:'' Actually, this is not true since, in Gecko, Webkit and IE10, then ''any'' element ges auto-clsoed when it see <code>rp</code> or <code>rt</code>
** ''Counter argument:'' To the degree that it is true (see above), it is a temporal problem - UAs willl update. Also: Because pre-HTML5 ruby is part of XHTML 1.1, the big bulk of legacy code ''do'' close the <code>rb</code> element, so it does not seem much of problem. This CP does however suggest that authors SHOULD close the <code>rb</code> until UAs catch up.

* To '''not''' make the <code>rb</code> element ''obligatory'' (like in XHTML 1.1), creates the ''risk that authors omits the <code>rb</code> element, just because they can, and because they think there is a benefit in doing so''.
** ''Comment: Agreed.'' I lean towards making the <code>rb</code> element obligatory, as I don't see it as particulary healthy that one can ommit the <code>rb</code> element. From my perspective, ''allowing the <code>rb</code> to be omitted, is just a compromise position'' (and I don't rule out that my argumentation in favour of includsion <code>rb</code> would have been more successful if I asked it to be obligatory). There is primarily only one benefit, namely, that it fits slightly better with the fact that IE6-8 does not by default recognize this element. But this does not seem to be much of an argument since, in a HTML5 parser, any unknown element would be handled in a defined way. Thus, while <code><rb>word<rb></code> might fail to work in an ''un-prepped'' copy of IE6/IE7/IE8 (and may be in Firefox 2), it would still nevertheless work in an HTML5 parser (as well as in e.g. IE6/7/8 browser prepped with an HTML5 helper script.
** ''Comment: Indeed.'' There would indeed be no more benefit in omitting the <code>rb</code> element, than it would be for the same author in dropping the <code>html</code>, <code>head</code> or <code>body</code> element. E.g. if the author drops the <code>html</code> element, then he/she also drops adding a language tag, semantic meta data and so on for the entire document. ''Actually,'' when dropping <code>html</code>, then the element is still auto-generated by the HTML5 parser — which means that it is readily available for scripting and styling. In contrast, when dropping the <code>rb</code> element, then there is no automatic generation of the element. Which means that when an author omits of the <code>rb</code> element, then it he also takes away the direct opportunity to apply e.g. CSS to the element. ''(Fortunately, however, by including the <code>rb</code> in HTML5, the author (or the authoring tool) has a very simple recipe for fixing such situations, though.)''

== References ==

=== Relevant tests ===

===='''rb versus span'''====

* Richard Ishida's [http://www.w3.org/International/wiki/Rb test of <code>rb</code> versus the alternatives], demonstrates that:
** for (more or less) HTML5-capable parsers (Firefox 9 and Opera 11.5, then [http://www.w3.org/International/tests/html-css/generate?format=h5&test=ruby-1020 use of <code>span</code>] '''does not work any better''' than [http://www.w3.org/International/tests/html-css/generate?format=h5&test=ruby-1021 using <code>rb</code>]: In either case, the author, if he/she wants to use ruby, must use alternative CSS styling, due to the lack of support for the [http://www.w3.org/TR/css3-ruby/ Ruby CSS module].
** for UAs that have some kind of built-in ruby support (IE, Safari/Chrome, ) then <code>span</code> and <code>rb</code> works equally well.
** if one adds the HTML5 shiv — <code><script>document.createElement("rb")</script></code> to Richard's tests (see [http://malform.no/messages/issue-172/ demo]), then <code>rb</code> works as good/bad as <code>span</code> in legacy IE version.

====''' auto-closing of the rb element'''====

*Test: [http://malform.no/messages/issue-172/rb-auto-closing auto-closing test].
*Results:
*# Parser does not recognize <code><rb></code> as an element (even if it recognizes <code><ruby></code> and <code><rt></code>): '''IE5-8'''.<br/>In IE5-8, this has two effects: a) <code>rb</code> styling does not work; b) it might make it seem as if auto-closing does work;.
*# Parser auto-closes ''any'' element ''(except <code>ruby</code> itself)'' when it sees <code><rt></code> or <code><rp></code>: '''Firefox''', '''Webkit'''
*# No auto-closing happens: '''Opera''', '''IE9''' and '''IE5-8 with HTML5 shiv''' (<code><script>document.createElement("rb");</script></code>)

=== Use cases for <code>rb</code> ===

* Uses cases for <code>rb</code> amount to documenting that there ''are'' use cases for the addition of language tags, CSS, metadata (via Microformats, Microdata or RDFa), ARIA to ruby base text. In our view, '''it does not make sense''' to ''accept'' that it has to be documented — via use cases — that ruby base text needs langauge tagging, styling, metadata or ARIA, since these are features which are generally accepted as needed ''anywhere'' on ''any element''. Nevertheless, we will mention some such examples:
** ''Language tagging:''
*** The very idea behind ruby markup is to express a translation (in the widest sense of the word) of a ruby base text in the form of a ruby (annotation) text. Often the difference between base and text is only a difference in ''script'' - thus the language is the same while the script differs. Other times, the language differs. In either case, the difference in script or language, can be expressed via language tags on either <code>rb</code> or <code>rt</code> — or on both. ''We can conclude'' that ruby mark-up (to the degree that language tagging has any relevance at all) is more frequently needed for ruby mark-up than for any other HTML construct.
*** The language is inherited from a parent element — e.g. from <code>p</code> or <code>html</code>. And since the ruby text (<code>rt</code>) is supposed to explain the ruby base (<code>rb</code>), one must conclude that it is the ruby base that most frequently will need to be language tagged. (The <code>rt</code> will just inherit the language tagging value from the parent element.) ''Without the <code>rb</code> element'', one would have to '''first''' add a language tag on the <code>ruby</code> element, and '''then''' add a language tag on the <code>rt</code> element, in order to cancel the (inherited) effect ot setting the language on the <code>ruby</code> element — quite ad hoc and impractical, in our view.
** ARIA, CSS
*** In the WebAIM forum, it was recently asked how to convey to an AT user that a Roman numeral (such as ''IV'') stood for ''4'' and was not to be read as the letters ''I'' plus ''V''. I provided [http://webaim.org/discussion/mail_message?id=19350 an answer] where one of the options was to use ruby markp. With the help of <code><rb aria-hidden="true"></code>, this was the only method that worked even in the Mac OS X screen reader (VoiceOver). In the demo code, I also added styling of the <code>rb</code> element in the form of <code>rb{text-decoration:underline}</code>, to hint to sighted users as well that hovering above this text, would provide information. Thus I was able to, by default, hide the ruby text for everyone except screen readers uers — [http://malform.no/messages/issue-172/aria.html see demo].
** CSS selectors for ruby base
*** Koji Ishii [http://dl.dropbox.com/u/8812114/ruby.htm suggests treating <code>rb</code> just like <code>tbody</code>] — thus, the selector should work, even if the author skips actually typing it. A good idea. But this proposal does however not make that proposal, as it would mean that one woudl have to change the HTML5 parser so that it autogenerates the element. No such change are on the horizon. Alternatively, one could add a pseudo selector in CSS - e.g. ruby:base{}. But no such selector is on the horizon either. ''It stands that it is necessary to be able to select the ruby base, and that simples way is to use <code>rb</code>.
** metadata (Microformats, RDFa, Microdata)
*** No examples.

__NOTOC__

ChangeProposals/presentation override

Sfaulkne — Thu, 05 Jan 2012 10:31:37 GMT

Sfaulkne: /* Summary */

ChangeProposals/notitle reality

Sfaulkne — Sun, 11 Dec 2011 15:54:11 GMT

Sfaulkne: /* title attribute definition does not match reality */

ChangeProposals/notitle captions

Sfaulkne — Sun, 11 Dec 2011 15:51:05 GMT

Sfaulkne:

[[Category:ChangeProposal]]
[[Category:Issues]]
[[Category:Accessibility]]
[[Category:Title]]

'''[http://lists.w3.org/Archives/Public/public-html/2012Mar/0731.html Change proposal Accepted by Working Group decision] Mon, 26 Mar 2012'''

= Replace poor coding example for figure containing multiple images =

The following Change Proposal is for the the HTML WG [http://www.w3.org/html/wg/tracker/issues/190 Issue 190]
Editor: Steve Faulkner (faulkner.steve@gmail.com)

Date: January 18th, 2012.

== Summary ==
The spec currently [http://dev.w3.org/html5/spec/the-figure-element.html#the-figure-element includes examples] using the title attribute to provide captions for images. This results in caption text not being available to a range of users. The required implementation in browsers to make title attribute content available to all users has not occured in over 12 years and no browser vendor has indicated a commitment to implement. Until such times that interoperable device independent support for title attribute display is on the horizon, examples in the spec should be replaced with more practical real world examples that actually work. There is no downside to removing the examples, only positives for users and authors.

__TOC__

== Rationale ==

=== Complete lack of support for recommended practice results in inaccessible content ===

The HTML5 spec currently contains an exampleof use of the title attribute to provide captions for images:
In this example, which could be part of a much larger work discussing a castle, the figure has three images in it.
<figure>
<img src="castle1423.jpeg" title="Etching. Anonymous, ca. 1423."
alt="The castle has one tower, and a tall wall around it.">
<img src="castle1858.jpeg" title="Oil-based paint on canvas. Maria Towle, 1858."
alt="The castle now has two towers and two walls.">
<img src="castle1999.jpeg" title="Film photograph. Peter Jankle, 1999."
alt="The castle lies in ruins, the original tower all that remains in one piece.">
<figcaption>The castle through the ages: 1423, 1858, and 1999 respectively.</figcaption>
</figure>

[http://dev.w3.org/html5/spec/the-figure-element.html#the-figure-element source]

The example is implicit authoring advice, independent of the specification of the figure and figcaption elements in HTML5. It '''is not''' a best practice or practical, accessible method, yet it is being used in an illustrative way without caveat. Using the title attribute in this way is an anti-pattern that hides content from keyboard and touch interface users and it advoactes the use of an ambiguous semantic container for plain text only.

'''Example:''' for users who can use a mouse the following code:

<img src="castle1999.jpeg" title="Film photograph. Peter Jankle, 1999." alt="The castle lies in ruins, the original tower all that remains in one
piece.">

results in the user having access to the title attribute text "Film photograph. Peter Jankle, 1999."

Users who are not using a mouse or are using most screen readers or using a mobile/touch device '''simply do not have access to the text or even know it is there'''.

On the contrary use of the figcaption element for captions '''provides access to captions for ALL users''' regardless of OS, input device or ability.
Browser are now starting to implement semantics for figure and figcaption.
For example in [https://bugzilla.mozilla.org/show_bug.cgi?id=658272 Firefox 11] the following semantics are exposed via accessibility APIs:

'''figure:'''
role=grouping, IA2 object attribute xml:role figure.
accessible relationship to figcaption, type=labelledby.

'''figcaption:'''
role=caption
provides accessible name for figure element.

As a consequence it is suggested that the current example containing poor markup should be replaced with an example containing markup that authors can use now and will be beneficial to a range of users.

=== Implict recommendation relies on a 12 year old HTML feature with no input device independent user agent support ===
The implementation of the title attribute in graphical browsers does not provide accessible access to its content. Content is hidden from the user by default and its display is dependendent on the type of input device a user is able to operate. There is no requirement on user agents to provide input device independent access to title attribute content, a [http://www.w3.org/Bugs/Public/show_bug.cgi?id=5807 request to make it a requirement] was rejected.

A request to browser vendors in April 2011, for information about their intentions to provide [http://lists.w3.org/Archives/Public/public-html/2011Apr/0468.html device independent access to title attribute content] has so far resulted in 4 vendors ([http://lists.w3.org/Archives/Public/public-html/2011Apr/0507.html Microsoft] and [http://lists.w3.org/Archives/Public/public-html/2011Apr/0507.html Mozilla]) indicating that they have no plans to do so:

On Wednesday, April 20, 2011 9:04 AM, David Bolter wrote:
No concrete, scheduled, plan at this time.

Adrian Bateman:
Same at Microsoft for IE.

While [http://lists.w3.org/Archives/Public/public-html/2011May/0109.html Apple] only made an equivocal statement, citing "company policy":

"Apple does not generally give specific details regarding future product plans."

Opera [http://lists.w3.org/Archives/Public/public-html/2011May/0126.html responded] with:
"As Maciej said about Apple, Opera generally doesn't make statements about
timelines for future development."

So no vendors have indicated any plans to implement device independent access to title attribute content as a feature. No user agents have implementedinput device independent support for the title attribute in the intervening 9 months or indeed in the last 12 years since specced in HTML 4.01.

=== Browsers on mobile platforms do not display title attribute content to ANY USERS===

The display of title attribute content in both browsers and OS's has decreased markedly in the last 6 years due to the increase in mobile browsers and touch interfaces.
No [http://www.quirksmode.org/mobile/browsers.html mobile browsers] are known to display title attribute content.

====suggested reasons====
* touch interfaces do not lend themselves to the 'incidental behaviour' paradigm that tooltip based disclosure of content relies upon.
* small screens do not work well with tooltips (same issue as for screen magnifier users).
* title attributes are [http://www.html5accessibility.com/tests/title-usage.html commonly misused] providing redundnant content.

=== Situations in which the the title attribute is not useful due to lack of support ===
'''Reference:''' [http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/ Using the HTML title attribute]

* Displaying information for web content viewed on mobile phone browsers. Typically in desktop browsers title attribute content is displayed as a tooltip. From what I could find, tooltip display is not supported in any mobile browser and alternative visual methods of accessing title attribute content are not provided.
* Providing information for people who cannot use a mouse. Typically in desktop browsers, title attribute content is displayed as a tooltip. Although the tooltip behaviour has been supported for 10+ years, no browser as yet has implemented a practical method to display title attribute content using the keyboard.
* Using it on most HTML elements to provide information for users of a variety of assistive technologies. Access to title attribute information is not supported uniformly by screen readers

User groups not well served by use of the title attribute

*Mobile phone users.
** title attribute content is not displayed on mobile phone browsers or touch based interfaces.
*Keyboard only users.
** keyboard users can neither access title attribute content or are aware that it is there.
*Screen magnifier users.
** The style of tooltips containing title attribute content cannot be modified by authors so that it readable by screen magnifier users. This results in in title attribute content being [http://www.paciellogroup.com/resources/articles/WE05/index.html#slide12 obscured and unreadable] if it is more than a few words long.
*Screen reader users.
** typically screen reading software only supports the announcing of title attribute content on interactive controls.
* Users with fine motor skill impairments.
** placing the mouse over a word or phrase to view a tooltip can be difficult.
* Users with cognitive impairments
** Typically tooltips only appear for a short duration < 5 seconds, some users are unable to read the text in a tooltip in such a short time.

== Details ==

Remove the following spec text from [http://dev.w3.org/html5/spec/the-figure-element.html#the-figure-element the figure element]

In this example, which could be part of a much larger work discussing a castle, the figure has three images in it.
<figure>
<img src="castle1423.jpeg" title="Etching. Anonymous, ca. 1423."
alt="The castle has one tower, and a tall wall around it.">
<img src="castle1858.jpeg" title="Oil-based paint on canvas. Maria Towle, 1858."
alt="The castle now has two towers and two walls.">
<img src="castle1999.jpeg" title="Film photograph. Peter Jankle, 1999."
alt="The castle lies in ruins, the original tower all that remains in one piece.">
<figcaption>The castle through the ages: 1423, 1858, and 1999 respectively.</figcaption>
</figure>

Replace it with:

In this example, which could be part of a much larger work discussing a castle, nested figure elements are used to provide both a group caption and
individual captions for each figure in the group.
<figure>
<figcaption>The castle through the ages: 1423, 1756, and 1966 respectively.</figcaption>
<figure>
<img src="castle-etching.jpg" alt="The castle has one tower, and a tall wall around it.">
<figcaption>Charcoal on wood. Anonymous, circa 1423.</figcaption>
</figure>
<figure>
<img src="castle-painting.jpg" alt="The castle now has two towers and two walls.">
<figcaption>Oil-based paint on canvas. Eloisa Faulkner, 1756.</figcaption>
</figure>
<figure>
<img src="castle-fluro.jpg" alt="The castle lies in ruins, the original tower all that remains in one piece.">
<figcaption>Film photograph. <span lang="fr">Séraphin Médéric Mieusement</span>,
1936.</figcaption>
</figure>
</figure>

== Impact ==

=== Positive Effects ===
The spec will provide an example of using nested figure elements, where currently it does not.

The example uses markup that adds useful semantic information not provided using the title attribute.

The removal of the title attribute antipattern for captions will mean that spec illustrates a method that is accessible to all users instead of one that is:

* not available to keyboard only users
* typically not available to AT users
* difficult to access for users with fine motor skill impairments
* not available to users of touch and mobile devices

The change would also be more in line with the [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies HTML design principle]:

3.2. Priority of Constituencies
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the
user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more
weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of
course, it is preferred to make things better for multiple constituencies at once.

As it puts users and authors before specifiers or theoretical purity.

=== Conformance Classes Changes ===

none

=== Negative effects ===

If at some point in the future, the markup method omitted actually becomes usable in an accessible way, the spec will not reflect this. This is mitigated by the fact that if this situation does arise, the method can be easily added to a future iteration of HTML.
Authors

Authors will be encouraged to use more verbose markup for providing captions for images.

ChangeProposals/notitle annotations

Sfaulkne — Sun, 11 Dec 2011 15:47:18 GMT

Sfaulkne:

[[Category:ChangeProposal]]
[[Category:Issues]]
[[Category:Issue182]]
[[Category:Accessibility]]
[[Category:Title]]

'''[http://lists.w3.org/Archives/Public/public-html/2012Mar/0555.html Change proposal Accepted by Working Group decision] Tue, 20 Mar 2012'''

= Advice in spec about annotations promotes inaccessible content =

The following Change Proposal is for the the HTML WG [http://www.w3.org/html/wg/tracker/issues/182 Issue 182]
Editor: Steve Faulkner (faulkner.steve@gmail.com)

Date: January 13th, 2012.

== Summary ==
The section 4.13.5 Footnotes http://dev.w3.org/html5/spec/Overview.html#footnotes of the HTML5 specification '''recommends''' the use of a markup antipattern that makes it impossible for some user groups and very difficult for some other user groups to know of the presence or access footnote content. It advocates the use of the title attribute, yet historically and currently title attribute content is not available to a range of users. there is no indication from implementors that this is likely to change.

__TOC__

== Rationale ==

=== Complete lack of support for recommended practice results in inaccessible content ===

The HTML5 spec currently '''recommends''' to HTML developers to use the title attribute as a method to mark up short footnotes:

HTML does not have a dedicated mechanism for marking up footnotes. Here are the '''recommended''' alternatives.
For short inline annotations, the title attribute should be used.
[http://dev.w3.org/html5/spec/Overview.html#footnotes source]

It is authoring advice, independent of the specification of the title attribute in HTML5. It is not provided to illustrate the use of the title attribute as specified in HTML5. It '''is not''' a best practice or practical, accessible method, yet it is being recommeded without caveat.

'''Example:''' for users who can use a mouse the following code:

<span title="Colloquial pronunciation of 'What do you'">Watcha</span>

results in the user having access to the text "Watcha" and the title attribute text "Colloquial proninciation of 'What do you'"

For users who are not using a mouse or are using a screen reader or using a mobile/touch device all they get is "Watcha".

=== Recommendation relies on a 12 year old HTML feature with no input device independent user agent support ===
The implementation of the title attribute in graphical browsers does not provide accessible access to its content. Content is hidden from the user by default and its display is dependendent on the type of input device a user is able to operate. There is no requirement on user agents to provide input device independent access to title attribute content, a [http://www.w3.org/Bugs/Public/show_bug.cgi?id=5807 request to make it a requirement] was rejected.

A request to browser vendors in April 2011, for information about their intentions to provide [http://lists.w3.org/Archives/Public/public-html/2011Apr/0468.html device independent access to title attribute content] has so far resulted in 4 vendors ([http://lists.w3.org/Archives/Public/public-html/2011Apr/0507.html Microsoft] and [http://lists.w3.org/Archives/Public/public-html/2011Apr/0507.html Mozilla]) indicating that they have no plans to do so:

On Wednesday, April 20, 2011 9:04 AM, David Bolter wrote:
No concrete, scheduled, plan at this time.

Adrian Bateman:
Same at Microsoft for IE.

While [http://lists.w3.org/Archives/Public/public-html/2011May/0109.html Apple] only made an equivocal statement, citing "company policy":

"Apple does not generally give specific details regarding future product plans."

Opera [http://lists.w3.org/Archives/Public/public-html/2011May/0126.html responded] with:
"As Maciej said about Apple, Opera generally doesn't make statements about
timelines for future development."

So no vendors have indicated any plans to implement device independent access to title attribute content as a feature. No user agents have implementedinput device independent support for the title attribute in the intervening 9 months or indeed in the last 12 years since specced in HTML 4.01.

=== Browsers on mobile platforms do not display title attribute content to ANY USERS===

The display of title attribute content in both browsers and OS's has decreased markedly in the last 6 years due to the increase in mobile browsers and touch interfaces.
No [http://www.quirksmode.org/mobile/browsers.html mobile browsers] are known to display title attribute content.

====suggested reasons====
* touch interfaces do not lend themselves to the 'incidental behaviour' paradigm that tooltip based disclosure of content relies upon.
* small screens do not work well with tooltips (same issue as for screen magnifier users).
* title attributes are [http://www.html5accessibility.com/tests/title-usage.html commonly misused] providing redundnant content.

=== Situations in which the the title attribute is not useful due to lack of support ===
'''Reference:''' [http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/ Using the HTML title attribute]

* Displaying information for web content viewed on mobile phone browsers. Typically in desktop browsers title attribute content is displayed as a tooltip. From what I could find, tooltip display is not supported in any mobile browser and alternative visual methods of accessing title attribute content are not provided.
* Providing information for people who cannot use a mouse. Typically in desktop browsers, title attribute content is displayed as a tooltip. Although the tooltip behaviour has been supported for 10+ years, no browser as yet has implemented a practical method to display title attribute content using the keyboard.
* Using it on most HTML elements to provide information for users of a variety of assistive technologies. Access to title attribute information is not supported uniformly by screen readers

User groups not well served by use of the title attribute

*Mobile phone users.
** title attribute content is not displayed on mobile phone browsers or touch based interfaces.
*Keyboard only users.
** keyboard users can neither access title attribute content or are aware that it is there.
*Screen magnifier users.
** The style of tooltips containing title attribute content cannot be modified by authors so that it readable by screen magnifier users. This results in in title attribute content being [http://www.paciellogroup.com/resources/articles/WE05/index.html#slide12 obscured and unreadable] if it is more than a few words long.
*Screen reader users.
** typically screen reading software only supports the announcing of title attribute content on interactive controls.
* Users with fine motor skill impairments.
** placing the mouse over a word or phrase to view a tooltip can be difficult.
* Users with cognitive impairments
** Typically tooltips only appear for a short duration < 5 seconds, some users are unable to read the text in a tooltip in such a short time.

== Details ==

Remove the following spec text from [http://dev.w3.org/html5/spec/Overview.html#footnotes 4.13.5 Footnotes]

"For short inline annotations, the title attribute should be used.

In this example, two parts of a dialogue are annotated with footnote-like content using the title attribute.

<p> <b>Customer</b>: Hello! I wish to register a complaint. Hello. Miss?
<p> <b>Shopkeeper</b>: <span title="Colloquial pronunciation of 'What do you'">Watcha</span> mean, miss?
<p> <b>Customer</b>: Uh, I'm sorry, I have a cold. I wish to make a complaint.
<p> <b>Shopkeeper</b>: Sorry, <span title="This is, of course, a lie.">we're
closing for lunch</span>."

Modify the following spec text from [http://dev.w3.org/html5/spec/Overview.html#footnotes 4.13.5 Footnotes] by removing the word "longer":

For longer annotations, the a element should be used, pointing to an element later in the document

== Impact ==

=== Positive Effects ===

The removal of the title attribute antipattern for footnotes will mean that spec recommends a method that is accessible to all users instead of one that is:

* not available to keyboard only users
* typically not available to AT users
* difficult to access for users with fine motor skill impairments
* not available to users of touch and mobile devices

The change would also be more in line with the [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies HTML design principle]:

3.2. Priority of Constituencies
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the
user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more
weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of
course, it is preferred to make things better for multiple constituencies at once.

As it puts users and authors before specifiers or theoretical purity.

=== Conformance Classes Changes ===

none

=== Risks ===

If at some point in the future, the markup method omitted actually becomes usable in an accessible way, the spec will not reflect this. This is mitigated by the fact that if this situation does arise, the method can be easily added to a future iteration of HTML.

ChangeProposals/hSub2

Tinkster — Thu, 10 Nov 2011 20:19:13 GMT

Tinkster: /* Examples */

ChangeProposals/OutlineMask

Sfaulkne — Mon, 07 Nov 2011 11:20:08 GMT

Sfaulkne: /* specification text to add */

Change Proposal

Replace <code><nowiki><hgroup></nowiki></code> with an attribute <code><nowiki>outlineMask</nowiki></code> that simply flags that a heading should not be included in the document outline when producing an outline using the outline algorithm.

==Rationale==
* The <code><nowiki><hgroup></nowiki></code> element has no uniquely useful function other than to remove a heading from the outline generated using the outline algorithm.
* It does not codify an existing usage pattern on the web. The creator of <code><nowiki><hgroup></nowiki></code> [http://www.w3.org/Bugs/Public/show_bug.cgi?id=11828#c2 describes it thus]:

<code><nowiki><hgroup></nowiki></code> is in fact the result of awaiting patterns. The pattern is that people
use <code><nowiki><h1></nowiki></code> and <code><nowiki><h2></nowiki></code> as heading and subheading respectively (without meaning
heading and subsection). '''All <code><nowiki><hgroup></nowiki></code> does is wrap them up so they don't impact the outline algorithm.'''

* Problem being with the statement "The pattern is that people use <code><nowiki><h1></nowiki></code> and <code><nowiki><h2</nowiki></code> as heading and subheading respectively (without meaning heading and subsection)" is that it is not a pattern that prevails over the other [http://wiki.whatwg.org/wiki/Hgroup_element patterns that people use] to mark up headings and subtitles. No cow paths are being paved with the addition of the <code><nowiki><hgroup></nowiki></code>, in fact it is the opposite, it is an attempt to force a pattern upon the markup where none previously existed, simply to support the newly created outline algorithm.

* The <code><nowiki>outlineMask</nowiki></code> attribute does not suffer from the issues ineherent with the introduction of the <code><nowiki><hgroup></nowiki></code> as it simply does the same thing as the [http://wiki.whatwg.org/wiki/Rationale#hgroup_and_other_heading_elements only rationale] provided for the inclusion of <code><nowiki><hgroup></nowiki></code> in HTML5:
The point of <hgroup> is to hide the subtitle from the outlining algorithm.

===implementations of hgroup===
* zero implementations of the semantics, only implementations of default style. hgroup conveys no meaning to any user.
* No browser has implemented the outline algorithm to display document outlines or change the semantics of H1 to H6 elements based on the outline algorithm.
* No browser has implemented the effect of the hgroup element on the document outline (i.e. masking the subheading as defined in [http://dev.w3.org/html5/spec/the-hgroup-element.html#the-hgroup-element HTML5 section 4.4.7] or the in document effect i.e. to remove the heading level semantics of the individual heading elements within a hgroup element and assign the heading level semantics of the top level heading element within hgroup to the hgroup element as defined in [http://dev.w3.org/html5/spec/wai-aria.html#wai-aria HTML5 section 3.2.7].
* One assistive technology (JAWS) has implemented the outline algorithm, it effects the representation of heading levels for page content. JAWS has not implemented the effect of hgroup on the outline or in page. From a recent discussion with a vendor working with freedom scientific (maker of JAWS) to implement HTML5 features, there are no plans to implement hgroup.

==Details==
* Remove the <code><nowiki><hgroup></nowiki></code> element from HTML5, remove the 52 instances of the text "hgroup" in the HTML5 specification.
* Add details about <code><nowiki><hgroup></nowiki></code> under [http://dev.w3.org/html5/spec/obsolete.html#non-conforming-features 11.2 Non-conforming features]
hgroup - Use outlinemask instead.
* add references to outline mask where appropriate in the spec.
* remove <code><nowiki><hgroup></nowiki></code> from the ARIA role mapping table.
* Further editorial details of additions and deletions to the spec can be provided, if the change proposal is accepted.

===specification text to add===

The <code>outlinemask</code> attribute

The <code><nowiki><h1></nowiki></code> to <code><nowiki><h6></nowiki></code> elements may have the <code>outlinemask</code> content attribute set.
The <code>outlinemask</code> attribute is a boolean attribute.
When specified on one or more <code><nowiki><h1></nowiki></code> to <code><nowiki><h6></nowiki></code> elements,it indicates that the element is not
to be included in the document outline.
User agents should not include the <code><nowiki><h1></nowiki></code> to <code><nowiki><h6></nowiki></code> elements or their content in
the document outline if the <code>outlinemask</code> attribute is specified.

The <code>outlinemask</code> IDL attribute must reflect the content attribute of the same name.

The ARIA role mapping for a <code><nowiki><h1></nowiki></code> to <code><nowiki><h6></nowiki></code> that has
an <code>outlineMask</code> attribute is the same as a <code><nowiki><h1></nowiki></code> to <code><nowiki><h6></nowiki></code>
without an <code>outlineMask</code> attribute set. User agents MAY provide an indication that a heading is a subheading when
the attribute is set.

'''Examples of outlinemask use:'''

<pre>
<body>
<h1>Title</h1>
<h2 outlinemask>Subtitle</h2>

<h1>Second Title</h1>
<div>
<h2 outlinemask>Second Subtitle 1</h2>
<h2 outlinemask>Second Subtitle 2</h2>
</div>
</body>
</pre>
<pre>
<article>
<h2 outlinemask>The Magical</h2>
<h1>Title</h1>
<h2 outlinemask>That Has</h2>
<h2 outlinemask>Multiple Subtitles</h2>
</article>
</pre>
<pre>
<section>
<h2 oultinemask>Preceeding subtitle</h2>
<h1>Title</h1>
</section>
</pre>

==Risks==

* Removal of the <code><nowiki><hgroup></nowiki></code> element.

* Legacy UAs will ignore the <code><nowiki>outlineMask</nowiki></code> attribute. This is not a big problem, as no legacy user agents support the semantic processing of <code><nowiki><hgroup></nowiki></code>.

* authors may misuse the <code><nowiki>outlineMask</nowiki></code> attribute

==Positive effects==
* authors will be provided with a simple mechanism for identifying subheadings and subtitles for which they wish to use h1-h6 markup on, but do not want included in the document outline.
* implementation issues are minimal, as no user agents have yet implemented hgroup effect on the outline or semantics.
* authors will not need to chnage their current markup patterns, just add an attribute where appropriate.

ChangeProposals/hSub

Klesinsk — Sun, 06 Nov 2011 23:11:27 GMT

Klesinsk: /* Rationale */

Change Proposal

Replace <code><nowiki><hgroup></nowiki></code> with an element that has a simple content model and backwards compatibility.

==Rationale==

* <code><nowiki><hgroup></nowiki></code> overloads meaning of <code><nowiki><h1-h6></nowiki></code>, making them either headings included in document outline '''or not''', depending on context created by hgroup and other headings. No other element in HTML creates such ambiguous context-dependent meaning.

* Name and usage of <code><nowiki><hgroup></nowiki></code> can be confused with <code><nowiki><header></nowiki></code>, since both appear in headers and group elements.

* [http://wiki.whatwg.org/wiki/Hgroup_element#Real_World_Examples Existing content] on the web does not use as complex multi-level subheadings as <code><nowiki><hgroup></nowiki></code> was intended to support. All use-cases collected in the WHATWG Wiki are limited to a title followed by a subtitle that can be marked up easily with <code><nowiki><hsub></nowiki></code> (and not all collected examples can be marked up with <code><nowiki><hgroup></nowiki></code>).

* Most popular HTML5 tutorials — MDN, HTML5 Doctor and W3Schools — as well as the HTML5 spec itself only show examples of a single title followed by a single subtitle. This can be interpreted as an indicator of lack of demand for more complex markup from HTML students and/or tutors and lack of common/popular use-cases for complex markup.

* The HTML5 spec does not define any interpretation of rank of subheadings other than highest-ranked, i.e. <code><nowiki><h1/><h2/><h2/></nowiki></code> and <code><nowiki><h1/><h4/><h6/></nowiki></code> are equivalent from the spec point of view. Rank of non-highest-ranked subheadings doesn't affect outline algorithm nor assistive technology, and thus change to <code><nowiki><hsub></nowiki></code> would not lose any semantics.

* <code><nowiki><hgroup></nowiki></code>'s content model disallows adding extra <code><nowiki><div></nowiki></code>s around multiple subheadings, which may be needed as styling hooks. A real-world example :

<pre>
<nowiki>
<div id="storyheader">
<div class="headline">
<h1>Cooking Solo Grows Up</h1>
</div>
<div class="clear"> </div>
<div class="subheadline">
<h2>On your own? You no longer have to put up with cereal over the sink or days of the same old leftovers. Joe Yonan shows us why</h2>
</div>
<div class="clear"> </div>
<div class="byline">
<span class="name">By Gwendolyn Richards, Calgary Herald</span>
<span class="timestamp">May 8, 2011 2:06 AM</span>
<span id="lblComment" class="comments"></span>
</div>
<div class="clear"> </div>
</div>
</nowiki>
</pre>

This code can be trivially changed to use <code><nowiki><hsub></nowiki></code> by replacing <code><nowiki><h2></nowiki></code>, but would require significant refactoring of markup and associated styles to remove three <code><nowiki><div></nowiki></code> elements surrounding headline and subheadline forbidden by <nowiki><hgroup></nowiki>'s content model.

* Mistakes in usage of <code><hsub></code> cannot break document outline, which is a significant improvement over <code><nowiki><hgroup></nowiki></code>.

At worst, in a rather rare case of subtitle preceeding the title, subtitle may end up associated with an earlier heading:

<pre>
<h1>Unrelated title</h1>
<p>Content</p>

<hsub>Preceeding subtitle</hsub>
<h1>Title</h1>
</pre>

However, this kind of mistake can be easily eliminated by use of <section>/<acticle> elements:

<pre>
<section>
<hsub>Preceeding subtitle</hsub>
<h1>Title</h1>
</section>
</pre>

==Details==

===Replacement of section 4.4.7 (hgroup)===

Categories:
*Flow content.
*Heading content.
*Palpable content.

Contexts in which this element can be used:
*Where flow content is expected.

Content model:
*Phrasing content.

Content attributes:
*Global attributes

DOM interface:
IDL interface HTMLHeadingElement : HTMLElement {};

<code><hsub></code> element represents a subheading (tagline, subtitle) of a section. The section on headings and sections [4.4.11] defines how <code><nowiki><h1-h6></nowiki></code> elements are assigned to individual sections. <code><hsub></code> does not imply new sections.

<code><hsub></code> may only be used in sections that have a heading.

====Examples====
<pre>
<body>
<h1>Dr. Strangelove</h1>
<hsub>Or: How I Learned to Stop Worrying and Love the Bomb</hsub>
</pre>

How a user agent exposes such multi-level headings in user interfaces (e.g. in tables of contents or search results) is left open to implementors, as it is a user interface issue. The first example above could be rendered as:

The reality dysfunction: Space is not the only void

Alternatively, it could look like this:
The reality dysfunction (Space is not the only void)

In interfaces where a title can be rendered on multiple lines, it could be rendered as follows, maybe with the first line in a bigger font size:
The reality dysfunction
Space is not the only void

<pre>
<article>
<hsub>The Magical</hsub>
<h1>Change Proposal</h1>
<hsub>That Has</hsub>
<hsub>Multiple Subtitles</hsub>
</article>
</pre>

===4.4.11 (Headings and sections)===

Add:

hsub elements in an element of sectioning content represent subheadings for that section. hsub elements following a heading that implied a section represent subheadings for that section.

Change:

These elements can have their own outlines, but the sections and headings inside these elements do not contribute to the outlines of their ancestors.

to:

These elements can have their own outlines, but the sections, headings and subheadings inside these elements do not contribute to the outlines of their ancestors.

===4.4.11.1 Creating an outline===

Add:

When entering a subheading content element
- associate the subheading with ''current section''

===Subsections of section 14===
Replace hgroup with hsub. Add in 14.3.7:

hsub {font-weight:bold;}

===Other sections===
Remove references to hgroup.

==Impact==

* Removal of complexity in outline algorithm introduced by hgroup. Without hgroup only h1-h6 are headings and are always headings. There is no need to look ahead and scan hgroup content to compute its rank.

* Availability of shorter and simpler to use markup for subheadings.

* Ability to mark up subheadings in a manner backwards-compatibile with pre-HTML5 outlining and AT tools.

* Simpler and less restrictive markup, name less similar to header, and the fact that hsub does not imply new sections may reduce number of authoring errors and reduce severity of errors made compared to hgroup.

===Risks===

* Removal of the <code><nowiki><hgroup></nowiki></code> element. This is low risk, as existing browsers haven't fully implemented hgroup yet (WebKit only recognizes it as a block element, doesn't change outline: https://bugs.webkit.org/show_bug.cgi?id=33369, Gecko bug is still "NEW" https://bugzilla.mozilla.org/show_bug.cgi?id=702594).

* Legacy UAs will render the <code><nowiki><hsub></nowiki></code> element inline. This won't be a problem in practice, as it usually will be between block-level headings and paragraphs. Rendering can be easily corrected with CSS.

* Default rendering with an appropriate font size dependent on <code><nowiki><section|article></nowiki></code> nesting requires special outline-aware CSS selector. The <code><nowiki><h1></nowiki></code> element suffers from the same problem, so if default <code><nowiki><h1></nowiki></code> size is fixed, <code><nowiki><hsub></nowiki></code> will be too. Proposed rendering in bold 1em font may be satisfactory.

TPAC2011

Plehegar — Thu, 03 Nov 2011 17:18:14 GMT

Plehegar: /* Agenda */

= HTML WG face-to-face TPAC 2011 =

== Agenda ==

=== Day 1 ===

* 09:00-10:00: Organization
* 10:00-11:00: Canvas Accessibility
* 11:00-11:30: -- Break --
* 11:30-12:30: the <time> element
* 12:30-13:30: -- Lunch --
* 13-30-15:00: Web and TV
* 15:00-15:30: -- Break --
* 15:30-17:00: WG Status
** HTML Last Week
** WG reporting and organization
** Change Proposal status
** Schedule status
** Decision policy report
** Test suite report

Minutes: [http://www.w3.org/2011/11/03-html-wg-minutes.html HTML WG f2f -- 03 Nov 2011]

=== Day 2 ===

* 9:00-11:00: Issues
** longdesc
** hgroup
** dialog
** URI/IRI
* 11:00-11:30: break
* 11:30-12:00: HTML Document license
* 12:00-13:00: HTML.next
* 13:00-14:00: lunch
* 14:00-16:00 or later: Testing HTML
* 16:00 or earlier-17:00: HTML to AAPI working session

Minutes: [http://www.w3.org/2011/11/04-html-wg-minutes.html HTML WG f2f -- 04 Nov 2011]

TPAC 2011 Agenda

Myakura2 — Thu, 03 Nov 2011 17:04:34 GMT

Myakura2:

Moved!: http://www.w3.org/html/wg/wiki/TPAC2011

ChangeProposals/issue-179 no change

Spfeiffe — Wed, 26 Oct 2011 11:43:27 GMT

Spfeiffe: added the data element

== Issue-179: Counter Change Proposal for No Change ==

This counter change proposal refers to:

* Issue: http://www.w3.org/html/wg/tracker/issues/179
* Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333
* Change Proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/av_param

=== Summary ===

Issue 179 asks for introduction of a child param element for the audio and video elements to allow the page author to specify arbitrary parameters to the user agent for transporting, decoding, rendering, and controlling the audio or video content.

The [[ChangeProposals/av_param|av_param change proposal]] argues that such param elements are known from the object element and are required to allow providing equivalent functionality to the audio and video elements.

This counter change proposal argues that the requirements of the av_param change proposal can already be satisfied with existing HTML features and that no change is necessary. It further argues that the introduction of a param element would require a fundamental change to the way in which audio and video elements are supported in browsers that is not justified by the given use cases.

=== Rationale ===

Issue 179 asks for a standardized mechanism by means of which various arbitrary parameters may be communicated to the user agent.

==== Use Cases ====

Any introduction of new attributes or elements requires demonstration of good use cases.

The av_param change proposal lists the following use case as an argument to support the need for a param element:

<blockquote>
An important use case for such feature is manifested when using audio|video
elements to refer to content sourced within a UPnP ecosystem. In the
usage scenarios employed therein, a ContentDirectoryService (CDS) exposes two
important pieces of information for audio|video content items:

# a URL that references the content on a server;
# an arbitrary list of {name,value} parameters encoded in the fourth field of what UPnP refers to as a 'ProtocolInfo' data structure;
</blockquote>

Here is how these are satisfied nowadays:

<ol>
<li>A URL that references the content on a server is provided by the Web developer to HTML audio or video elements through the @src attribute, either directly on the audio or video file, or through the source element. It is also possible to change this dynamically with @src using JavaScript.
<li>The value of the "protocolInfo" data structure of the UPnP protocol are described in [http://www.upnp.org/specs/av/UPnP-av-ContentDirectory-v1-Service.pdf] and exemplified in [http://msdn.microsoft.com/en-us/library/windows/desktop/aa468340.aspx] is given in four parts as *:*:*:* as follows:
*the protocol for exporting the resource, e.g. http-get, rtsp, rtsp-rtp-udp
* the network (this is usually "*")
* the MIME-type of the resource, e.g. audio/m3u, audio/x-ms-wma, image/jpeg, video/mpeg, audio/mpeg, audio
* additional information (this is usually "*"), e.g. DLNA.ORG_PN=MP3, MICROSOFT.COM_PN=WMALSL, DLNA.ORG_PN=MPEG_PS_NTSC
with the purpose of checking the compatibility between server and renderer devices for this resource.
</ol>

The protocol in use in an audio or video element is given through the URL.

The network is the Internet.

If the MIME type needs to be specified explicitly, this can be done through the source element and the @type attribute.

It seems that much of the information that is provided in the additional information field is information that can be extracted directly from the media resource's header fields which is where decoding-specific information resides, and thus does not require additional fields.

However, assuming additional information needs to be specified, this can be provided through one of the [http://dev.w3.org/html5/spec/Overview.html#extensibility existing extensibility mechanisms of HTML]:
* data-* attributes allow providing information that is only required for a particular Web page.
* new attributes can be experimented with as x-* attributes and eventually be standardized for use cases that require a standard piece of information to be communicated. The latter seems particularly appropriate given the structure of the additional information field, e.g. x-upnp-dlna="MP3", x-upnp-microsoft="WMALSL", x-upnp-dlna="MPEG_PS_NTSC".
* new document content can be specified by [http://dev.w3.org/html5/spec/infrastructure#other-applicable-specifications "extensions specifications"]. This means that in a situation where a different standardisation organisation wants to define an extension such as a param element, they may just go forward with it, may even make it non-conforming, and may specify their own conformance terminology without the W3C HTML specification requiring any change.
* the new [http://dev.w3.org/html5/spec/text-level-semantics#the-data-element data element] may possibly also satisfy the need, even though at this stage it is unclear whether it can be used as a child of the video element.

==== Principle Approach ====

The Details section in the av_param change proposal suggests that:

<blockquote>The param element defines parameters for media components or plugins invoked by audio, video, or object elements.</blockquote>

Since the audio and video element provide native support for audio and video resource playback in browsers, there is no assumption about how browsers implement media resource parsing, in particular there is no requirement for a plugin framework or a component interface in the HTML specification. Therefore, there is no defined means of propagating parameters from the Web page to the media pipeline. Only parameters and elements that browsers understand can have an effect.

Therefore, the introduction of a generic parameter communication mechanism is not possible without changing the principle by which the audio and video element are defined. It would require introduction of a plugin framework requirement for media elements.

=== Impact ===

==== Positive Effects ====

To be fully consistent, a param element would need to be introduced as a child not just to audio and video, but also to the source element. This would break existing implementation of the source element, which is currently an empty element. Thus, not introducing it will ensure that existing browser implementations continue to work.

Introducing a param element for communicating any arbitrary information to a media decoding and rendering pipeline can be a breaker of accessibility functionality, since information is passed through the standardized markup layer transparently and deal with away from where browser accessibility APIs have access. Thus, not introducing it will ensure that any such semantic information requires creation of standardised markup and is thus able to be made accessible.

Not following the av_param change proposal will make sure that the HTML specification stays clean of a new extensibility mechanism on the audio and video element that will only be usable by a limited subset of browsers, namely one that uses a plugin architecture for implementing media element support.

Not following the av_param change proposal will ensure that existing extensibility mechanisms will continue to be used for the use cases identified by the av_param change proposal. This in turn will ensure that new use cases for the media elements are properly addressed and result in new standardised attributes and elements in the HTML specification rather than result in special-purpose and incompatible specification branches.

==== Negative Effects ====

None.

==== Conformance Class Changes ====

No changes.

==== Risks ====

None.

ChangeProposals/av param

Gadams — Wed, 26 Oct 2011 10:30:06 GMT

Gadams: /* Rationale */

= Change Proposal =

== Summary ==

The <code>audio</code> and <code>video</code> elements fail to provide a standards compliant
mechanism to specify arbitrary parameters that may be used by the user
agent to fetch, decode, and present the referenced media resource. In
contrast, the <code>object</code> element does provide such a mechanism, the <code>param</code>
element. This issue requests that the <code>param</code> element be permitted as a
child for both <code>audio</code> and <code>video</code> elements in order to provide equivalent
functionality to that afforded to implementations in prior versions of HTML.

__TOC__

== Rationale ==

As currently defined, the audio|video elements do not define a mechanism to
permit the content author to specify arbitrary parameters to the user agent to
be used in transporting, decoding, rendering, and controlling the audio|video
content. Prior to HTML5, this was accomplished using the object element while
specifying such parameters using the param element child of object.

In order to maintain continuity and support for such pre-existing usage and to
permit migration from object to the new audio|video elements, the audio|video
elements should similarly support a standardized mechanism by means of which
various arbitrary parameters may be communicated to the user agent.

An important use case for such feature is manifested when using audio|video
elements to refer to content sourced within a UPnP ecosystem. In the
usage scenarios employed therein, a ContentDirectoryService (CDS) exposes two
important pieces of information for audio|video content items:

# a URL that references the content on a server;
# an arbitrary list of {name,value} parameters encoded in the fourth field of what UPnP refers to as a 'ProtocolInfo' data structure;

In order for an HTML5 user agent to dereference and effect transport, decoding,
playback, and control of such audio|video content, it is necessary to supply
both the URL and this arbitrary set of parameters to the user agent, wherein
the user agent itself semantically interprets those parameters that it
recognizes, while ignoring those it does not recognize.

Due to the arbitrary nature of this parameter set, it is not possible to a
priori define specific attributes to carry the individual parameters
communicated in this fashion; therefore, a standardized parameter mechanism,
such as pre-exists on the object element, should also be supported on
audio|video elements.

Furthermore, the <code>data-*</code> attribute mechanism or a non-standardized use of vendor
specific <code>x-*</code> attributes are not appropriate, since the former is prohibited
from being interpreted by the user agent, and the latter impedes
interoperability and goals of standardization.
Regarding the <code>data-*</code> attribute mechanism, HTML5 specifically prohibits
interpretation by the user agent
[http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data-with-the-data-attributes]:

<blockquote>
User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.
</blockquote>

and also

<blockquote>
These attributes are not intended for use by software that is independent of the site that uses the attributes.
</blockquote>

In the usage scenarios addressed by this issue, the media component, i.e., the implementation of the audio or video
media codec and renderer in the User Agent, would directly support the interpretation of specific param name and value pairs,
and would do so in a manner independently from the site specifying the parameters.
It is expected that support for specific parameters by a class of user agents would be specified or documented
in other specifications outside the context of the HTML5 specification.

Finally, the object element itself cannot be used in this case, merely to
obtain the use of its param children, without abandoning the new, desirable
features supported by the audio|video elements, such as timed text tracks,
media controllers, playback and seek semantics, and so forth.

It is therefore requested that the param element be supported as a child of the
audio|video elements in a fashion identical to the existing support for param
on the object element.

== Details ==

==== In [http://dev.w3.org/html5/spec/Overview.html#the-param-element 4.8.5 (param)] ====

Change '''Contexts in which this element can be used''' to read
as follows:

<blockquote>
As a child of an <ins>audio, video, or</ins> object element, before any flow content.
</blockquote>

also in the subsequent prose, make the following changes:

<blockquote>
The param element defines parameters for <ins>media components or</ins> plugins invoked by
<ins>audio, video, or</ins> object elements. It does not represent anything on its own.
</blockquote>

<p></p>

<blockquote>
If both attributes are present, and if the parent element of the param is an
<ins>audio, video, or</ins> object element, then the element defines a parameter with the
given name-value pair.
</blockquote>

<p></p>

<blockquote>
If either the name or value of a parameter defined by a param element that is
the child of an <ins>audio, video, or</ins> object element that represents an instantiated
<ins>media component or</ins> plugin changes, and if that <ins>media component or</ins> plugin is
communicating with the user agent using an API that features the ability to
update the <ins>media component or</ins> plugin when the name or value of a parameter so
changes, then the user agent must appropriately exercise that ability to notify
the <ins>media component or</ins> plugin of the change.
</blockquote>

==== In [http://dev.w3.org/html5/spec/Overview.html#the-video-element 4.8.6 (video)] ====

Change '''Content Model''' to read as follows:

<blockquote>
If the element has a src attribute: <ins>zero or more param elements, then</ins> zero or
more track elements, then transparent, but with no media element descendants.
If the element does not have a src attribute: <ins>zero or more param elements, then</ins>
zero or more source elements, then zero or more track elements, then
transparent, but with no media element descendants.
</blockquote>

==== In [http://dev.w3.org/html5/spec/Overview.html#the-audio-element 4.8.7 (audio)] ====

Change '''Content Model''' to read as follows:

<blockquote>
If the element has a src attribute: <ins>zero or more param elements, then</ins> zero or
more track elements, then transparent, but with no media element descendants.
If the element does not have a src attribute: <ins>zero or more param elements, then</ins>
zero or more source elements, then zero or more track elements, then
transparent, but with no media element descendants.
</blockquote>

== Impact ==

=== Positive Effects ===

# provides continuity for the use of video/audio content when migrating from the object element as defined in HTML4
# permits use of new features of video/audio, such as accessibility features, that would not be afforded if content author is required to use the object element in HTML5 in order to express parameters;
# provides standards compliant mechanism for expressing arbitrary parameters for video and audio elements that are not yet supported by existing attributes on video and audio elements;

=== Negative Effects ===

None identified

=== Conformance Classes Changes ===

None identified

=== Risks ===

None identified

== References ==

* [http://dev.w3.org/html5/spec/Overview.html#the-object-element 4.8.4 object element]
* [http://www.upnp.org UPnP]
* [http://upnp.org/specs/av/UPnP-av-ContentDirectory-Service.pdf UPnP Content Directory Service]

__NOTOC__