Aria-practices: Review section on role presentation

[mcking65]

Please review this new
section describing the presentation role.

Requested reviews

• [x] Review by @jongund
• [x] Review by @annabbott

[annabbott]

Suggested edit:
"Assistive technologies will thus be unaware of the list item elements and see the tab elements as immediate children of the tablist."
Change to:
"Assistive technologies will thus be unaware of the list item element semantic and see the tab elements with a role of tab as immediate children of the tablist."

[annabbott]

Not good to use the term as it's definition, so suggested edit:
"1. Hiding a presentational image."
Change to:
"1. Hiding a purely decorative image. The same result can be achieved using null alt text."

[annabbott]

Suggested edit:
"2. Suppressing semantics of a layout table."
Change to:
"2. Suppressing semantics of a layout table, where table semantics provide no meaning and column and/or row headers are not relevant."

[annabbott]

The following is confusing:
"1. Browsers ignore the presentation role and it therefore does not affect how assistive technology users perceive the element if either:

the element is focusable.
The element has any of the twenty-one global ARIA states and properties , e.g., aria-label."

Does that mean the browser doesn't honor role="presentation"?

If you choose to retain the original text, then both bullets need to either start with a capital letter or both bullets need to start with a lower case letter.

[annabbott]

Target needed for link in following sentence:
"The presentation role examples page illustrates the effects of these rules in a variety of scenarios and provides more detailed explanations of the rationale behind them. "

It currently directs to a 404 file not found error.

[jongund]

CHANGE:
For example, consider a tablist built using an HTML ul element.
TO:
For example, consider a tablist widget built using an HTML ul element.

I also think it would be good to enclose "tablist" in a code element, it will sand out visually.

[jongund]

I suggest a little restructuring of the items to make some of the rule visible in the TOC and as headings.

6.1 Presentation is ignored for focusable Items and global ARIA attributes
Browsers ignore the presentation role and it therefore does not affect how assistive technology users perceive the element if either:

• The element is focusable, e,g. a element, tabindex attribute is defined.
• The element has any of the twenty-one global ARIA states and properties , e.g., aria-label.

6.2 How Presentation changes content to assistive technologies
If presentation is not ignored the following is how content changes to assistive technologies:

• The element’s implied ARIA role and associated ARIA states and properties are hidden from assistive technologies.
• Text contained by the element and all its descendant elements remains visible to assistive technologies except including the ALT text of an image, unless the text is explicitly hidden using the CSS property display: none, HTML5 hidden attribute or has aria-hidden="true".

6.3 When Presentation is inherited
The roles, states, and properties of all descendant elements remain visible to assistive technologies except when the descendant element is a required part of the presentational element. This feature is designed to reduce the amount of markup required of an author to change the semantics of roles with parent/child dependencies(e.g. TABLE, OL, UL).

For example:

• The descendant LI elements of an UL or OL element with role=presentation.
• The descendant TH, TD, CAPTION, THEAD, TBODY, TFOOTER, TR, COL and COLGROUP elements of a TABLE element with role=presentation. NOTE: Note that a TABLE contained in the TD element of a TABLE with role presentation does not inherit the presentation role because the nested table is not a required part of the presentational table.

[jongund]

Matt the previous edits I think provide more concrete examples to an author and also makes the "rules" visible as headers. Hope this helps.

Jon

[mcking65]

@annabbott and @jongund, thank you very much for the feedback. I have incorporated most of it.

@jongund, I played with the idea of changing the format to one that breaks the rules into several separate sections like you have suggested. To me, it does not seem to add clarity or improve brevity. And, I question whether there is benefit to having the rules themselves in the TOC. Attempting to capture the essence of the rule in a headline can create ambiguities that cause a potentially incorrect understanding to stick.

[jessebeach]

Suggesting edit: "The roles, states, and properties of descendant elements remain visible to assistive technologies except for the descendant elements that can only exist in the context of the presentational element."

Change to: "The roles, states, and properties of descendant elements remain visible to assistive technologies except for the descendant elements that require an ancestor element with a specific role."

[mcking65]

The roles, states, and properties of descendant elements remain visible to assistive technologies except for the descendant elements that require an ancestor element with a specific role.

@jessebeach, I kind of like the form you suggest better, but need to make it accurate in this case:

<ul role="presentation">
  <li>
    <table>
      <tr>

The descendant tr requires a specific ancestor role but it will not be presentational because it does not require the role of the ancestor that is marked presentational.

And in this case:

<ul role="presentation">
  <li id="1">
    <ul>
      <li id="2">

In this case, li 1 is presentational and li 2 is not. They both require the specific implied ancestor role of list.

But, when I fix this issue, I get back to nearly the same statement I previously had:

The roles, states, and properties of descendant elements remain visible to assistive technologies except for the descendant elements that must be contained in the presentational ancestor.

Is that better than the original:

The roles, states, and properties of descendant elements remain visible to assistive technologies except for the descendant elements that can only exist in the context of the presentational element.

[tatermelon]

What if you try switching the subject to the descendant elements? Something like:

The descendant elements maintain their roles, states, and properties unless they require the context of the presentational element.

[jongund]

I think the current wording reads more like a spec than authoring guidance for people trying to learn this stuff. I don't think calling the concepts rules is very inviting to people trying to learn this stuff, the more straight forward we can make it the easier it will be for them to understand the basic principles of using "presentation". In this case two important concepts "presentation" is ignored when an item is focusable or has gloabla properties and states, and second "presentation" can be inherited by other elements with default semantics. So these should be headers in my opinion.
Als the inheritences examples should focus on the HTML elements and not the role values, since it is only

[jongund]

The update looks really good, thanks for all your work

[jongund]

The menu button, menu and tree examples with links now use role="none" in the examples, so you can point to them it you want

[jessebeach]

The roles, states, and properties of descendant elements remain visible to assistive technologies except for the descendant elements that must be contained in the presentational ancestor.

No, it's still not there. I'm confused because it makes me think that ancestor elements that had a role and are then marked as "presentation" now have required descendants. It implies that presentational elements have required descendants.

At least for a table, isn't the situation the same as me putting a <tr> tag on the page without a <table> in its ancestor chain? The <tr> is required to be contained in a <table>. A <tr> is not required to be contained in a presentational ancestor.

[mcking65]

Thank you all for the reviews of this section.

I dreamed of making presentation so straight forward anyone will understand it in a matter of a couple of minutes. what a dream. Even though I didn't quite achieve that lofty ambition, I think it is close enough that I can consider this section done for now.
Completing the example page
should lend clarity even if it increases the amount of time one must invest to fully comprehend.