22090 2013-05-18 16:07:15 +0000 feedbck from James Craig part 2 2014-01-29 22:44:30 +0000 1 1 1 Unclassified HTML WG Using ARIA in HTML unspecified PC Windows NT RESOLVED FIXED P3 normal --- 1 faulkner.steve david100 david100 faulkner.steve jcraig mike public-html-bugzilla dave.null oldest_to_newest 87878 0 faulkner.steve 2013-05-18 16:07:15 +0000 Starting with the "Recommended ARIA usage" table: > dl Please note that there is no direct ARIA role match for description lists, so it's in appropriate to override the native role in this case unless the author is retrofitting an improper use of the DL element. > hgroup Probably need to remove this. > iframe Probably need to add another row for iframe[seamless], where it is okay to override with any general grouping role. > input type=checkbox This note is no longer relevant for ARIA 1.0: "it is required that an explicitrole=checkbox is declared " The host language implicit role is enough without the redundant role attribute. > input type=number > input type=range Should add that it's okay to use aria-valuetext on these, with or without an explicit role. > math Why is it recommended to use the ARIA role here? The ARIA role is mainly useful for math that is not marked up in such a way as to be programmatically determinable. MathML on the other hand, provides enough structure and metadata to determine much more information about the math content. I would say that it is not necessary or recommended to explicitly use a math role on MathML. > meter This one is listed as N/A, but I think progressbar is the equivalent role here. I would still list this as NO, though. > ol Add "group" to the role list. > output Not YES. I'd say it DEPENDS. If you add role="status", it will force this to be a broadcasting live region. In some cases, this is fine, but if this is an element whose value changes constantly due to scripted updates rather than explicit user action (like a progressbar), it'd be more appropriate to set aria-live="off". Otherwise some AT users are going to find this very distracting, even impossible to use. Even "polite" live regions can be annoying if they are overused. > progress Should add that it's okay to use aria-valuetext on this (e.g. "Step 2 of 10"), with or without an explicit role. > tbody, thead, tfoot Change "NONE" to "role=rowgroup" Change "N/A" to "NO" Change "these elements" to "these unrendered elements." > Text level elements not listed elsewhere Out of curiousity, why weren't INS and DEL listed here instead of on their own row? > Element with an inert attribute Change "aria-disabled" to "aria-hidden" Change "NO" to either "YES" or "DEPENDS." Remove the note about disabled content and add a new note indicating that inert content is used for things like the background contents while showing a modal dialog. In this case, it would be appropriate and recommended to use aria-hidden="true"… If there are cases where inert is being used to deactivate foreground content that is still intended for consumption, @inert should be combined with an explicit aria-hidden="false" to override the default rendering engine behavior. > Element is focusable I think you should split this into a couple rows. 1. Focusable elements that are natively focusable (links, buttons, etc.) NO, don't override. 2. Focusable elements that are not natively focusable (li, span, div, etc.) YES, override with any widget role. For example, <span tabindex="0"> is focusable but has no role in most rendering engines. The document has "NONE" in the role column, but I think it needs a role here in a lot of cases. > Element that is a candidate for constraint validation but… The note column should be updated to link to what HTML defines what constitutes the user has interacted with the control "significantly." Also ARIA defines aria-invalid="grammar" and aria-invalid="spelling" which are not mentioned here. --- That's all I noticed. Great document! Thanks for publishing it. 88340 1 david100 2013-05-29 00:24:38 +0000 Removed hgroup Will continue to go through this making appropriate changes in spare time. 88343 2 david100 2013-05-29 01:43:28 +0000 (In reply to comment #1) > Removed hgroup > > Will continue to go through this making appropriate changes in spare time. Removed ", as per current browser implementations it is required that an explicit <code>role=checkbox</code> is declared and if so you may use any <code>aria-*</code> attributes applicable to the <code>checkbox</code> role" Added <p>It is okay to use aria-valuetext on these, with or without an explicit role.</p> Removed <code>role=math</code> Did the rest of the recommendations, except the last two > Element is focusable, > Element that is a candidate for constraint validation but… and > iframe [seemless] I will look at those next time. Added role=progressbar to the meter element I'm not sure if I got the right place for the disabled content note that Craig is talking about. I'll confirm later... in the meantime, I added it with a big ADD: and REMOVE: not on each change. 88372 3 david100 2013-05-29 10:41:03 +0000 I've addressed everything in this bug. Outstanding issues (questions) are: 1) iframe (seemless) row that I added needs tweaks, and live link to element in HTML5 2)Element is not natively focusable (li, span, div, etc.) row I added needs some example 3) Element that is a candidate for constraint validation but that does not satisfy its constraints... needs link to html5 doc 4) Element with an inert attribute... needs to be checked. YES (DEPENDS) 98701 4 david100 2014-01-17 13:17:37 +0000 Moved outstanding issues to Bug 24320 98703 5 david100 2014-01-17 13:19:04 +0000 This can now be closed