Skip to content

Commit

Permalink
first draft addressing Issue #500
Browse files Browse the repository at this point in the history
  • Loading branch information
@cookiecrook
cookiecrook committed Jun 15, 2017
1 parent 0a57d38 commit b6d1810
Showing 1 changed file with 4 additions and 11 deletions.
15 changes: 4 additions & 11 deletions aria/aria.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10308,17 +10308,10 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
<p>[ARIA 1.1] Defines a human-readable, author-localized description for the <a>role</a> of an <a>element</a>.</p>
<p>Some <a>assistive technologies</a>, such as screen readers, present the role of an element as part of the user experience. Such assistive technologies typically localize the name of the role, and they may customize it as well. Users of these assistive technologies depend on the presentation of the role name, such as "region," "button," or "slider," for an understanding of the purpose of the element and, if it is a widget, how to interact with it.</p>
<p>The <code>aria-roledescription</code> property gives authors the ability to override how assistive technologies localize and express the name of a role. Thus inappropriately using <code>aria-roledescription</code> may inhibit users' ability to understand or interact with an element. Authors SHOULD limit use of <code>aria-roledescription</code> to clarifying the purpose of non-interactive container roles like <rref>group</rref> or <rref>region</rref>, or to providing a <em>more specific</em> description of a <rref>widget</rref>.</p>
<p> When using <code>aria-roledescription</code>, authors SHOULD also ensure that:</p>
<ol>
<li>The element to which <code>aria-roledescription</code> is applied has a valid <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role or has an implicit WAI-ARIA role semantic.</li>
<li>The value of <code>aria-roledescription</code> is not empty or does not contain only whitespace characters.</li>
</ol>
<p>User agents MUST NOT expose the <code>aria-roledescription</code> property if any of the following conditions exist:</p>
<ol>
<li>The element to which <code>aria-roledescription</code> is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.</li>
<li>The value of aria-roledescription is empty or contains only whitespace characters.</li>
</ol>
<p><a>Assistive technologies</a> SHOULD use the value of <code>aria-roledescription</code> when presenting the role of an element, but SHOULD NOT change other functionality based on the role of an element that has a value for <code>aria-roledescription</code>. For example, an assistive technology that provides functions for navigating to the next <rref>region</rref> or <rref>button</rref> SHOULD allow those functions to navigate to regions and buttons that have an <code>aria-roledescription</code>.</p>
<p>User agents MUST NOT expose the <code>aria-roledescription</code> attribute if the value of aria-roledescription is empty or contains only whitespace characters.</p>
<p>If <code>aria-roledescription</code> is applied to a generic or semantically <em>meaningless</em> presentational element (for example, <code>div</code> or <code>span</code> in HTML), user agents SHOULD NOT expose <code>aria-roledescription</code> unless the author also defines an explicit WAI-ARIA role value.</li>

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 15, 2017

Contributor

I'm ok with this, but I have a couple of concerns:

  1. Without defining "semantically meaningless," are we in danger of different user agents defining this differently.
  2. SHOULD NOT is, of course, not MUST NOT. So we may be in danger of different user agents doing different things. By the same token, I don't see how we can turn it into a MUST without a clear definition of "semantically meaningless."

So, IF we can come up with a definition of "semantically meaningless" (or come up with an alternative phrase, list of elements, or something which makes it 100% clear which elements we're talking about), would you be ok with turning the SHOULD NOT into a MUST NOT?

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 15, 2017

Author Contributor

I think that definition would be solved by addressing #525. Short of that, I don't know of a better way to define it.

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 15, 2017

Author Contributor

Re: should not vs must not: If you think you can get the definition explicit enough to exclude div/span without excluding the rest of the HTML/SVG/etc elements with potential (including custom elements), then yes.

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 15, 2017

Author Contributor

also, should we make an exception for generics that have mouse or keyboard event handlers? what about focusable generics?

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 15, 2017

Contributor

Addressing #525 won't happen until ARIA 1.2.

I don't think we should make an exception for generics that have mouse or keyboard event handlers or are focusable. That might encourage authors to not provide a role for interactive content, and ATs would then have no idea what the thing is.

Are all the "semantically meaningless" elements "textual elements" or "text containers"?

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 15, 2017 •
edited
Loading

Contributor

Rich (during meeting) mentioned "host language interactive controls" as a category of things which might not have an explicit or implicit ARIA role, but which should still permit roledescription.

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 16, 2017

Author Contributor

Are all the "semantically meaningless" elements "textual elements" or "text containers"?

Not necessarily. In #500, I gave three examples: <fieldset>, <meter>, and <code>. Out of those, I think only <code> fits your criteria definition of text containers.

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 16, 2017

Contributor

Seeing that you +1'ed Rich's suggestion, could you revise your proposal to use his language -- and if you feel it's clear enough, s/SHOULD/MUST/ so all the user agents are doing the same thing. Thanks!!

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 16, 2017

Author Contributor

I don't think the use cases are limited to "interactive controls" so I'd be hesitant to use that language. The "thumbs up" was because I was pleased Rich seems to agree with the general utility of this change.

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 16, 2017 •
edited
Loading

Author Contributor

e.g. the <code> example mentioned #500 is pretty solid use case, but is not an "interactive control."

What if this was described as "JavaScript code":

foo > x

And this was described as "CSS code":

div > p

Notice the different syntax highlighting?

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 16, 2017 •
edited
Loading

Contributor

Fair enough. But could the <code> (and similar) situations be addressed as part of 1.2's role/element parity?

Why things like <meter> concern me (and why I think it's worth addressing as part of 1.1) is that the way the spec currently reads, an author has two choices:

  1. Slap a role on the meter just to get their roledescription to work
  2. Not use a roledescription

My guess is that they would do the former. In doing so, things may seem to work (e.g. screen reader says "speedometer" or "pedometer" instead of "meter"). However, what role do they pick?

  1. Something pretty close to being right (e.g. progressbar)
  2. Something nowhere near to being right (e.g. group)

If authors pick the former, ATs might get a tad confused (on my platform, progress bar is ATK_ROLE_PROGRESS_BAR; meter is ATK_ROLE_LEVEL_BAR). BUT if authors pick the latter, we're in danger of losing the accessible value interface/pattern/properties necessary to present the accessible element correctly because the "group" role doesn't support valuemin, valuemax, valuenow, valuetext, etc.

But for something like <code>, authors can slap a "group" role on it and arguably be correct and not break anything by doing so because <code> doesn't have any properties or states or special interfaces that the "group" role lacks (right?).

Long way of saying: I fear the current spec language may cause authors to do things which make interactive elements less accessible, because ATs won't know what those interactive elements are or have access to the interaction-specific properties, states, and values. Non-interactive elements won't be broken and can be given roledescription values by using the "group" role until we achieve role/element parity in 1.2.

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 19, 2017 •
edited
Loading

Author Contributor

My guess is that they would do the former (add role to meter). In doing so, things may seem to work

"Seem to work" is the key point here.

But for something like <code>, authors can slap a "group" role on it and arguably be correct and not break anything by doing so because <code> doesn't have any properties or states or special interfaces that the "group" role lacks (right?).

I'm not willing to make that assumption. We've talked about potentially changing speech verbosity or pronunciation based on type (type=tel) or engine role (code), so I think it would be unwise to bake that assumption into a spec.

Long way of saying: I fear the current spec language may cause authors to do things which make interactive elements less accessible…

I have the same concern about all elements, not just the interactive ones.

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 20, 2017

Contributor

Do you have any additional proposed changes to make for the group's consideration? If we're going to exit and re-enter CR, we really should do so soon.

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 20, 2017

Author Contributor

Are you speaking of more changes related to this issue, or are you opening it to other issues?

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 20, 2017

Author Contributor

A conceptually related issue to discuss is #529.

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 20, 2017

Contributor

Are you speaking of more changes related to this issue, or are you opening it to other issues?

I meant the former. Though I'm willing to consider low-risk, high-impact, easy-to-sell-to-the-working-group changes. That said, I am not convinced #529 falls into the category (though if you are, please email the public-aria list as I've not yet written the agenda for Thursday's meeting and am happy to add it as an agenda item).

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 20, 2017 •
edited
Loading

Author Contributor

I agree #529 fits better in a later milestone.

Do you have any additional proposed changes [related to this issue] to make for the group's consideration?

Not that I am currently aware of. If you think something is vague, missing, or potentially controversial, I can attempt to rephrase.

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 20, 2017

Contributor

Not that I am currently aware of. If you think something is vague, missing, or potentially controversial, I can attempt to rephrase.

If the rest of the group is ok with your changes as they are, then I will not stand in the way. But in the previous meeting discussion, no one seemed to embrace "semantically meaningless" (because it is vague).

I myself am not happy with the "SHOULD NOT" -- though as stated before, without defining "semantically meaningless" we can't really turn that into a "MUST NOT."
<p>If <code>aria-roledescription</code> is applied to a semantically <em>meaningful</em> host language element whose implicit role semantic is not defined by WAI-ARIA, user agents SHOULD expose <code>aria-roledescription</code>, even if the author does not provide an explicit WAI-ARIA role value.</li>

This comment has been minimized.

Sign in to view

Copy link
@joanmarie

joanmarie Jun 15, 2017

Contributor

Ditto.

This comment has been minimized.

Sign in to view

Copy link
@cookiecrook

cookiecrook Jun 15, 2017 •
edited
Loading

Author Contributor

I think the formal definition is less critical here, but it might be addressed as "not generic" e.g. anything that does not match the role defined by #525
<p><a>Assistive technologies</a> SHOULD use the value of <code>aria-roledescription</code> when presenting the role of an element, but SHOULD NOT change other functionality based on the role of an element that has a value for <code>aria-roledescription</code>. For example, an assistive technology that provides functions for navigating to the next <rref>region</rref> or <rref>button</rref> would allow those functions to navigate to regions and buttons that have an <code>aria-roledescription</code>.</p>
<p>The following two examples show the use of <code>aria-roledescription</code> to indicate that a non-interactive container is a "slide" in a web-based presentation application.</p>
<pre class="example highlight">&lt;div role="region" aria-roledescription="slide" id="slide42" aria-labelledby="slide42heading"&gt;
&lt;h1 id="slide42heading">Quarterly Report&lt;/h1&gt;
Expand Down

1 comment on commit b6d1810

@jnurthen
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can take this up again now we have the generic role

Please sign in to comment.