search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
638 stars 123 forks source link

method to determine how blocks of text are separated (aria-text separation (property)) #699

Open joanmarie opened 6 years ago

joanmarie commented 6 years ago

As part of achieving role parity with HTML, we will need to create at least one generic role.

joanmarie commented 6 years ago

The exact nature of the role(s) will be influenced by the input we receive from stakeholders responding to the HTML element/role-parity triage. Thus adding the "blocked" label for now.

cookiecrook commented 6 years ago

Dupe of #525

joanmarie commented 6 years ago

I think #525 may prove to be a subset of this issue, but ok.

joanmarie commented 6 years ago

Actually, I'm re-opening because #525 may prove to be a subset of this issue.

We're taking a different approach to triaging and tackling these roles, and I'm reserving the right to open new broader issues such as this one. I, of course, don't want to immediately close out old issues which have discussion. So there may be duplicate issues. I promise to clean things up in the end. Hope that's ok. :smile:

joanmarie commented 6 years ago

Conclusion from the Working Group face-to-face today is that we're going to create two generic roles: inline and block. They will be fleshed out and a pull request will be created.

carmacleod commented 6 years ago

First attempt at fleshing out block/inline roles is in PR https://github.com/w3c/aria/pull/805 in branch issue699-block-inline. Feel free to edit directly in branch as needed.

Reminders for later:

  1. Update "Class diagram of the relationships described in the role data model"
  2. Open PRs for HTML and other specs for new generic mappings
cookiecrook commented 6 years ago

@joanmarie I'm sorry I did not see the decision from May until @carmacleod's PR went in, but I think this is a serious mistake. It's unfortunate that the original issue #525 was closed in favor of this one, because more of the discussion (and my defense of a single "generic" role) happened there.

My main objection is that this conflates an ARIA role with a style (display: inline vs display:block). Separation of content (usually markup) from presentation (usually CSS) is widely understood to be a good thing for the Web, so I'm at a loss to understand why the working group wants to two new entirely style-based roles.

My best guess is that it's caused by a misunderstanding of how these are represented by user agent implementations. Screen readers treat block and inline elements differently, and I know members of the WG don't want to lose this functionality, but I don't believe that's at risk. WebKit and Blink (maybe other user agents too) expose differences in these generic elements because they are styled differently, not because the element is tied to a block or inline role. Therefore a single generic role would work for both, and user agents can still expose any presentational relevance (block, inline, bold, italic, underline, etc) without adding presentational roles to the ARIA role hierarchy.

Adding some other implementors in case they know of an implementation reason we would need style-based roles. @aleventhal @asurkov @minorninth @alice @hober @dwsinger

cookiecrook commented 6 years ago

The best suggestions I saw in Issue #525 were these two:

I'd prefer either of those to adding style-based ARIA roles.

carmacleod commented 6 years ago

I'll admit that it did feel weird to try coming up with words for inline and block roles. :) Adding @mcking65 and @jnurthen to the discussion.

mcking65 commented 6 years ago

@cookiecrook, I know we had a role vs attribute discussion at the meeting in Toronto in May, and I do not clearly recall the reasons we landed on role. You can see in the minutes for May 1 that I raised the possibility of an attribute. I honestly believe there was a good reason for going with role instead of attribute. I do not recall going in with a strong opinion on that point. I didn't leave with one, but I remember the decision as rational, not arbetrary. So, we may need to do some more brain-digging on that point so we can at least document it, and, per your request, revisit it.

However, One point where we are not connecting is on the "presentation" vs "semantics" issue. I think it would beneficial if we could sort that out.

If I understand correctly, You do not support having two roles, but you could support a property that distinguishes between elements that should be treated as blocks and elements that should be treated as inline. And, this is because roles should not be used to represent style. In issue 525, you wrote:

We don't need separate role mappings for inline-vs-block generics. The rendering engines can remap the generics based on display if necessary.

and, in this issue you wrote:

My main objection is that this conflates an ARIA role with a style (display: inline vs display:block). Separation of content (usually markup) from presentation (usually CSS) is widely understood to be a good thing for the Web

I would 100% agree if the types of presentation did not have semantic significance. However, the types of presentation we are talking about completely change meaning and understandability. That is why browsers occasionally, and frequently differently, remap based on style in an attempt to correctly represent the meaning the author is conveying. Unfortunately, that remapping based on style goes wrong as or more often than it goes right. So, it is imperative that we give authors a way to explicitly declare the semantics that is independent from styling.

On Windows, span has historically had the strongest semantics because, regardless of styling, all versions of Chrome, Firefox, and IE render span in exactly the same way when read by any version of either NVDA or JAWS. 

<p>The following 3 spans are read as the single word, "cat", with any version of either JAWS and NVDA using any version of Chrome, Firefox, or IE:</p>
<span>c</span><span>a</span><span">t</span>
<p>The following 3 block style spans are read as a single word, "cat", with any version of either JAWS and NVDA using any version of Chrome, Firefox, or IE:</p>
<span style="display:block">c</span><span style="display:block">a</span><span style="display:block">t</span>

The default treatment of div as a block element has been just as essential to understandability. A stunning amount of content on the internet would be become unintelligible by screen reader users if the representation of spans and divs were to change.

In other words, there are accessibility semantics associated with inline and block styling. While you have pointed out that this is historically the consequence of an implementation detail in browsers, that does not remove the fact that authors have both intentionally and unintentionally relied upon those implementation details for their semantic consequences. From my perspective, turning those side effects of implementation into explicit first-order effects is one of the primary objectives of this issue. The fact that we have not had explicit ways to declare block and inline semantics independent of style has created real problems in some browsers.

That said, if the rest of the group is open to reconsidering the role verses attribute decision, this would become a mute point if the decision were to change. While I would be more comfortable if we had consensus on both the rationale behind the specification and the actual specification, mostly because that rationale effects pedagogy, I grant that consensus on rationale is a nice-to-have.

carmacleod commented 6 years ago

semantics: read blocks separately; read inlines run together

cookiecrook commented 6 years ago

Matt's comments seem to confirm this decision was made based on the current interaction of Windows-based browser+screen readers combinations. As mentioned in #525, its the opposite behavior of the Mac browser+screen readers combinations. That and my other objections seem to confirm this is worthy of revisiting.

jnurthen commented 6 years ago

@cookiecrook My opinion is that we should let browsers determine if an element should be inline/block using their internal rules but we should provide an ability in ARIA for a developer to override the browser and state that an element really should be either inline or block. Do you agree with this?

cookiecrook commented 6 years ago

Conceptually, I sort of agree, but definitely not as a role, and definitely not as the values 'inline and block... Those two come with CSS display baggage. What happens when we need an inline-block behavior? Or a block flow, or a flex run-in? Check out all the display values on MDN and I hope you'll agree it should not use these terms.

cookiecrook commented 6 years ago

I think it's reasonable for the WG to consider a feature that indicates whether element breaks are considered meaningful. Is the purpose of this limited to whether or no screen reader speech is continuous, or is there another benefit to other types of Assistive Tech?

AmeliaBR commented 6 years ago

definitely not as the values 'inline and block... Those two come with CSS display baggage.

I am a strong supporter of having two generic roles which reflect the normal inline vs block semantics of HTML elements, and the presumed whitespace/line-breaks that come with them. However, I agree with @cookiecrook that using the CSS terms is problematic, because the CSS can be overridden, and has hybrid layout options like inline-block.

I'd suggest looking instead to the HTML terminology.

The "inline-by-default" HTML elements are called "phrasing content", so maybe the "span" role could be phrase ? Although span as a role name works, too (and would be more recognized by authors), if people don't think it's confusing to have other phrasing elements map to role=span with extra formatting exposed.

For the "block" role, there isn't a clear term in HTML. But when you look at the list of elements that are default block-layout in HTML, the only non-deprecated ones that don't have a more specific role are address, div, and p.

If p is going to map to a specific new paragraph role (as I believe it should), maybe the new block-level role can be called division? That makes it clear that the impact of this role is to divide otherwise continuous phrasing flow of content, without being quite as strong as a group. But quite frankly, I'm also happy with group being the default role for div and address when they need to be included in the accessibility tree.

carmacleod commented 6 years ago

So to summarize, we have either separate roles:

  1. role="block" and role="inline" (which have CSS display baggage)
  2. role="div/division" and role="span"
  3. role="structure" (make concrete) ... and role="span"?
  4. role="group" (like structure but supports aria-expanded and -activedescendant) ... and role="span"?

Or single role with attribute (property):

  1. role="generic" and aria-block/aria-inline="true/false" or aria-display="inline/block"
  2. role="structure" (make concrete) and aria-x property as in point 5.

Did I miss any?

Some other possible words that could be used for role or property names:

TBH, I'm a little unclear on why we seem to be leaning towards "two roles" rather than "one role and a property"? Might be slightly more "future proof" to use a property, i.e. easier to add a new property value than a new role?

cookiecrook commented 6 years ago

@carmacleod wrote:

TBH, I'm a little unclear on why we seem to be leaning towards "two roles" rather than "one role and a property"? Might be slightly more "future proof" to use a property, i.e. easier to add a new property value than a new role?

👍 Since the goal seems to be overriding AT element separation behavior (useful on any element or role), it shouldn't be a role.

Did I miss any [options to resolve this feature]?

There are lots of options, but enough members of the WG are convinced this shouldn't be a role, I move to 1) open a new issue for the element separation behavior (which would likely end up as an attribute), and 2) reopen the original issue #525 to address the need for a generic role.

mcking65 commented 6 years ago

Seems like there is some agreement that there are two semantics that have been accidentally or unintentionally imposed by span and div: a block-like semantic that is similar but not identical to paragraph, and an inline semantic that is similar to a string.

Even though there are some differences among browsers that effect whether or not these semantics are perceived by screen reader users, the vast majority of the time, the appropriate semantic is conveyed. This good luck has been supported by a variety of circumstances, including the popularity of particular browsers and screen readers as well as customary usage patterns for div and span.

BTW, @cookiecrook, VoiceOver in Chrome does not work the same as VoiceOver in Safari when reading div and span elements. In Chrome, VoiceOver actually works more like Narrator. VoiceOver in Safari is an outlier. That said, even if you ignore the uniqueness of Safari, most of the time, the appropriate semantic is rendered.

Proposal for minimum requirements to address with new ARIA attributes

Here are the requirements I think we need to address:

  1. New role or attribute mappings should not change how existing content is experienced, specifically:
    1. For div, We need an ARIA expression of default block semantics that browsers are allowed to override during rendering based on visual styling.
    2. For span, We need an ARIA expression of default inline semantics that browsers are allowed to override during rendering based on visual styling.
  2. Authors need a way to override default behavior and explicitly declare a block-like or inline-like semantic that is not changed based on visual styling during rendering.
  3. No inherritance: These semantics apply to child text nodes but not to descendant elements or text nodes contained by descendant elements.

The no inherritance requirement is particularly important. I strongly disagree with the idea that one advantage of a property is that it can be applied to existing roles. I think that is a very dangerous idea that would not just massively complicate the spec and its implementation but eventually lead to unintended side effects. For example, this semantic should not apply to descendants of a group that contains a set of widgets.

The semantics currently expressed by today's treatments of div and span are limited to text nodes and whether or how browsers should combine them in the accessibility tree. Currently, screen readers already have their own methods for how they present elements with any other accessibility semantic. For instance, no matter what screen reader or browser you use, a span containing a set of buttons is presented in the same way as a div containing the same set of buttons. The solution this issue should not attempt to change that.

Another thing to keep in mind is that the resolution to this issue could have consequences for the name calculation and how strings are concatenated. This is especially true for elements that are named from content where that content consists of one or more generic containers that contain text. If the effects of the role or properties we develop for this issue were inherrited by descendants, we'll have yet one more complexity to consider during recursive collection of text for naming.

Another requirement to consider

Consider:

<h1><span>foo</span><span>bar</span></h1>
<a href="..."><div>foo</div><div>bar</div></a>

In circumstances like the above, CSS is used to separate "foo" and "bar" in ways that could lead to either "foo" and "bar" getting lumped together as a single word or separated into two separate elements while the most accessible result would be to have them read as a string of two words "foo bar". However, getting them to be space delimited is actually challenging. It means adding a 3rd element to contain the space or adding space to one of the existing elements. Often, neither of those options is practical.

I think we could solve this issue in a way that gives authors the ability to fix problems like this, which have become extremely common.

Proposal for solution

blob (role)

Generic, nameless grouping container that can be used to specify how child text nodes are presented to assistive technologies.

Superclass: structure No subclasses.

aria-text separation (property)

Indicates the type of separation, if any, that is required between the text nodes contained in the blog and its sibling elements.

If a blob contains one or more text strings, and if any contained strings are at the start or end of the blob, the value of the aria-textseparation property specifies how those text strings will be separated from text strings contained by sibling elements.

Allowed values:

Mappings for div and span

Possible Future Enhancement

We could add a property aria-textseparator that allows the author to specify a string to be used as a text separator. We could add 3 more tokens for aria-textseparation: string, leadingstring, and trailingstring. Thus, it would be possible to add punctuation in situations where the visual presentation connotes something that is not accurately represented by only a space character. Then you could have:

<div><span aria-textseparation="trailingspace">Price:</span><span>$4</span><span aria-textseparation="leadingstring" aria-textseparator=".">99</span></div>
<!-- Rendered to a screen reader as a single text node with value "Price: $4.99". -->
cookiecrook commented 6 years ago

@mcking65, I like where you're headed, with a few mods:

Role: I'm not sure about the role name "blob"… Why do you prefer this over the previously proposed "generic" name?

Attribute: How about aria-whitespace? values could be space, line-break, paragraph-break, none, and inherit.

carmacleod commented 6 years ago

I like the direction, also. This (by either set of names) would solve a long-standing problem.

Although, if AT would look for aria-label on a div, that would solve it, too. :) But they don't - I just tried it with the following:

    <p>Styled spans with aria-label on parent div:</p>
    <div aria-label="Price: $4.99">
        <span>Price:</span>
        <span style="padding-left: 4px;">$4</span>
        <span style="vertical-align: super; font-size: 70%;">99</span>
    </div>

NVDA and JAWS both say "$499" instead of "$4.99" (a significant difference in price that is only apparent visually).

Blob is a very cool name, but maybe it's a bit too "computer jargony"? Maybe generic would be more universally understood?

Regarding attribute, aria-whitespace is easier to understand, but aria-textseparation is more powerful.

@cookiecrook You asked:

Is the purpose of this limited to whether or no screen reader speech is continuous, or is there another benefit to other types of Assistive Tech?

I would guess that voice commands like "Go to cat" or "Select cat" in Matt's "cat example" would benefit.

I tested a version of the cat example on Windows with 2 screen readers in 3 browsers:

The visual rendering is: divs: c, a, t, inline divs: dog, spans: cow, and block spans: p, i, g. Rendered speech generally follows the visual rendering, but the exceptions are wildly inconsistent:

Given that inconsistency, it's obvious that authors need a way to help AT interpret these things.

cookiecrook commented 6 years ago

@mcking65 wrote:

BTW, @cookiecrook, VoiceOver in Chrome does not work the same as VoiceOver in Safari when reading div and span elements.

This is likely because Blink forked from WebKit more than 5 years ago, and hasn't gotten all the same accessibility fixes since then.

In Chrome, VoiceOver actually works more like Narrator. VoiceOver in Safari is an outlier. That said, even if you ignore the uniqueness of Safari, most of the time, the appropriate semantic is rendered.

Testing @carmacleod's cat example in Safari vs Chrome resulted in correct behavior in Safari, but incorrect behavior in Chrome: Chrome renders every element separate, regardless of tag name or style declaration. As such, I think this is likely just a bug in Chrome, rather than any specific intention of Blink's accessibility engineers. In any case, it doesn't match your conclusion that Safari is the only outlier.

carmacleod commented 5 years ago

Here are some new draft words for the generic role, simply to have a basis for discussion.

The idea is that this role will support an as-yet-unnamed attribute (property) that conveys whether text content should be read as discrete chunks or as a continuous, uninterrupted whole.

We discussed calling the generic role container, but unfortunately the word container is used in various contexts all through the spec, which I think may lead to confusion. For example, the Managing Focus section uses it to describe the container element for a composite widget. So, for now, this new draft is using the name generic, with the word "container" in its definition.

HTML divs and spans will both default to role="generic".

The default value of the unnamed attribute needs to be based on the display style if we want the default speech to match the visual rendering (which I think we do?). Authors can obviously override this by explicitly setting the attribute's value.

carmacleod commented 5 years ago

Draft words for aria-textseparation property and its values: inherit (default), line, none, paragraph, space.

See also slight changes to generic role (extra sentence about aria-textseparation in description, and addition of aria-textseparation as supported role).

Notes/Questions:

melanierichards commented 5 years ago

Responses to questions:

I'm kind of throwing a wrench in things here, but as I think about it I'm wondering if it would be more performant, as well as simpler for authors, if this property was added to a wrapper element, rather than to individual nodes that could get concatenated onto anything else in the markup.

For example, this design:

<div role="generic" aria-textseparation="space">
 <div>Price:</div>
 <div>$4</div>
 <div>99</div>
</div>

as opposed to the current design:

<div>
 <div role="generic" aria-textseparation="trailingspace">Price:</div>
 <div role="generic" aria-textseparation="space">$4</div>
 <div role="generic" aria-textseparation="leadingspace">99</div>
</div>

If you place concatenation on the wrapper, the leading and trailing spaces could get handled automatically. I suppose the issues with this are that 1) this property would need to be role-agnostic and 2) maybe there are use cases where there is no natural wrapper element and it would be more crufty (or undesirable from a layout perspective) to add another one.

I also have a couple questions under the current design:

mcking65 commented 5 years ago

@melanierichards commented:

* I think we do need the granular values, `leadingspace` and `trailingspace`, in the current design. The expectation for these probably should be that the UA default is preserved in the direction that is not specified by the author. So if you have `leadingspace` specified, and there would usually be a line break after the element, then it should still be a line break.

I think this is saying the same thing, but just to be certain ...

The implicit value is inherit. So, inherit applies to text nodes at ends of a generic where the author has not overridden aria-textseparation. Thus, if the author specifies leadingspace, the trailing end of that generic has a value of inherit.

@melanierichards commented:

* Probably need a note somewhere about spaces collapsing between elements with `aria-textseparation="space"`, for clarity's sake.

We also need to specify precedence, e.g., paragraph has precedence over line, which has precedence over space, which has precedence over none.

For example, in the following, assume that div is inheriting line and span is inheriting none.

<div>I have line separation from the span that follows.</div>
<span>Even though I inherit separation of none, there is line separation between me and the text node in the prior div.</span>
<span aria-textseparation="space">Even though the span before me has text separation of none, my space separation has precedence so there is a space between me and the previous span.</span>
<div aria-textseparation="paragraph">Even though the span before me has space separation, my paragraph separation has precedence, so there is a paragraph break before me.</div>
<span>Even though I have inheritted separation of none, I have a paragraph break before me and screen reader-determined separation between me and the button that follows because screen readers have their own algorithms for determining how to present the boundries between semantic elements.</span>
<button>When the screen reader navigates to me, it will say I am a button and text separation is thus irrelevant -- I am a semantically separate and distinct object</button>

@melanierichards commented:

I'm kind of throwing a wrench in things here, but as I think about it I'm wondering if it would be more performant, as well as simpler for authors, if this property was added to a wrapper element, rather than to individual nodes that could get concatenated onto anything else in the markup.

For example, this design:

<div role="generic" aria-textseparation="space">
 <div>Price:</div>
 <div>$4</div>
 <div>99</div>
</div>

as opposed to the current design:

<div>
 <div role="generic" aria-textseparation="trailingspace">Price:</div>
 <div role="generic" aria-textseparation="space">$4</div>
 <div role="generic" aria-textseparation="leadingspace">99</div>
</div>

If you place concatenation on the wrapper, the leading and trailing spaces could get handled automatically. I suppose the issues with this are that 1) this property would need to be role-agnostic and 2) maybe there are use cases where there is no natural wrapper element and it would be more crufty (or undesirable from a layout perspective) to add another one.

If aria-textseparation could be inherrited, we would have a serious authoring mess. I definitely could not support that.

@melanierichards commented:

* What happens if the `role="generic"` elements contain children other than text/white space? I imagine that the text separation only applies to the entire generic element as a unit.

More specifically, it applies only to text nodes at the boundaries of the generic container. It has no effect on separation between text nodes and other types of elements inside the generic. And it has no effect on separation between text nodes and other elements that are not text nodes at the boundaries of neighboring generics. The aria-textseparation does only what divs and spans do to current content, which nothing unless the content is text at the boundary of the div or span. For example:

<div>string1</div><img alt="img1"><span>string2</span><button>push me</button>

In the above, aria-textseparation is completely irrelevant because none of the text nodes are adjacent to text nodes. So, if the author specifies aria-textseparation, it should have 0 effect. Screen readers treat each of those elements as semantically separate objects.

* More of a comment but there could potentially be cross-API or cross-AT ambiguities for how to handle text ranges when an element with inherent semantics gets smooshed together with one of these generic elements. So if you have `<a href="http://wikipedia.org">Ca</a> <span role="generic" aria-textseparation="none">t</span>` that would yield a text range `Cat`, but should that be interpreted as a "word" and then potentially the link gets lost? Or because the "word" contains a link, would you get something "Link, 'ca', 't'", despite the author direction to concatenate?

Again, the goal is to exactly replicate the semantic effects of inline and block styling we currently have for spans and divs. We do not want any new or unintended side effects. There should be no difference between how screen readers read that today and how they would read it after aria-textseparation is implemented.

It is important to keep in mind that every screen reader has its own way, or ways, of reading that example. For instance, by default, VoiceOver does not let you navigate inside of link text. So, you will navigate to a "ca link" and then you will navigate to the letter 't'. However, NVDA does things differently. By default, you can navigate across link text and it tells you when you are entering and leaving the link. JAWS is similar, but it has two different modes, and how it separates the "ca" link from the "t" text will depend on the presentation mode.

Net: aria-textseparation must be defined to describe how to separate text nodes from text nodes. It cannot have any other effect or we will be creating a giant can of worms.

mcking65 commented 5 years ago

In PR #805, I propose this definition for generic:

A nameless container element that can confer accessibility properties to its descendants without exposing itself to assistive technologies. (see related group).

I came up with that wording as I was attempting to figure out how we will explain the generic role to authors.

In practice, because it is the default for span and div and since there is likely no reason to use it on any other element, an author will never declare the generic role. I suppose there might be an exception to this when building virtual nodes with AOM, but I'm not clear on that point. I suppose it is possible it might get used in SVG, but I don't know enough about SVG authoring to assess that either.

One aspect of generic elements that I am having difficulty figuring out how to clearly explain is that they are essentially invisible to assistive technology users. For example, assistive technology users do not know when they are navigating out of the content from one span and starting reading content from another span. This is also true of divs, regardless of their styling. The text separation is obviously important, but the element that specifies the boundaries of the separation are completely unimportant.

Similarly, if a span is used to style a misspelled word and aria-invalid is applied to that span, while the user does not care about the span, the user does care about which characters are part of the misspelling. So, again, the conferred property is semantically critical, and the scope of that property is important, but the container is completely unimportant.

This got me wondering ... If the semantic differences conveyed by styling of div and span are going to be conveyed entirely by the aria-textseparation property and not in any way by the generic role, what is the difference between <div role="none"> and <div role="generic">?

In other words, couldn't we define aria-textseparation in a way such that we could map both div and span to role="none" with aria-textseparation="inherit"?

If not, what are the meaningful differences between none and generic?

Keep in mind that applying role="none" to a div has absolutely no effect on descendants. It is already designed to keep text nodes without changing anything else. That is what we want the generic to do. And, applying aria-textseperation to a generic effects only how the child (not descendant) text nodes are separated from text nodes at the boundaries of neighboring generic elements.

So, the inherritance aspects of role none are entirely innocuous. They would have no impact if both div and span were mapped to role="none" aria-textseparation="inherit".

mcking65 commented 5 years ago

The currently proposed definition of the default value of aria-textseparation is:

inherit (default): Indicates that the element's text is separated from neighboring element text according to the element's display style.

I think the word "inherit" could lead to confusion. We don't ever want to imply that aria-textseparation itself could be inherrited. I suggest we consider using either "infer", "compute", or "style" and adjust the wording to be:

style (default): Indicates that the user agent infers how text at the element's left and right boundaries is separated from text of neighboring presentational elements based on the display of the element and neighboring elements. Note: Inference algorithms are not standardized and vary significantly among user agents.

By using the term "presentational element", I am assuming that we map div and span to role none.

carmacleod commented 5 years ago

@mcking65 commented:

it is the default for span and div and since there is likely no reason to use it on any other element

If I am reading #697 and #698 correctly, I believe the idea was to default to generic role for:

and possibly others that are currently TBD or "more discussion needed". (aha - here's a summary in the role parity wiki)

Which isn't to say that role none wouldn't be ok for those also... I'm still trying to wrap my head around using role none by reading through:

So, to make sure I understand, role none would mean that the div/span is not in the accessibility tree, but its text (and other) children are.

Would aria-textseparation be a global attribute then? Or would we make it a supported property of presentation/none? We originally had it as a supported property of generic role.

carmacleod commented 5 years ago

Note: Mappings are different for presentation, div, and span. @joanmarie Please double-check that I have summarized these mappings correctly (and edit if needed).

presentation role in core-aam:

div element in html-aam:

span element in html-aam:

carmacleod commented 5 years ago

@mcking65 I agree that style is a better than inherit for the default value for aria-textseparation.

@mcking65 @melanierichards Do you think it might be clearer to have aria-textseparation take a 2-token value - one for leading and one for trailing?

Here's a couple of examples:

<div>
 <div role="generic" aria-textseparation="style space">Price:</div>
 <div>$4</div>
 <div role="generic" aria-textseparation="space style">99</div>
</div>

Or, same visual presentation and slightly simpler markup:

<div>
 <div>Price:</div>
 <div role="generic" aria-textseparation="space space">$4</div>
 <div>99</div>
</div>

This would be similar-ish to the CSS "top right bottom left" shorthand that developers already use.

carmacleod commented 5 years ago

I wrote this little test to see whether the current HTML-AAM mappings for div and span reflect what is in the browsers' accessibility tree.

For Windows Chrome and FF, I see the following:

I can check out Edge/UIA this evening (or if anyone else can, please do).

@cookiecrook Would you be able to see whether div and span both map to AXGroup, as stated in the HTML AAM... or is span actually (often? always?) ignored?

@joanie, could you confirm that div is usually ATK_ROLE_SECTION and span is not mapped in ATK?

I'm wondering if we should consider the following default mappings:

If this makes sense (i.e. if it would cause the least breakage), then we would need to rethink aria-textseparation. Also, perhaps section (for block) or none (for inline) make sense for some of the other elements in our list for generic role?

joanmarie commented 5 years ago

@joanie, could you confirm that div is usually ATK_ROLE_SECTION and span is not mapped in ATK?

Correct UNLESS the span is focusable or has some other attribute necessitating an accessible object be created. See related https://github.com/w3c/html-aam/issues/151.

melanierichards commented 5 years ago

@carmacleod thanks for doing this research! In Edge/UIA we map <div> and <span> to ControlType: Group, only if it is semantically interesting (tabindex for example). Otherwise, child nodes, such as text nodes, are placed into the accessibility tree. HTML-AAM probably needs the "May not have an accessible object if has no semantic meaning. Otherwise..." preamble for us too...

carmacleod commented 5 years ago

I wrote a new test to look at the elements listed as generic role on the wiki.

In Firefox, the accessibility tree seems straightforward:

Chrome prunes more than firefox:

Mac Safari:

carmacleod commented 5 years ago

1) Global attributes for generic role:

Currently, generic role inherits from structure, which inherits from roletype. Which means that generic inherits all of the global attributes:

As @mcking65 and @aleventhal have pointed out, some of the global attributes are problematic for generic, such as aria-label and aria-labelledby, possibly others.

Also, the third paragraph of State and Property Attribute Processing in the ARIA spec says:

Global states and properties are supported on any element in the host language.

(Perhaps this is why developers often think they can add an aria-label to a plain div or span).

Need to discuss what to do about global attributes with respect to generic role. Which ones to support? Do we need to change the role hierarchy?

2) Using a token list (with only 1 or 2 tokens allowed) for aria-textseparation:

Authors can style an element any which way, so I believe they need a way to specify both leading and trailing textseparation separately for linebreak, paragraphbreak, style, etc (not just for space).

The ARIA spec defines a "token list" as Space-separated tokens.

I think having a 2-token space separated list as mentioned in https://github.com/w3c/aria/issues/699#issuecomment-427040820 above would give authors the flexibility they need. We could even say that a single token, such as aria-textseparation="space" is a shorthand for aria-textseparation="space space". The default would be aria-textseparation="style".

carmacleod commented 5 years ago

Re: aria-label/labelledby on generic @joanmarie opened https://github.com/w3c/aria/issues/833 and https://github.com/w3c/html-aam/issues/160

cookiecrook commented 5 years ago

Commenting on this proposed definition.

A nameless container element that can confer accessibility properties to its descendants without exposing itself to assistive technologies.

Aside from the hilarity of phrasing it "exposing itself", this doesn't appear to be correct. Generic containers like <span> are exposed to the API so that assistive technologies can gather certain properties such as layout and bounds. This allows VoiceOver to enlarge the cursor for low vision users, Switch Control to simulate mouse or drag events, etc. These elements are conveyed to the APIs… the distinction is that the role is irrelevant, or generic. Naming it does not cause the user to infer some specific interaction model as it would with a button, landmark, or form field.

mcking65 commented 5 years ago

@cookiecrook commented

Aside from the hilarity of phrasing it "exposing itself",

Funny ... But, let's keep in mind that, hopefully, all readers are aware that the spec is not a transcript of a legislative hearing about nominees for judicial positions.

@cookiecrook commented:

this doesn't appear to be correct. Generic containers like are exposed to the API so that assistive technologies can gather certain properties such as layout and bounds. This allows VoiceOver to enlarge the cursor for low vision users, Switch Control to simulate mouse or drag events, etc. These elements are conveyed to the APIs… the distinction is that the role is irrelevant, or generic.

Thank you for the assistive tech dev use cases. Those, combined with the case of the generic being focusable, are sound reason for having the role rather than mapping to none.

Would the following wording be more acceptable?

A nameless container element that is not exposed to users of assistive technologies but can confer accessibility properties to its descendants.

@cookiecrook commented:

Naming it does not cause the user to infer some specific interaction model as it would with a button, landmark, or form field.

Nameless is meant to say that the generic element cannot be named, i.e., labeled. So, two critical aspects of the definition are:

  1. Unlike other elements, e.g., headings or buttons, AT users will never be aware of the role of the element. Generics are always part of some other element that has a role.
  2. Generics are unlabelable.

This implies a need for a requirement on assistive technologies. That seems necessary if we can't express the requirement at the API level.

schne324 commented 5 years ago

two random examples we were talking about in f2f:

carmacleod commented 5 years ago

Quickly testing @schne324's examples with JAWS/NVDA in Chrome/FF.

Example 1

Example 2