This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23888 - Not allowing role=alert on UL / OL / LI / H- tags. etc. is a needless constraint
Summary: Not allowing role=alert on UL / OL / LI / H- tags. etc. is a needless constraint
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Using ARIA in HTML (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: steve faulkner
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-22 17:17 UTC by Sailesh Panchang
Modified: 2014-07-22 22:08 UTC (History)
5 users (show)

See Also:


Attachments

Description Sailesh Panchang 2013-11-22 17:17:48 UTC
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
Comment 1 steve faulkner 2013-11-23 09:50:59 UTC
(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">...
Comment 2 Sailesh Panchang 2013-11-24 00:20:37 UTC
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
Comment 3 steve faulkner 2013-11-24 10:25:14 UTC
(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"
Comment 4 steve faulkner 2013-11-24 10:29:39 UTC
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.
Comment 5 Sailesh Panchang 2013-11-25 17:49:53 UTC
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