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

I type role="image" often. Having a synonym would be a huge time saver in
debugging. 🤦‍♂️

On Fri, Sep 6, 2019 at 7:39 PM Scott O'Hara <sohara@paciellogroup.com>
wrote:

> I’d imagine that would be exactly what we should do, if we were to keep
> both roles.  So yes, 100% agree Matt ☺
>
>
>
> *From: *Matt King <a11ythinker@gmail.com>
> *Date: *Friday, September 6, 2019 at 7:02 PM
> *To: *'Scott O'Hara' <sohara@paciellogroup.com>, "'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
> *Resent-From: *<public-aria@w3.org>
> *Resent-Date: *Fri, 06 Sep 2019 23:02:11 +0000
>
>
>
> Reminder that another way to help authors is with a synonym. None was
> added as a synonym of presentation to help authors.
>
>
>
> We could have a caption role and define legend as a synonym.
>
>
>
>
>
> I still think we should add image as a synonym of img not to match HTML
> convention, obviously, but to be more consistent within aria where we have
> avoided abbreviations in role names.
>
>
>
> Matt
>
>
>
> *From:* Scott O'Hara <sohara@paciellogroup.com>
> *Sent:* Friday, September 6, 2019 3:12 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,
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__go.illinois.edu_jongund&d=DwMFaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=9I76s_DQeMyePDM1NLeRmzQO75RtgjJ9Clf1LQyt7-I&m=ofooc3Zp3mXm6um55Zg0Vex0s4ZIZE5et5Q-3AQ_ZeI&s=K2ynzXgtITN61QW3I-Q2eRKaQvL584JQtyWXWKqhHAI&e=>
>
>
>


-- 
Scott Vinkle
Web accessibility advocate
Shopify