Re: Argument for keeping proposed ARIA caption and legend roles separate

Hi Jon,

 

Again, while I mentioned on the call I’m in favor of a single role, as I said in my previous email I’m not as concerned about that, as much as I am about the fact that the definitions for these roles are different, especially regarding the bullet points I listed.

 

From: "Gunderson, Jon R" <jongund@illinois.edu>
Date: Friday, September 6, 2019 at 5:02 PM
To: Scott O'Hara <sohara@paciellogroup.com>, ARIA Working Group <public-aria@w3.org>
Subject: RE: Argument for keeping proposed ARIA caption and legend roles separate
Resent-From: <public-aria@w3.org>
Resent-Date: Fri, 06 Sep 2019 21:02:20 +0000

 

Scott,

 

I am one of the authoring advocates in the group, so anything we can do to be less confusing to authors the better.

 

Role names like ASSOCIATIONLIST is designed to be less familiar to authors to keep them for using the role at all.

 

Authors already are confused about how to use ARIA and we all know there is a lot of bad ARIA in the wild.

 

That said I think the CAPTION and LEGEND labeling techniques are really important and will be used a lot by developers, so authors can use more natural ways to label grouping and tabular roles, without having to use aria-labelledby or aria-label.

 

So if we want authors to think more like programmers then we can use just one role, but if we want authors to use more familiar terms and concepts from the HTML spec then I vote we keep the two roles, even if they programmatically do similar things for albeit different sets of roles.

 

Jon

 

 

 

From: Scott O'Hara <sohara@paciellogroup.com> 
Sent: Friday, September 6, 2019 3:19 PM
To: Gunderson, Jon R <jongund@illinois.edu>; ARIA Working Group <public-aria@w3.org>
Subject: Re: Argument for keeping proposed ARIA caption and legend roles separate

 

Hi Jon,

 

To be perfectly honest, I’m less concerned with there being two roles as I do think you have a point about authors expecting parity between a role’s name and an HTML element’s equivalent.  That said, group/radiogroup but no fieldset role.  Caption role, but not figcaption for figure.  Associationlist but not descriptionlist.  Role=term maps to HTML’s dfn, but role=definition is related, but different.  That’s not meant to be a comment to disparage the effort that went into naming these roles, nor am I ignorant to some of the reasoning. My point here being that ARIA and HTML haven’t had to 100% match before, and there are definitely some things I just mentioned that may initially be a bit confusing to authors. So I’m wondering if this is really where the line in the sand should be drawn? 

 

Regardless, I’m more concerned with the current differences in the definitions between caption and legend. They should largely be the same, save for some differences regarding their parent role: 
In HTML legend and caption should be the first child element of the parent they’re naming. Parity should likely be kept here.
However, regarding a figure’s figcaption, it can be either the first or last child element, creating a different allowance between how role=caption should be used in context of a role=figure vs table, grid, treegrid... 
Additionally, legends are not inherently clickable in HTML, so I’m still wondering why that’s in role=legend’s definition as that seems the reason why these might have diverged?
 

Glad to hear any additional thoughts on this.

 

Thanks

 

 

From: "Gunderson, Jon R" <jongund@illinois.edu>
Date: Thursday, September 5, 2019 at 5:47 PM
To: ARIA Working Group <public-aria@w3.org>
Subject: Argument for keeping proposed ARIA caption and legend roles separate
Resent-From: <public-aria@w3.org>
Resent-Date: Thu, 05 Sep 2019 21:46:59 +0000

 

I would just like to comment on the proposed caption and legend roles and the idea of using a single role.

 

We have the HTML spec that has already defined caption and legend elements for providing labels and we have some accessibility APIs that also have legend and caption roles.

 

But in ARIA we are going to say the semantics and the history of these two roles is not relevant and we will just merge them into one role.

 

While I agree programmatically they are doing the same or similar things, so it seems like a way to eliminate some work for ARIA to do.

 

But I think it will look strange for the role we eliminate and confuse authors to see only one of these roles available to them.

 

We can argue that HTML should not have used two roles in the first place and maybe accessibility APIs shouldn’t have either, but they did.

 

So I don’t think ARIA should try to merge them, keeping them separate will provide clearer mappings to accessibility APIs and support naming conventions that authors are already familiar with.

 

Jon

 

Jon Gunderson, Ph.D., CPWA

Coordinator of Accessible IT Group

University of Illinois at Urbana/Champaign

1207 S. Oak Street

Champaign, IL 61820

 

www: https://go.illinois.edu/jongund