Re: addition of HTML role requirement mappings

On Feb 21, 2014, at 12:30 PM, Alexander Surkov <surkov.alexander@gmail.com> wrote:

> Thanks, James. Answering inline (if it's out scope of the topic then let's move it somewhere else).
> 
> On Fri, Feb 21, 2014 at 3:06 PM, James Craig <jcraig@apple.com> wrote:
> 
>> Ah. There are several reasons and use cases:
>> 
>> 1. ARIA is used for more than just HTML, (e.g. SVG <g role="table">)
> 
> afaik SVG allows HTML inside, it doesn't seem the author have to use ARIA if he wants tabular data for AT in SVG.
>  
>> 2. Some people need to retrofit tablular data on existing sites that do not use <table> (e.g. <div role="table">)
> 
> What does prevent them to use HTML tables?

In response to both of the previous comments, it would certainly be ideal if the original author used semantic HTML correctly the first time, but sometimes an individual will inherit a project or site that was coded with poor practices. Completely gutting the site and rewriting it would be risky, but retrofitting the non-semantic markup by adding some roles and other ARIA attrs is low-risk and frequently trivial. 

For example, if you change <div class=bigtext> to <h1 class=bigtext>, you’ll have to rewrite your CSS and potentially some JavaScript, too. But if you change <div class=bigtext> to <div class=bigtext role=heading aria-level=1>, you’re done with the accessibility retrofit, and can be almost 100% certain you didn’t cause any regressions.

>> 3. The 1-to-1 role mapping to HTML is also required for presentation inheritance. (e.g. <table role="presentation">)
> 
> I don't follow these cases, can you elaborate please?

Basically, if a <table> is marked as presentational, the immediate required descendants (caption, thead, tbody, tfoot, tr, td, td) should inherit the presentation state. Likewise for other elements like <ul>. Without this chunk, an author would have to add a lot of redundant roles.

<ul role=presentation>
  <li role=presentation>Foo</li>
  <li role=presentation>Bar</li>
  <li role=presentation>Bar</li>
  <!-- etc… -->
</ul>

With this bit of the ARIA spec, the author can just do this:

<ul role=presentation>
  <li>Foo</li>
  <li>Bar</li>
  <li>Bar</li>
  <!-- etc… -->
</ul>

View the presentation inheritance description with the spec sentence starting with “Some elements are only complete when additional descendant elements are provided.” 
http://www.w3.org/WAI/PF/aria/complete#presentation

>> 4. The 1-to-1 role mapping will be useful once we add the Element.computedRole interface. PFWG-ISSUE-427
> 

> I don't follow these cases, can you elaborate please?


We’re discussing adding partial Element interfaces for computedRole and computedLabel for ARIA 1.1. The syntax is TDB, but it’d probably be something like this:

document.createElement("h1").computedRole; // --> 'heading' 
document.createElement(“ul").computedRole; // --> 'list'

But since ARIA 1.0 started out mostly as roles that were missing from HTML (like grid, dialog, landmarks, etc) there is not full coverage of all HTML semantics in the list of ARIA roles. It’s great that <dialog>, <main>, <header>, and more exist natively in HTML now, but in order to support computedRole on all elements, ARIA.next needs to add more roles to cover the remaining semantics, including generic semantics like svg:g and html:span.

document.createElement("p").computedRole; // —> ??? (would need to add ‘paragraph’ role)
document.createElement("span").computedRole; // —> ??? (need to add ‘generic’ or some such role)

Some implementations (WebKit for example) consider <table> to be equivalent to the grid role, but they aren’t 1-to-1 matches.
document.createElement(“table").computedRole; // —> 'grid' (this should probably be table, since the grid role is reserved for interactive grids)

Element.computedLabel would be similar, and return the element’s computed label based on the rules in the text alternative computation. 

In addition to making things more clear for authors, these interfaces will make it possible to test portions ARIA with TestHarness.js. Since most of the ARIA 1.0 validation is platform-specific accessibility API mappings, it’s difficult to test, which is why it took us 2 years to go from LC to PR. One of my goals for 1.1 is to make sure the spec parts are more readily testable with automation. The platform-specific user agent mappings will still be difficult to test, but we should automate any parts we're able to automate.

James

Received on Friday, 21 February 2014 21:24:48 UTC