W3C home > Mailing lists > Public > public-aria@w3.org > May 2016

Re: Action 2044

From: Richard Schwerdtfeger <richschwer@gmail.com>
Date: Wed, 4 May 2016 09:53:26 -0500
Cc: Rich Schwerdtfeger <schwer@yahoo.com>, Fred Esch <fesch@us.ibm.com>, Joseph Scheuhammer <clown@alum.mit.edu>, ARIA Working Group <public-aria@w3.org>, SVG-A11y TF <public-svg-a11y@w3.org>
Message-Id: <5D3E90FC-46EF-4E93-9B23-5C90BCBD84B4@gmail.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>

> On May 3, 2016, at 9:14 PM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote:
> 
> Some general comments:
> 
> 1)
> I don't like calling this "Overriding Presentational Roles".  That suggests that presentational roles are there by default and the author is intentionally over-riding them.  That's not what we're describing: we're describing cases where an author-supplied role of presentation/none is invalid and ignored.
> 
> I would change the heading to something like "Conflicts with Other Element Semantics" or "Incompatible Use of Presentational Roles".  The first paragraph could then be something like:
> 
> "The presentational roles only neutralize implicit semantics from the host language. There are a number of ways in which author-supplied semantics, including other WAI-ARIA attributes, can cause an explicit or inherited presentational role to be invalid and therefore ignored."
> 

I don’t completely agree with that. At times, as an author, I am intentionally overriding a presentational role for a reason. Other times I am invalidating the presentational role by doing something like making it focusable or by applying a global attribute. 

Perhaps “Changing presentational role semantics”? 

> 
> 2)
> I would still prefer that this be a stand-alone section, rather than tucked into the description of the presentation role.  The section is long enough.  It may now have a link-able ID, but it doesn't show up in the table of contents.
> 
> It seems to me it is more equivalent to the section on conflicts with host language semantics, although in this case we are also discussing conflicts between different types of ARIA semantics. 
> 

I had it as a stand alone section and it did not flow properly. Joanie and I don’t believe it should be moved. We agree the section is too long and Joanie has stated she would simplify it. I don’t know if we will do that for ARIA 1.1. I will raise a separate issue for this. The role of presentation was long in ARIA 1.0 and it was very hard to achieve concensus on the wording.

> 
> 3)
> Does this section also apply to elements that are presentational because of an ancestor with a "children are presentational" role? If so, it should be clearly stated.  If not, we need rules elsewhere for what to do if there are interactive elements as a child of a button, img, or similar role.
> 

Yes. It says so in the second sentence and this was in the specification before:

"Explicit roles on a descendant or owned <https://rawgit.com/w3c/aria/action2044/aria/aria.html#dfn-owned-element> element override the inherited role of presentation, and cause the owned element to behave as any other element with an explicit role.”

> 
> 4)
> Does this section also apply to elements that are presentational because of host native semantics (e.g., a <span>)? What role gets applied if global ARIA attributes or interactivity force such an element to be included?
> 
Good point. It does. This is new for ARIA 1.1 and HTML 5.1 since ARIA 1.0 assume no implicit native host language semantics. I think I have to look at the entire presentation role for this to make sure it is indeed covered. 

> 
> On 26 April 2016 at 14:59, Rich Schwerdtfeger <schwer@yahoo.com <mailto:schwer@yahoo.com>> wrote:
> I modified the role=“presentation” section to separate out the overriding of role “presentation” so that it may be referenced by the SVG and Core AAMs:
> 
> https://rawgit.com/w3c/aria/action2044/aria/aria.html#override_presentation_none <https://rawgit.com/w3c/aria/action2044/aria/aria.html#override_presentation_none>
> 
> Let me know if you have any issues.
> 
> Rich
> 
> Rich Schwerdtfeger
> Round Rock, TX
> 
> 


Received on Wednesday, 4 May 2016 15:00:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:26 UTC