- From: Greg Lowney <gcl-0039@access-research.org>
- Date: Thu, 28 Jul 2011 02:48:51 -0800
- To: WAI-UA list <w3c-wai-ua@w3.org>
- CC: Janina Sajka <janina@rednote.net>
- Message-ID: <4E313E93.1020207@access-research.org>
The following are not specifically about accessibility, but are miscellaneous errors in the current draft HTML spec, and some suggestions for possible improvements. Errors and omissions: In 11.2 Non-conforming features, marquee is listed as a non-conforming feature, but that conflicts with 11.3.2 The marquee element which describes it as obsolete but conforming. In 4.11.1 The details element, there is a significant error. It says "The open content attribute is a boolean attribute. If present, it indicates that the details are to be shown to the user. If the attribute is absent, the details are not to be shown. When the element is created, if the attribute is absent, the details should be hidden; if the attribute is absent, the details should be shown. Subsequently, if the attribute is removed, then the details should be hidden; if the attribute is added, the details should be shown." The THIRD occurrence of "if the attribute is absent" should read "if the attribute is present". In 7.3.2 Focus management, the instructions titled "The unfocusing steps are as follows:" includes "2. Unfocus the element." but does not define what "unfocus the element" means. In 7.5.1 User editing actions, it says " Select and move non-editable elements nested inside editing hosts: 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. User agents must not, in response to a request to move non-editable elements nested inside editing hosts, generate a DOM that is less conformant than the DOM prior to the request." This should also mention that the UA is expected to support equivalent mechanism, such as cut and paste, that does not require a pointing device. [This one is an accessibility issue, albeit a minor one.] In 7.1 The hidden attribute, it should explicitly say that when the user selects and copies to the clipboard a region that includes hidden content, the hidden content should not be copied to the clipboard. (This is a significant problem for users of some browsers when part of the copied content is hidden using CSS.) In 4.8.1.1.2 A link or button containing nothing but the image, and other places like it, I'd recommend that the text "In this example..." be replaced by "In the following example..." or "In the preceding example...". As it is now, the spec often alternates examples with their descriptions, but the only way to determine whether a description applies to the example above or below it is to scroll back to the beginning of the list and see whether or not it the paragraph preceding the first example starts with "In this example". This is obvious when one is reading the document or section sequentially, but is not when one searches for text or otherwise navigates into the middle of the list, or reads an excerpt. Suggested improvements: In 7.8 Editing APIs, it would be good to have a command for repeat, as in repeat the last editing action (e.g. equivalent of the F4 key in Microsoft Office). I'd like to see a limited set of attributes allowed in end tags, which would be entirely ignored by user agents yet could enable valuable double-checking to help guard against authoring errors. For example, if we allowed id and class attributes in end tags then authors could use things like <div id="group1">...</div id="group1"> in which user agents would ignore the id or class attribute in the end tag, but authoring tools could flag as an error if they did not match the same attribute in the start tag. This would also save authors the effort and space of using comments to mark up matching pairs of tags (e.g. </div> <!-- end of div class="topstories"> --> ). It would be helpful for authors if there were a way to special-case links to the current page. For example, if one is hand-crafting a site today (rather than using a content management system) one often has to edit the navigation links in each page to disable the link to the current page, but this could easily be done by the user agent. I suggest either an attribute on the <a> element that could be applied to it that would tell the user agent to ignore the href attribute if it points to the currently viewed page (URL), although not if it pointed to a fragment (anchor) within the page. This attribute could be a Boolean attribute called something like noselfref, or a value taking attribute called something like selfref that could take the value "disable". Unfortunately to completely solve this would probably also require enhancements to CSS, such as a :match() selector.
Received on Thursday, 28 July 2011 15:18:04 UTC