This is a planning document for the Web Accessibility Initiative Working Groups to support the Protocols and Formats Working Group in executing a formal review of the HTML 5 specification (Editor's Draft as of August 2009). The Table of Contents from the HTML specification is shown along with reviewers assigned to each section.
Gottfried: The „willful violation“ of RFC3986 (see note at bottom of the section) in using the term „URL“ is not good. It confuses users and works against a harmonization of existing standards. A replacement term for “URL” should be found. Cf. http://www.w3.org/html/wg/tracker/issues/56 MC: not a PFWG comment.
Gottfried: Is it possible to create and modify <optgroup> elements by JavaScript? <optgroup>s are a useful mechanism for structuring options, in particular for users with screenreaders and magnifiers. I don’t see this here, but maybe i am missing something. MC: add method does allow optgroup; suggest not submitting.
UAWG03: ISSUE-41 (Decentralized-extensibility) blocks progress to Last Call. HUGE problem for AT. Possible new elements created that no AT is familiar. MC: issue in "raised" state; should add a PFWG +1 but not sure of mechanism.
Loretta: http://lists.w3.org/Archives/Member/wai-liaison/2009Aug/0006.html
The standard Element interface includes an attribute, "icon". I'm not sure of its purpose, but we should make sure that these icons have text equivalents available, too, if needed.
Cynthia: icon is part of a "command API" that also has a label. That would need to be required. Cynthia looking into this.
MC: label is present; no need to comment.
Loretta http://lists.w3.org/Archives/Member/wai-liaison/2009Aug/0006.html
Accessibility uses of title problematic when title may have other uses as well.
Steve has an issue open about title. http://www.w3.org/html/wg/tracker/issues/80
MC: suggest reengineering title attribute, moving accessibility use cases to label attribute or something. But this would be a big change that has to propagate through many elements.
UAWG21: Embedded Links to Non-Visible Data - this could be really useful and a great accessibility feature, but as there is no concept of interoperability beyond the site (as it is site bespoke) then we need to ensure that this kind of data is readable by the AT and maybe even the semantics of the interaction expressed in someway. MC: this is related to extensibility and we should review in context of extensibility solution and what our priorities for that are.
UAWG22: Orphan Nodes in Content Models - this could be problematic if the node cannot be accessed by AT, especially if it is going to modify the DOM based on a user event, but there is no way of telling what that modification will be. MC: the node isn't meaningful until it gets inserted into the document at an appropriate place, at which point AT can use it. Don't think this is an issue.
UAWG23: activation behaviour and pre-click activation - there are too many opportunities for some accessibility nightmare here so it maybe worth reading these points and then discussing them. MC: discuss. My biggest concern is that it's all mouse-biased. Beyond that, I can't figure out what it does.
Sofia: The base element allows for a target attribute that controls the context in which target URLs will be displayed. The target attribute value potentially changes the context for all links in the document. Applicable WCAG 2.0 Success Criterion: 3.2.5 (Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)) MC: Suggest a user agent technique to provide an override mechanism, and a WCAG technique around the issues.
Sofia: No mention of encouraging authors to make their applications degrade gracefully in the absence of style support or to allow for alternate presentation. Applicable WCAG 2.0 Success Criteria: SC under Guideline 1.3 (Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.) MC: think this is a design issue, not a spec issue.
MC: I don't understand what the title attribute does ("alternative style sheet sets" is not linked to a definition) and what accessibility implications it might have.
MC: Handling of alternate style sheets not defined (alternate to what?).
Josh: Does the algorithm give an idea of how this kind of content would be parsed by legacy UAs? Discuss.
Josh: In the “Sectioning Root” [2], the spec states “Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level.”
Does this mean that multiple <h1>s can be used in a single doc? Does this go against current best practice?
The spec states that:
For example, the following is correct:
<body> <h4>Apples</h4> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <h6>Sweet</h6> <p>Red apples are sweeter than green ones.</p> <h1>Color</h1> <p>Apples come in various colors.</p> </section> </body>
is it? Seems like an incorrect placing of <h1> to me.
Josh: Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.
Does this break the model of only allowing use of one <h1> per html doc.Josh: The spec state:
“User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.”
How will this be done in the UA? Will they activate a linked nav element like they do a href? Or will the user be able to jump to a <nav> element the same way user can browse by headings etc.
How will this work with aria role=”navigation” in a UA?
Josh: The spec gives an example:
“In the following example, there are two nav elements, one for primary navigation around the site, and one for secondary navigation around the page itself.”
They seem a little pointless. Both are just lists links wrapped in <nav>. They can link to items on the same page, or on separate pages. The user can often gain this information from good descriptive link text. Again how will this work with aria role=”navigation”.[reaction to comment 126] The first paragraph is not clear whether it means an article can contain a widget or be a widget (have a widget role). We believe it should be able to contain a widget but be default should not be a widget. By default, articles should be contained in documents, not in applications.
Josh: Are the examples equivalent?
Is this advice confusing? Does this use of headings represent a shift in the way HTML headings have been used in the past? Discuss.Josh: How will that work in practice with screen readers? Will child headings contained in the <hgroup> be ignored? In particular legacy UAs? Will legacy UAs just not parse the <hgroup> element and just parse the contained headings?
Should alternative alternative titles, or taglines etc be marked up like this in the fist place?
Josh: “The header element is not sectioning content; it doesn't introduce a new section.”
The header element does not take part in the outline algorithm. However, should it not do this? Is it not implied that a header has an associated following section? Seems counter intuitive. Or is this by design?Ben:
Ben:
Ben: Private communication (4.8.2.1.11) should not be listed as an exception. Exceptions of this nature are beyond the scope of both HTML5 and WCAG 2.0 and should be addressed at a policy level rather than the specification level.
AUWG: re alt: Suggest wording be synchronized with "ATAG 2.0 Guideline B.2.4". Specifically: B.2.4.3 Let user agents repair: After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text value that is equally available to user agents (e.g., the filename is not used).
When iframes are processed in keyboard navigation order, the tab order should tab in document order from outside the iframe, into the first focusable item in the iframe, then when it reaches the last focusable item in the iframe, the next tab should exit the iframe and move to the next item in tab order in the parent document. This is because a lot of uses of iframe are to support security in the web page.
Ben: Suggest including advice related to iframe about the use of the title element to identify frames from a navigation perspective. (ex. In speech media, the title attribute provides a label for an iframe, allowing users to more easily navigate to and explore individual sections.)
Gregory: an issue that the <iframe> can't be resized. See http://esw.w3.org/topic/PF/XTech/IFrame.
Ben: What is the mechanism for providing a short text alternative for embedded content? If there are scenarios where the embedded content itself would be unable to provide a label for the embedded content, the spec should include a mechanism for authors to id the embedded content. Even if the plugin content has built-in accessibility, the need for fallback content will arise for users on platforms that do not support the plugin, have limited bandwidth, etc. Propose either dropping this element it in favor of object as proposed in http://www.w3.org/Bugs/Public/show_bug.cgi?id=7075, adding support for fallback content to this element, or adding an attribute that can provide a short text alternative (could be by placing embed inside a figure element with a label, via the alt attribute similar to <img>, aria-labeledby, or via title similar to <iframe>).
Ben:
Ben:
UAWG30: Accessibility of the video content left unspecified. No mechanism for defining or providing captions as part of the Video element. This is unfortunate, in that W3C's very own proposed DXFP [1], and even SMIL Text [2] provide everything needed to create accessible video content (assuming the authoring tools and browser support were there).
Given the controversory over video codec support, captioning is apparently not being given attention.
It is not clear to me that the spec has specified/will specify a standard API that would allow a UA to query if media (either audio or video) ".hasCaptions", or to otherwise get at the text of the captions(or the language, etc).
If the UA (or AT) is supposed to have the ability to control captions, shouldn't the video element have defined the needed properties to query and control the caption content in the video being loaded/played? This seems very vague and a big gap for such a visible feature of the HTML5 spec. Failing any further details in the HTML5 spec, it is imperative that the UA spec will address the missing details.
Silvia Pfeiffer [3] has been active in looking at HTML5 video accessibility, and has a proposal for iText as a means of integrating captioning into HTML5 video. This is great work, to be lauded, but I am still at a loss for the failure to integrate existing W3C work such as DXFP for captioning. I must be missing something.
No mention of descriptive video or alternate audio tracks. Again, is this something that *may* be in the video source, pr authored using a combination of scripting and the audio/video elements? Unclear, and should be addressed.
My take on HTML5 video is that, based on the current spec, implementation of captioning/dvs will will primarily occur via authored scripting around the video element. Perhaps some browser vendor will build it in a non-standard way. It should be defined more fully in the HTML5 spec.
[1] http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/
[2] http://www.w3.org/TR/SMIL3/smil-text.html
[3] http://blog.gingertech.net/2009/07/29/first-experiments-with-itext/
UAWG31: The User Agent should be required to provide the controls/interface-elements for media (audio, video, etc.). The author should be able to style or script for extended functionality. The core functionality - start/stop, pause, seek, volume, size (full screen), caption track(s)- on/off/fg-bg color/location, descriptive video(s), should not be written by millions of authors.
Ben: <same as for video>
Ben: for partially usable media data, the specificaion indicates that the UA should "render just the bits it can handle and ignore the rest." What happens if a caption or secondary audio stream fails to load? Suggest that this be revised to require the UA to present an opportunity to load fallback content when it is available.
Ben: "If the media element's Document stops being a fully active document, then the playback will stop until the document is active again." - This implies that it would not be possible for a user to listen to audio in the background or take notes about a video in another application while viewing the video at the same time. Suggest that the decision about what should be done in this case should be left to the user agent.
Ben: Suggest adding the availability of captions or aditional audio tracks to the items listed in a UA provided user interface. "... (e.g. <ins>show captions, turn on audio descriptions, </ins>full-screen video or in an ...)"
Ben: Propose adding additional media events to indicate whether captions and audio descriptions are present, turned on, etc.
Ben: Primary concerns here are that it appears to lack hooks for direct accessibility in a number of places. As with other types of embedded content in this specification, a basic mechanism to include text alternatives (both short and long) is of critical importance.
Ben: Speech browsers and assistive technologies handle text alternatives on image maps and their corresponding area elements differently. Please include a description of the expected behavior for situations where the text alternatives for the individual area elemements may not make sense without the added context of the text alternative for the <img> or <object> that is associated with the <map>.
Ben:
UAWG15: Overall the proposal to allow unscripted client-server interaction thereby taking the onerous off the page author and into the browser is a huge benefit to accessibility. This means that validating forms, checking input and so on will be customized across sites with no reliance on JavaScript. Designers will not have to build form validation from the ground up each time and users can enjoy some consistency, less breakage and so on.
UAWG17: Date pickers should be both keyboard accessible and able to be magnified in the browser. I think this is beyond the scope of HTML5 itself and covered in UAAG but mention it just to clarify.
UAWG17: <same as above>
UAWG16: Under form validation there is no stipulation that validation errors should be stylable by the page author using CSS and are currently only available as per how the UA styles them unless the page author knows JavaScript. This I see as an issue if browsers simply implement an arbitrary styling that some users find hard to read. As such there needs to be scope for validation errors to be stylable (without relying on JavaScript) or browser implementations to be as readable / accessible as possible (the latter being pretty subjective).
My other fear is that if forms validation can not be styled without JavaScript page authors may skip using HTML5 webform validation as it messes up their design. We then get to a situation where we have developers refusing to adopt webforms in HTML5 in favour of their own styled forms which potentially could be inaccessble. Users in turn miss out.
Anecdotally I know of a web designer who works predominantly with users with cognitive problems and wont use webforms if they can't easily be styled without JavaScript.
Proposal: require that all error validation be stylable by the page author without relying on JavaScript. Not sure if this is in scope of HTML5 or is under UAAG. I'm told this is not so easy for a UA to do and that if we want to make the default error messages styleable, we would need to approach the CSSWG with the problem and have them find a solution to make them styleable. Apparently it could possibly work if they provided some sort of pseudo-element.Cynthia: I’m not sure what this sentence means:
“The details element represents a disclosure widget from which the user can obtain additional information or controls.” After reading through the section, it seems to be for those “more info” popups. There is no discussion of what the default rendering looks like. I think it looks like this
<details> <dt>More Info</dt> <dd> <img> <p>blah blah blah</p> </dd> </details>
Would render as just “More Info”. The author would have to write script to toggle the “open” attribute. This should have a built-in tabstop (not specified) and built-in toggling behavior (not specified). The default rendering should be specified. For example, does an open details section cause the page to reflow?
Cynthia: Can the <dt> and the <dd> contain any arbitrary tags?
Content model is empty. I think that means it can’t have any tags inside. Why? It would be very useful to be able to wrap a command around a larger group of tags. The Hotmail inbox is a great example of this. Each message has an icon, a subject, a from field, some time stamps, and a line of text from the message. The whole thing is clickable, and multi-selectable.
Attributes: type, label, icon, disabled, checked, radiogroup.
Title has special semantics, in that it defines a ‘hint’ (which would map to an MSAA description, I think). This seems like the right general semantic for title.
Type can be normal (which is either a button or a menu item, it’s hard to tell), radio and checkbox. There’s no markup sample, which makes it confusing why you would use this instead of the <input type=radio|checkbox>. After reading the whole of 4.11, I think the checkbox state is actually a multi-select state and the radio state is a single-select state. Having these states outside of a <select> is a good thing. Radio and checkbox do have those properties, but I think most people think of the rendering more than the selection behavior. I would change these to @select or @multi-select, and replace @checked with @selected.
Radio buttons can be grouped using the @radiogroup attribute. The algorithm described seems to require that radiobuttons with the same radiogroup have the same parent. This is not required of <input type=radio> now, and it’s pretty common for them not to have the same parent. Why is this required?
Icon and label attributes give the visible and textual representation of the command. This is actually a really elegant way of handling what is now handled by <a href><img alt="">Display Text</a>. Label is not currently required, but I think it should be, just like alt. I would add an attribute that shows or hides the label, so you could have a button that is just an icon, but that has a label anyway. This would be great for toolbars that shrink and grow based on widow size. This should also support aria-labeledby and <label for>. There are situations where text in attributes is problematic in production and localization procedures. Also, why/how is this label different from aria-label?
Note: firing a synthetic click event at the element does not cause any of the actions described above to happen. WHY? Synthetic click should always be the same as real click. This is used by lots of accessibility techniques.
Command elements are not rendered unless they form a part of a menu. I don’t think that’s necessary. The Hotmail inbox example shows a real need for a generic multi-selection mechanism like this, even without a menu.
<menu type=”list|context|toolbar”> (list is default)
I think "list" is a normal popup menu, rather than an always-open menu, but this is a confusing name. I'd add type=popup which would have the standard open/close menu behavior built in. I’d make popup the default, rather than list, which would be an always-open menu. That list could be used for the Hotmail inbox example.
[as a side note, I find the format really hard to understand. It talks about processing instructions, and I had to reverse-engineer what the markup would look like]
Working out the API mappings will be interesting here. This seems to be based on how Mac menus work, where the commands are buttons rather than menu items.
The example uses a select inside a menu to build a backward-compatible menu (I think that's why it's done). The rendering of <select> and <option> changes when inside a menu, so <select> is ignored and <option> renders as a command. This will be tricky for mapping, as the mapping of these elements may change based on context.
The example has a <select> that navigates onchange, which is a WCAG violation. There is a go button, but it isn't used.
Both <menu label="Go to…"> and <label for="(id of select)"> are used, and have the same text. This seems goofy and redundant. Also text in attributes is often a problem for localization. aria-labeled-by on the select would be a better choice, perhaps?
They also use in the example, <option value="" selected="selected">Select site:</option>. Which I've always thought of as a worst practice. This is more feedback for the forms section, but maybe something like this would interesting
<select> <label>Choose a value</label> <option>….</option> … </select>
The label would render as the displayed text of the select, and also provide its accessible name, but would not be selectable itself.
[Another side note, the example could perhaps be a little more vendor neutral…]
There is a special case for <option value="" disabled>--------</option>. Since <hr> is also supported, why is this needed?
Again, processing instructions but no markup. Why do you need to say "An option element that has a value attribute set to the empty string, and has a disabled attribute, and whose textContent consists of a string of one or more hypens (U+002D HYPHEN-MINUS), rather than the simple markup I used above.
There are way too many ways to define menu items.
Needs a code sample, but I think they're saying that context menus would work like this:
<menu type="context" id="foo"> <li>Save As…</li> <li>Spelling…</li> <li>etc…</li> </menu>
Then, somewhere else in the DOM
<span contextmenu="foo">
I think these should only be allowed on tabable elements, or should make the element tabable when they are added. Similarly, reading order and tabbing order need to be defined in this spec. We don't want to have to write WCAG techniques that say to put the context menu in the DOM right after the element that triggers it, as that would make them less reusable, or require that every context menu be scripted.
I also wonder if something like this wouldn't be better, but it might be less reusable.
<menu type="context" for="bar">
In the 6th paragraph in this section, it says "The default action of this event is that the user agent must show a context menu built from the menu element. I'm not sure what this event is or why it's italicized.
The user agent may (I'm assuming this is MAY) also provide access to its default context menu. I think this should be a MUST, and that there may need to be an attribute that authors can use to say when they don't want that behavior. Users would need to be able to override the author attribute.
Context menus must not while being shown reflect changes in the DOM… Why?
User agents MAY provide means for bypassing the context menu processing model… This should be a MUST.
The user agent MUST reflect changes made to the menu's DOM… why is this the opposite of context menus?
Again, reverse engineering the markup
<command type="command|radio|checkbox" ID="string" label="string" hint="string" icon="absolute URL of image" accesskey="string" hidden disabled checked action="event handler or URL">
Type=command means a "normal" command. What is that and how does it behave? Is that a menu item? A button?
Why is there a command and an input for radio and checkbox? Why not use the existing form elements inside the menu? Select is used this way.
Why only absolute URLS and not relative urls for icons?
Command API (this should have a heading 4.11.4.1)
What elements support this API? Only those that “define a command”? Can I use this API on an <option> for example? If I use this API on a <span>, does it become a command?
Why “facet” and not “attribute”? How seem to map to the element attributes, so why use a different word?
Does label also return values set with aria-labled-by and aria-label?
Disabled: This attribute will be shadowed by the disabled IDL attribute on button, input, option, and command elements. What does that mean? What does the markup look like? How does the markup map to the API values? (same feedback for checked)
document.commands: do <a href>, <button>, <input> etc show up in this collection?
<a href> defines a command (again, written out in longhand as “an a element with an href attribte” why not just use the markup? It would be both shorter and more clear). Defines what the type, etc will be. A table would be more clear, and shorter.
Label is the string given by the elements textContent IDL. Does this include alt of any images inside the link?
Icon is obtained by resolving the src of the first img in the link. I like this.
Supports ‘hidden’ but not ‘disabled’. Why? I’m guessing because <a href> doesn’t have a disabled state, but why is that?
Button always defines a command. I like that.
Why do we need this AND <command type=”radio|checkbox”> ?
If the type is command (any input other than type=”radio|checkbox”), then label is given by the value attribute, if any, and a UA-dependent, locale-dependent value that the UA uses to label the button itself if the attribute is absent. HUH? What does that mean? Examples, please? What about <label for>, aria-label, aria-labeled-by? Also, in IE, title fills in the accname if none of this other stuff does. Should it?
Image button has an icon, others don’t. Why not use the first image inside a button or label, like what is done for <a href>
An option element with an ancestor select element and either no value attribute or a value attribute that is not the empty string defines a command. So… <option value=””> is not a command, but <option value=”foo”> and <option> with no value is? Why is <option> with no value allowed?
The type of the command is “radio” if the options nearest ancestor select element has no multiple attribute, and checkbox if it does. So…
<select multiple> <option>1</option> <option>2</option> <option>3</option> <option>4</option> </select>
Defines a bunch of checkboxes, and
<select multiple> <option>1</option> <option>2</option> <option>3</option> <option>4</option> </select>
Defines a bunch of radio buttons.
Is this only true if it’s inside a menu? Should these be commands when they’re not in a menu? There are issues with select being used as a menu.
Should these be mapped to button or menu item?
How does this render? Does it render with actual radio and checkbox UI? If not, should commands be <command type=”action|single-select|multiple-select”> instead of radio/checkbox?
Why is this in a separate section from the command element?
Lachlan says accesskey on the <command> element provides nearly all the features of the XHTML access module. What's missing is role-based navigation. See Rich's access key requirements. We need to decide if we think what HTML has goes far enough, and if not make specific suggestions for what change needs to be made.
Ben:
Sally: "...the user agent may report the error to the user in a user-agent-specific manner, may navigate to an error page to report the error, or may ignore the error and do nothing." If unable to resolve URI, UA has option of doing nothing. The user should get an error message that is accessible and understandable.
Sally: "...if these rules result in the creation of a new browsing context, it must be navigated with replacement enabled." A general issue around 'browsing contexts' and ensuring accessibility of these 'views'. There may be an instance where a second browsing context is presented to the user. It should be accessible to the user and presented consistently.
Sally: "Otherwise, if the hyperlink element is a sidebar hyperlink and the user agent implements a feature that can be considered a secondary browsing context, such a secondary browsing context may be selected as the browsing context to be navigated." I'm honestly a bit confused by the concept of 'secondary browsing context' and 'sidebar hyperlink', but I believe this could mean that the urls will open in a part of the user agent's interface, which is not the main content area. Then this should be made clear to users.
Sally: explanation of ping attribute at end of section Generally this attribute looks to improve things but there is one statement: "It allows the paranoid user to disable the notifications without losing the underlying link functionality." Can we ensure that the notifications are accessible in the first instance, and then that the way to switch them off is accessible?
Sally: This is attempting to encapsulate more meaningful links but I am not clear generally how is this information presented to the user and screen reader? There are a lot of these listed in this section. One still on the WHATWG wiki is rel=accessibility which is just a proposal at present.
Sally: The example suggests to have the 'help' link following the relevant form element. This goes against what we RNIB always recommend, which is to have the help link between label and field, but *NOT* part of the label element.
Sally: The spec states "Icons could be auditory icons, visual icons, or other kinds of icons". But are 'auditory icons' meant to be played by the AU as soon as a page loads? This may clash with AT such as screen readers especially if the audio sample is long.
Sally: Spec does not specify how to distinguish between main content of the doc and the rest. Surely this should be clear and there should be a way to distinguish. If nothing else so people jumping around content using shortcuts are clear what they are reading.
Sally: This example uses an old technique RNIB advise against, which is a printable character '|' between links. This was a AAA in WCAG 1.0 but fortunately disappeared from WCAG 2.0. CSS or a decorative image with empty ALT="" would be preferred.
JamesC: The paragraph after the HTML example code states, "In this case, the license applies to just the photo, not the whole document." However, the example is not marked up in a way that can be determined by assistive technology. If license is meant to apply to anything other than the entire document, the specification should define rules to make the relationship determinable by assistive technology.
Sally: "The nofollow keyword indicates that the link is not endorsed by the original author or publisher of the page, or that the link to the referenced document was included primarily because of a commercial relationship between people affiliated with the two pages." This could be a bit of information that could be worth to have *all* user agents to pass on to users, including screen readers.
Sally: This links back to my comment on secondary browsing contexts and ensuring accessibility above. Anything that is going to open somewhere other than the main content area needs to be made clear to users.
JamesC: Link type "tag" specifies the link relationship, but does not specify how the tag name is to be determined apart from the link's text equivalent. The specification does not define how an author might differentiate hyperlinks referring to the same tag in different scopes. For example, on Flickr, there are two links for each tag: "your photos with tag: 'foo'" and "others' photos with tag: 'foo'"… If the text equivalent for both links the same, an assistive technology user will not be able to perceive the difference. If the text is different, there is no machine-readable way for a script to understand that both links refer to the same tag. The Microformats wiki page for rel-tag attempts to solve this problem by enforcing a RESTful tag URL apart from the text equivalent, but it still has several unaddressed development and internationalization issues. <http://microformats.org/wiki/rel-tag-issues> If this type of link relationship is to remain, consider adding an optional data attribute to allow the author to explicitly state the tag name if it is not the same as the text equivalent.
Sally: This way of structuring documents and the relationships between them needs to be clear and be understood by the screen reader user as having relationships.
JamesC: The example code uses a related set of links to define the breadcrumb navigation, but does not use a list element, so there is no way for assistive technology to convey the hierarchy or relationship between the links. The example should probably group the links in a list element, and should also provide some sort of text equivalent to explain the purpose of each list and convey the difference between the two types of breadcrumb lists.
Sally: Again this way of structuring documents and the relationships between them needs to be clear to the screen reader user.
Sally: What I am not clear about is how/when other link types will be approved. It does state in the spec at the moment that this is not clear yet. When the spec is published will people be able to continue to propose to the WHATWG Wiki new types that get accepted? Could this mean a rash of new types which just keep getting accepted without being formally approved?
UAWG05: It's important to give users the ability to discover and navigate content when authoring tools are used incorrectly. The hidden attribute is a good example. Excerpt: "The **hidden **attribute must not be used to hide content that could legitimately be shown in another presentation, for example..." On occasion it will be, however, and full accessibility means the user needs some way to override this in order to deal with incorrectly rendered pages.
UAWG12: Accessibility APIs must honor this. User agents will need to ensure to reflect the state of this attribute in their accessibility APIs. This may be stating the obvious but is worth calling out since there are various situations today where AT products do or do not show the same text that is visually displayed and this is another potential variable to keep in mind. UAAG Implications: We need to develop some kind of test criteria around this, especially for AT support/compatibility
UAWG06: In a perfect world there'd be a way for the user to override automatic scrolling. Automatic scrolling can make the cursor jump in ways that causes the user to go through extra steps to get back to what he was doing. This is a special hardship for some users. This is another example of allowing for full accessibility by giving the user a way to override inappropriate design.
UAWG13: What should happen to focus here, especially keyboard focus? This is an interesting one. The GL talks about calling attention at times as in The scrollIntoView([top]) method, when called, must cause the element on which the method was called to have the attention of the user called to it. Exactly what this means for accessibility and how UA should do this in an accessible fashion are good things to think about.
UAWG07: The user needs some way to override/hold off focus changes. User macros including speech commands execute over time. Unwanted focus switches can produce bad results. In addition, speech users don't necessarily change the focus by moving the mouse -- this makes them more likely to get caught with bad focus changes. This is a third example of allowing for full accessibility by giving the user a way to override inappropriate design.
@@need for full Access Module functionality
UAWG18, UAWG19: So looking at this further, I see that in 7.6 list-item 2 @@can't find@@ and 3.3 of the HTML5 spec on accesskeys, that only a single key is allowed as opposed to multiple sequential keys, however, when you add this to the concept of the context menu in 4.11.5.3 it seems that the general model of interaction, and importantly exploration of the interface, becomes broken as a single keystroke without a modifier key cannot be allocated. While this follows on the mac OS, the intuitive sequential keystrokes of Windows and Linux will break. In this case what about a caveat that if the context menu is in focus then a single keystroke without a modifier key is sufficient?
UAWG08: Move the carrot *Excerpt: ... "this could be triggered as the default action of keydown events with various key identifiers and as the default action of Mousedown events * It's important to provide a way to do everything through the keyboard -- this seems like an either/or. (For speech users, selecting text using keyboard commands is easier, requires fewer steps and is more precise than selecting text using mouse commands.)
UAWG09: Select and move non-editable elements nested inside editing hosts *Excerpt: UAs should offer a way for the user to move images and other non-editable parts around the content within an editing host. This may be done using the drag and drop mechanism.* All drag and drop needs to be accessible using key navigation and cut-and-paste. (For speech users, drag-and-drop using key navigation and cut paste is less prone to mistakes and fewer steps than using mouse commands. )
UAWG10: Again, needs to be accessible using key navigation and cut-and-paste. It's also important to have undo enabled for drag-and-drop. *Excerpt: On a visual medium with a pointing device...* *On media without a pointing device...* Even if media has pointing device needs keyboard option
UAWG14: This still seems plagued with accessibility actions. This needs more discussion around accessibility. Is it enough to say that the start/end point experiences of the drag/drop must be accessible. What about everything that can happen along the journey? I think we need to discuss this one further with PF and ourselves.
UAWG20: I have no idea how this can be addressed, while selection can be easy, understanding the location on a page for a drop/release may be problematic without some form of browser based auditory feedback?
UAWG11: This should include drag and drop
Sally: It appears that the main change here is that they have changed the way the syntax works moving away from SGML. I don't know enough about this to comment if it does have an impact on accessibility. The doctype ensures the page renders in standards mode which is a good thing and seems to be supported by most browsers already.
Sally: Nothing in WCAG 2.0 mentions any requirements for charset. However, because of RNIB's experience with See it Right and some browsers - specifically Internet Explorer 6 - We wanted to include in Surf Right a checkpoint for valid charsets. We never checked on other versions of Internet Explorer, but on IE6, if you don't specify a charset, some characters are not correctly displayed and replaced by things like French letters or other symbols. So we don't need to be too strong about it in the HTML5 document. It would be nice though, to have a note saying that to ensure compatibility with older UA having a charset would be advisable.
UAWG29: If the user wishes to increase the size of text in an iframe or other container element, the text may overflow the container. When text overflows the size of a box and the attribute value is set so that the overflow value is "hidden", the overflow text may not be passed to the Assistive Technology and the user may not be able to see the text that does not fit in the container.
Proposal: Add after chart (Attribute value/'overflow' value)
UAWG28: Users with low vision adjust font sizes to the minimum size needed for comfortable reading. Many users with low vision do not use assistive technology, but rather adjust to the largest font size supported by the user agent. Reducing the size of the font - particularly a text-dense element like "article" - increases the imbalance between font sizes in other parts of the page (e.g. the user would be forced to increase font size for the article text to the point where the font size in the non-nested parts of the page are enlarged so much as to overflow their containers. Automatic reduction of the size is unnecessary and will decrease access for users with low vision.
Proposal: Remove the section. Nested elements should not have the containing text size reduced automatically. The author can choose to reduce the size of nested text through CSS, but it should not happen to font sizes automatically.Loretta: http://lists.w3.org/Archives/Member/wai-liaison/2009Aug/0007.html
abbr attribute shouldn't be removed, it has a valid use case? Use the language from HTML 4 about how to use it still.
Maybe instead we need the opposite use case: way to provide an expanded version.
@@need to discuss more
Loretta: http://lists.w3.org/Archives/Member/wai-liaison/2009Aug/0007.html
Unsure what the well defined elements are here. Not sure if it's an accessibility issue.
Loretta: http://lists.w3.org/Archives/Member/wai-liaison/2009Aug/0007.html
Marquee should default to off.
@@this needs more review
Suggest a section on tabbing describing tab cycle, default tabbable elements, use of tabindex=-1, what happens with special elements like iframe
Sally: What do we know of the roadmap for screen reader vendors to support html5?
Ben:
UAWG01: massive document, changing frequently. HTML so complex, and nuanced, concerns about missing accessibility issues
UAWG02: Fallback content - no user agent provides a mechanism to retrieve author created fallback content: 3.2.5.1.6 Embedded content - definition of fallback content; 3.2.5.3 Paragraphs; 4.8.4 The embed element; 4.8.5 The object element; 4.8.7 The video element; 4.8.8 The audio element; 4.8.11 The canvas element... (lots more in the document)
UAWG04: 3.2.6 Annotations for assistive technology products - are these in sync with ARIA (MC: can't find section)
UAWG25: There are elements which are VERY VERY GOOD and the HTML5 crew should be congratulated from the nice explicit semantics of menu and the like. However, they then mess it up with elements such as 'small' - convenient for a visual rendering, good for the designer, but without a concept of the semantics of the thing it encloses - it does not say what the thing is. Would it not be better to enable overloading of an element and style combination into an element that is good for the designer, but because its base element type is known (and this has explicit semantics) AT gets a better idea of what the thing actually is as opposed to how it should be rendered?
UAWG26: I've not seen a good definition of quirks or limited- quirks modes.
UAWG27: It seems to me we are going to need far better validation and conformance tools to check that possible DOM modifications in the scripts are accessible - otherwise an html page - containing pretty much nothing will validate as OK, but there may be a huge amount of scripting which will enact inaccessible DOM updates on the client.
AUWG: "Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, but only to the extent that authoring tools are not yet able to determine author intent." Suggest stating that authoring tools should help authors meet the strict requirement (of using elements only for their specified purpose) by not automatically misusing elements or encouraging the author to do so (e.g. in documentation)
AUWG: "Authoring tools are expected to come in two broad varieties: tools that work from structure or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG). The former is the preferred mechanism for tools that author HTML, since the structure in the source information can be used to make informed choices regarding which HTML elements and attributes are most appropriate." It seems subjective to prefer an editing mechanism. Perhaps this should be clearly marked as "informative".
AUWG: "However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are appropriate, and should not use elements that they do not know to be appropriate. This might in certain extreme cases mean limiting the use of flow elements to just a few elements, like div, b, i, and span and making liberal use of the style attribute." Suggest stating that WYSIWYG tools may need to make a special effort to gather semantic information, rather than describing exceptions for "extreme cases".