Spec Review/Globals

Under review:

• Elements
• Content models

Simon Harper

The following are notes and concerns for primarily UAWG but with notes to ATWG and HTML5 if the PFWG decide they can be integrated.

3.2.3 Global attributes

• accesskey - By only allowing an accessskey for be one unicode character we remove the possibly of sequenced entry such as Alt+F S for file save. This is important in cognition (called Progressive Disclosure). There is an argument which goes 'A sequence such as Alt+F S is activating two UI elements in sequence, the File menu followed by the Save sub menu item. Although you are hitting them in sequence, and you the user may perhaps internally recall the key sequence as a combination to invoke the save action, it does not imply that the Save menu choice has an access key, or shortcut, property value of "Alt+F S". The handling of sequenced keys should be in the menu keyboard handler, not through assigning sequences to a given item.' However if we're talking Rich internet applications, I think this gets to be quite tricky, if the developer of an app is trying to maintain compatibility with the desktop UI conventions. In addition, I also think we need a Web Key (think Windows or Apple key) which give focus to accesskeys first before chrome? Myself and mhakkine have had an email discussion about this which should inform any decision titled 'HTML5 Sanity Check - before it goes to the Wiki' http://lists.w3.org/Archives/Public/w3c-wai-ua/2011AprJun/0068.html

overlaps with others

• Class - looks OK

• contenteditable - Does, contenteditable equal to true, mean that the content/UA now needs to conform to ATAG?

discuss

• contextmenu - typo 'by the invoking the'; Does the 'show' event modify the DOM (cannot find a definition) - if not how will AT 'see' contextmenu?

Michael to file bug on typo Bug 13618

discuss

• dir - looks OK

• draggable - looks OK

• dropzone - looks OK

• hidden - '— if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.'Seems to me that it should be up to the AT to decide this based on used preference. While the spec states 'should not be rendered' will it be in the DOM and if not it should be.

UAWG to discuss

• id - looks OK

• lang - looks OK

• spellcheck - looks OK

• style - looks OK

• tabindex - looks OK but 'an element that is only focusable because of its tabindex attribute will fire a click event in response to a non-mouse activation (e.g. hitting the "enter" key while the element is focused' - seems right but thoughts?

• title - 'If this attribute is omitted from an element, then it implies that the title attribute of the nearest ancestor HTML element with a title attribute set is also relevant to this element. Setting the attribute overrides this, explicitly stating that the advisory information of any ancestors is not relevant to this element. Setting the attribute to the empty string indicates that the element has no advisory information.' Do we need to say the nearest ancestor HTML element with a title attribute set is automatically used as the uaag repair default? Myself and Jim Allan have had an email discussion about this which should inform any decision, again, titled 'HTML5 Sanity Check - before it goes to the Wiki' http://lists.w3.org/Archives/Public/w3c-wai-ua/2011AprJun/0069.html

UAWG to discuss

Content Models

I find the Content Model description to be fine including 3.2.7 WAI-ARIA / however someone from PF should take a look at this just to flag anything I've missed in 3.2.7 (I'm technical but not nuanced in ARIA).

Joshue O Connor A11y Review

3.2 Elements [1]

Issue and Concerns.

While this section introduces the use of semantics and how they relate to conformance, the examples given don’t convey the negative impact incorrect or insufficient semantics can have on the user experience, in particular for users of Assistive Technology.

I suggest the following or similar spec text be added to the ‘Elements’ section to illustrate these issues and to provide a deeper sense of context and purpose behind the need to create conformant content.

This text could go in either ‘3.2.1 Semantics’ or in the following section ‘3.2.2 Elements in the DOM’.

Draft Spec text

<sample spec text>

"At all stages, in a dynamically generated or altered document the semantic integrity of the document snapshot must be maintained at each step in the document mutation – in particular where the document is in a ‘steady’ state (after a user interaction for example). These rules may be relaxed to some degree during transitional steps involve background transition or operations with other APIs but, if the document is to be a conformant HTML5 doc, then suitable elements/attributes from this spec must be used in a way that supports the documents integrity, the UA parsing requirements and above all the user experience as this can impact on the usability and accessibility of the content.

Maintaining this integrity will assist user agents such as Assistive Technologies understand and successfully interact with the DOM or other user agent structures, [ref]. This means that a dynamic widget which is semantically structured to be accessible on a page load, will when responding to user interaction/input have to maintain its semantic structure as scripting or other dynamic events are applied and the widget content/structure is altered, in order to be considered conforming html.

This example is applicable to processes such as a checking out cart, or in mashup type applications and semantic integrity will help to maintain the interoperability of application/document structures as well as facilitate a more consistent user experience. **

• • Examples of where this kind of mutation or dynamically altered content can impact on the user can be found in WCAG."

</sample spec text>

Josh to file bug for this Bug 13444

Related WCAG SC, Fails etc

• **SC 2.4.5: note wcag reference to dynamic processes [2]
• F76: Failure of Success Criterion 3.2.2 due to providing instruction material about the change of context by change of setting in a user interface element at a location that users may bypass(context change in an interface) [3]
• G13: Describing what will happen before a change to a form control that causes a change of context to occur is made. [4]

discuss, send to WCAG

3.2.5 Content models [5]

Issues and Concerns

The SVG content model VENN diagram needs to be made accessible [content-venn.svg].

• Issues – On focus the SVG diagram container is just announces as ‘Frame 0’. This is in breach of WCAG as the frame needs a suitable title that describes the diagram such as @longdesc or ARIA describedby.

Also the SVG diagram isn’t keyboard accessible, the descriptions of each of the nodes only appear on mouse over events. They should also be able to be triggered via the keyboard.

The fallback diagram ‘content-venn.png’ for where SCG is un-supported etc also needs alternate text to be applied in a way that is accessible. It currently isn’t, as the alternate text of the .png document is not announced when the diagram is parsed by Assistive Technology.

Josh to file bug with help from SVG experts Bug 13447 pinged Chaals

Device-independent Events

SVG uses the new event set provided in DOM 2 [DOM2], which supports device-independent interactive content. This allows authors of SVG to ensure that interactive content does not rely on a user having a particular type of device. Good authoring practice will normally use the focusin, focusout and activate events rather than the device specific events for gaining and losing the focus on an element or activating the element. Device-independent scripting is required by Web Content Accessibility Guidelines [WCAG10] checkpoints 9.3 and 6.4. [6]

Metadata Content/ Other notes

The description of that ‘Metadata Content’ is ‘out of band’ is rather vague. It is outlined as ‘[…] content that sets up the presentation or behavior of the rest of the content, or that sets up the relationship of the document with other documents, or that conveys other "out of band" information”. Whats does ‘out of band’ mean?

For example, this doesn’t tally with the editors stance that accessibility related semantics such as @summary is hidden ‘metadata’ or ‘out of band’. The summary attribute doesn’t come under the umbrella of ‘[..] behavior of the rest of the content, or that sets up the relationship of the document with other documents, or that conveys other "out of band" information’.

As the @summary on a complex data table can be currently easily used by users of Assistive Technology such as screen readers, and added by content authors how is this content, by inference, - ‘out of band’. It could be argued that the summary attribute relates to ‘presentation’ of content but it could equally be stated that so does the use of heading elements, list items etc but none of these elements are labeled as ‘metadata’. So there is a disconnect here and a lack of consistency about what is or isn’t ‘metadata’ and the inference that @summary is ‘out of band’.

discuss

Fallback Content [7]

The definition of what Fallback content is needs to be clearer, as well as how it varies depending on context.

For example, <object> has a fallback model via being "transparent", but <embed> lacks this there's confusion among authors about when to use <embed> and when to use <object>.

Also whether fallback content as supported by <object> is browser support fallback or accessibility alternative fallback these are two separate use cases, even though sometimes they get confused / blended as defined currently in the spec, the fallback for object is for browser support and does not address accessibility.[8]

This confusion lead the bug triage sub team us to conclude that both <embed> and <object> do not have accessibility fallback mechanisms at the moment.

This issue turns out to be represented by Bug 8885. It’s current status (as of 20/6/11 is RESOLVED NEEDSINFO)

discuss, relates to bug 8885 which needs to be revived

References

[1] [2] [3] [4] [5] [6] [7] [8]

Greg Lowney

As a general rule, when it's common for pieces of content to serve a conventional purpose, the markup should allow this purpose to be identified in an unambiguous and automation-friendly way. This allows user agents and assistive technology to make use of it to provide users with advanced navigation and customization features. HTML5 does this in many areas, many more in fact than HTML4, but there are still common purposes that are not yet addressed.

For example, in order to let people find and navigate content using a wider range of mechanisms, markup languages could provide a way to add tags (also called keywords) to any or almost any content elements. Currently keyword tagging is supported at the HTML document level, but not at smaller granularities. As many web sites support content tagging on images, posts, or articles, and HTML5 puts a lot of effort into facilitating aggregation of these, the new feature would also be an example of providing a standardized way for content to expose information that is currently handled in an ad hoc or site-specific fashion, thus allowing user agents and assistive technology to make use of it in novel ways.

Use case: Nadia uses a screen reader to explore a blogger's web site. The page shows the first paragraph of each recent post, each in an HTML5 article element, and each includes the title, poster, posting date, keyword tags, and a link to the full article. Because scanning the entire page searching for articles that match her criteria is much more difficult and time consuming for her than for most users, Nadia uses a browser add-in that lets her navigate to the most recent article before or after a given date. Each article's title and publication date are marked up in automation-friendly ways, as <article><header><h1>The Very First Rule of Life</h1><header><p><time pubdate datetime="2009-10-09T14:28-08:00">…, allowing user agents and accessibility aids to use this information for navigation, filtering, color-coding, etc. However, HTML5 defines no standard way to identify the content that represents the poster's identity or keyword tags, so the author has to put those in a plain text. Because of this, her add-in cannot let quickly navigate to or between articles that are posted by a particular person or that are tagged with specific keywords.

Use case: Marge is browsing a web page with a hundred images, but she wants to find the one of a sailboat. While many users can make a quick visual scan of each screenful of content, paging down until they find the correct image, this is much more difficult for her, so she activates an add-in for her browser, selects the check box for "Images", and a list box is populated with the keywords for all the images on the page. She types the first characters of "boats" to move the focus to this entry, presses Space to select it, and presses Enter, at which point the extension temporarily hides all the content except the two images that have the boat keywords.

Use case: Randy is easily distracted so he uses a browser add-in to filter each page, hiding information that it can recognize as not relevant to his current task. Using standard markup it can, for example, hide all content on a page excepting articles that meet certain criteria.

Use case: In order to help him understand and navigate a collection of HTML documents, Joshua runs a tool that generates and presents him with an index and table of contents. If the author has no way to recommend keywords and phrases for portions of content, the functionality can only provide a simplistic guess at what are the primary topic of each section, but if the author can explicitly associate key words or phrases with headings, tables, and even paragraphs, the tool can do a much better job. This can also provide tools such as search engines to data and hints to work with.

Recommendation: HTML5 should allow a keywords or tag element to be added to all or nearly all elements. This could be a set of space-separated tokens, and although this precludes including spaces in the keywords or key phrases, it would allow it to be processed in standard ways already used by other attributes. For example:

• <img keywords="flags swan union-jack" src="western-australia.png" alt="Flag of Western Australia">.

• <article keywords="computers apple news"…>

Alternatively, a keywords element could be defined that could be associated with another element, either by referencing an element ID or by surrounding content with which it's associated.

discuss, John to follow up with Tantek Çelik and Manu Sporny

Recommendation: HTML5 should define a text-level author element that would identify its content as identifying the author of the associated content. The typical use would be in cases like <article><header><h1>The Very First Rule of Life</h1><header><p><time pubdate datetime="2009-10-09T14:28-08:00"><p>Posted by: <author><a href="/users/gwashington">George Washington</a></author>…

discuss, John to follow up with Tantek Çelik and Manu Sporny