This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I am reviewing the 3-col table under 3.2.7.4 Implicit ARIA Semantics [1] I see none of the items in the table allow role=alert. I wonder why. Referring to ARIA The Role Model doc[2], I see an alert is'A message with important, and usually time-sensitive, information'. The alert role goes on the node containing the alert message'. This does not suggest that role=alert should not go on an h tag or ul or li tag etc. As it contains an important message, it should also be discoverable and navigable to because alerts are not meant to be closed and may remain on the page as per the description for role=alert. That content needs to fit in with the page's structure and if it does have proper structural markup depending on context as appropriate, I see no harm. In fact it is better for WCAG 2. And Setting role=alert on a UL/OL or H-tag does not change the semantics of those tags. They are still lists or headings or whatever. So perhaps it will help to clarify why such a restriction is needed in the first place. In fact I plead that this constraint be removed. Here is an example of role=alert that works quite well and is AT supported on FF, IE9/10 and OSX http://mars.dequecloud.com/demo/form-alert2.htm Thanks and regards, Sailesh [1] http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics [2] http://www.w3.org/TR/wai-aria/roles#alert
(In reply to Sailesh Panchang from comment #0) > I am reviewing the 3-col table under > 3.2.7.4 Implicit ARIA Semantics [1] > > I see none of the items in the table allow role=alert. > I wonder why. > Referring to ARIA The Role Model doc[2], I see an alert is'A message with > important, and usually time-sensitive, information'. The > alert role goes on the node containing the alert message'. > This does not suggest that role=alert should not go on an h tag or ul or li > tag etc. the ARIA spec is host language agnostic and leaves up to the host language to define conformance constraints. As it contains an important message, it should also be discoverable > and navigable to because alerts are not meant to be closed and may remain > on the page as per the description for role=alert. That content needs to fit > in with the page's structure and if it does have proper structural markup > depending on context as appropriate, I see no harm. In fact it is better for > WCAG 2. And Setting role=alert on a UL/OL or H-tag does not change the > semantics of those tags. yes it does as per the ARIA spec the alert role overrides the native host language role. They are still lists or headings or whatever. > So perhaps it will help to clarify why such a restriction is needed in the > first place. In fact I plead that this constraint be removed. > > Here is an example of role=alert that works quite well and is AT supported > on FF, IE9/10 and OSX > http://mars.dequecloud.com/demo/form-alert2.htm > Thanks and regards, > Sailesh > > [1] > http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native- > semantics > [2] http://www.w3.org/TR/wai-aria/roles#alert suggested alternatives: <h1 aria-live="assertive">heading text</h1> <h1> <span role="alert">heading text</span></h1> <ul aria-live="assertive">...
Well I could make the validator error go away if I put the UL tag in a div and placed role=alert on the DIV tag innstead of the UL tag. I get the same functionality but that is more code that I have to insert needlessly. The role=alert does not change the semantics of the UL tag like role=navigation or role=menubar etc. So it does not make sense to insert a div tag or not use <ul role=alert> === Sailesh
(In reply to Sailesh Panchang from comment #2) > Well I could make the validator error go away if I put the UL tag in a div > and placed role=alert on the DIV tag innstead of the UL tag. > I get the same functionality but that is more code that I have to insert > needlessly. The role=alert does not change the semantics of the UL tag like > role=navigation or role=menubar etc. > So it does not make sense to insert a div tag or not use <ul role=alert> > > === > Sailesh this is incorrect as per the ARIA spec[1] and as per what is exposed in accessibility APIs, depending on AT and browser used headings/lists roles are ignored as the heading/list roles are overridden by role=alert So it does not make sense to insert a div tag or not use <ul role=alert> testing shows otherwise. try this simple test case: https://www.dropbox.com/sh/j7389jjoecghf0d/LtNgHsgOAi using an object inspection tool suach as inspect.exe or aViewer. When role=alert is present on an element the native role is overriden. [1]http://www.w3.org/TR/wai-aria/host_languages#host_general_conflict "When a WAI-ARIA role is provided, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic"
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: rejected Change Description: no chnage Rationale: The ARIA spec requires users agents to override native semantics when an ARIA role is present. Testing with object inspections tools to view the roles exposed when role=alert is present on an element showed that the native semantics are replaced by the ARIA semantics. Testing in AT showed that in cases where the AT used an accessibility API to access role information an elements native role was not announced or included in navigation.
Steve, I got to the Bugzilla page from the HTML validator 'Report Feedback' link. In the component drop down I did not see ARIA. So I did not change it. And as the validation page says this is an experimental feature for validation, etc. I thought maybe this is how it is categorized. Even now the closest is 'Using ARIA in HTML'. So I have changed it to this now. Regards, Sailesh