RE: Another AccName sanity check: presentational role and name computation

I see what you mean, that is indeed confusing.

So based on this spec text, it appears that the following scenarios would produce different results in the accessibility tree.

The following element would be exposed no matter if it includes role="presentation".

<img role="presentation" aria-label="Test">

However, all of the following elements would not be exposed in the accessibility tree because they include no global ARIA attributes.

<img role="presentation" alt="Test">

<img role="presentation" title="Test">

I understand that the spec also says "Authors SHOULD NOT provide meaningful alternative text (for example, use alt="" in HTML) when the presentation role is applied to an image.", but this is advisery and doesn't prevent people from doing this in practice.

So, in regard to the naming computation and exposure of relevant nodes, is the above interpretation correct?

What is supposed to happen in this case, where aria-owns is used to change the order of content but the desire is to hide the structural syntax of the parent list?

<ul role="presentation">
<li aria-owns="contentId"></li> 
</ul>

<div id="contentId">
Something.
</div>

Would the LI be exposed as an orphan node in the accessibility tree in this case?

This sounds nitpicky, but to make the naming computation work reliably, it has to correctly parse that too. E.G should presentational elements also process explicitly owned children even if they are presentational?

What if aria-owns in the above example was set to aria-live="polite" instead? Would the LI still be exposed regardless?

Unfortunatley I need to know the answers to these questions because I have to program this functionality into the AccName prototype.

Thanks,
Bryan





Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: James Nurthen <nurthen@adobe.com> 
Sent: Wednesday, April 04, 2018 11:00 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Gunderson, Jon R <jongund@illinois.edu>; Joanmarie Diggs <jdiggs@igalia.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: Re: Another AccName sanity check: presentational role and name computation

Bryan,
I think this is covered in Presentational Roles Conflict Resolution - https://www.w3.org/TR/wai-aria-1.1/#conflict_resolution_presentation_none

However I don't believe either user agent you checked is actually behaving according to the spec.

What I think the spec says is 
* If you specify a global state or property AND the element has a role of presentation THEN ignore the presentation role and expose the element as if the presentation role were not present.

As aria-label is a global property, then according to the spec text

    <h2 role="presentation" aria-label="One">
    Two
    </h2>

Should be exposed as a Header level 2 with text of "One" as the presentation role should be ignored due to the global property.

What is exposed? I don't have a windows machine here right now but 
* Safari seems to expose exactly this (Heading Level 2, One)
* Chrome seems to remove the Heading (Heading not found)

Regards,
James





James Nurthen  |  Accessibility Engineer  |  Adobe  |  p. 415.832.2734  |  c. 415.987.1918  |  nurthen@adobe.com
 
 

On 4/4/18, 10:13 AM, "Bryan Garaventa" <bryan.garaventa@levelaccess.com> wrote:

    Hi,
    I had a bit of time to run some tests, and since this involves the naming computation, it seemed important to do so prior to our call tomorrow.
    
    I ran the following code and checked this with the accessible object checker to see what the accessibility tree is showing for the H2 node:
    
    <h2 role="presentation" aria-label="One">
    Two
    </h2>
    
    I was confused by the earlier assertion that "role=presentation does not remove content from the accessibility tree it only changes its role", because technically if a node has role=presentation or role=none it literally has no role and thus cannot be represented in the accessibility tree.
    
    According to Firefox, which I don't think was the case in the past but appears to be now, the H2 node now is represented in the accessibility tree of having a role of "presentation" and the node still exists in the accessibility tree.
    
    However in Chrome, the node is entirely removed and is not present in the accessibility tree at all.
    
    If this is exposed as in Firefox, then what is the point of the presentation and none roles if this is ignored anywhay? 
    
    And, if Firefox is wrong and Chrome is correct, then how can a node that does not exist in the accessibility tree have an accessible name?
    
    
    
    Bryan Garaventa
    Accessibility Fellow
    Level Access, Inc.
    Bryan.Garaventa@LevelAccess.com
    415.624.2709 (o)
    https://na01.safelinks.protection.outlook.com/?url=www.LevelAccess.com&data=02%7C01%7Cnurthen%40adobe.com%7C0468f2bc500d4ebd786108d59a4f64e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636584588144206508&sdata=WaTMgrQiZ3Db9ME2E4gEadezTJ5W3RJ%2FF21bkueYF%2BI%3D&reserved=0

    
    -----Original Message-----
    From: Gunderson, Jon R <jongund@illinois.edu> 
    Sent: Monday, March 19, 2018 12:59 PM
    To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Joanmarie Diggs <jdiggs@igalia.com>
    Cc: ARIA Working Group <public-aria@w3.org>
    Subject: Re: Another AccName sanity check: presentational role and name computation
    
    Bryan and Joanie,
    
    role=presentation does not remove content from the accessibility tree it only changes its role, so the question seems more that if you apply aria-label to any node does that change the accessible name for that element in for the calculation of the accessible name. 
    
    To me I think we are making the accessible name calculation to complicated for aria-labelledby if we start including the need to account for aria-label or title attribute values.
    
    I think it should simply look at text content, form/widget values and name from ALT and TYPE attributes for images and buttons.
    
    We need to make the algorithm simpler to help people understand it and not make mistakes.
    
    Jon
    
    
    On 3/19/18, 2:49 PM, "Bryan Garaventa" <bryan.garaventa@levelaccess.com> wrote:
    
        Hi,
        I'm already in San Diego for the conference, so my internet is somewhat spotty.
        
        I remember asking Joseph about this over a year ago, and he said that if role=presentation is applied to a node, then that node doesn't exist in the accessibility tree, and as such it cannot have an accessible name no matter if it includes a title or aria-label in the recursive processing.
        
        I'll be happy to explore further about the issue you submitted earlier too, but will probably have to wait till next week to dig into it.
        
        
        
        Bryan Garaventa
        Accessibility Fellow
        Level Access, Inc.
        Bryan.Garaventa@LevelAccess.com
        415.624.2709 (o)
        https://na01.safelinks.protection.outlook.com/?url=www.LevelAccess.com&data=02%7C01%7Cnurthen%40adobe.com%7C0468f2bc500d4ebd786108d59a4f64e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636584588144362763&sdata=cKQSQ4Nggc%2BXrQwDkUZ%2FpqCqczc3gs8b9ynEx1yIvP4%3D&reserved=0

        
        -----Original Message-----
        From: Joanmarie Diggs <jdiggs@igalia.com> 
        Sent: Monday, March 19, 2018 11:56 AM
        To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
        Cc: ARIA Working Group <public-aria@w3.org>
        Subject: Another AccName sanity check: presentational role and name computation
        
        Hey again Bryan and others interested in AccName.
        
        I'm now working on the test cases where the expected result includes "Garaventa the weird." Both Firefox and WebKit have results which include "Eli" instead of "Garaventa." Looking at the AccName algorithm, I think Firefox and WebKit are correct.
        
        Searching the algorithm, I see only one mention of the presentational role, namely in step 2D, which states:
        
        <quote>
        Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").
        
        Comment:
        For example, in HTML, the img element's alt attribute defines a text alternative string, and the label element provides text for the referenced form element. In SVG2, the desc and title elements provide a description of their parent element.
        </quote>
        
        Looking at your test case, the markup relevant to which name is chosen is this bit:
        
            <span role="presentation" aria-label="Eli">
              <span aria-label="Garaventa">Zambino</span>
            </span>
        
        While the presentational role is applied to the outer span, my understanding of an attribute provided by the node's native markup is something specific to HTML. The aria-label attribute can be used on HTML of course; but the aria-label attribute is not *provided by* HTML. So my read of step 2D is that technically "Eli" should be chosen.
        
        Furthermore, in the case where the thing being calculated is a name, I don't think we'd get to step 2D because step 2C states:
        
        <quote>
        Otherwise, if computing a name, and if the current node has an aria-label attribute whose value is not the empty string, nor, when trimmed of white space, is not the empty string:
        
        * If traversal of the current node is due to recursion and the current
          node is an embedded control as defined in step 2E, ignore aria-label
          and skip to rule 2E.
        
        * Otherwise, return the value of aria-label.
        </quote>
        
        Step 2C doesn't say anything about the presentational role. And the current node is not an embedded control as defined in step 2E. So why don't we want to use the aria-label value of "Eli"?
        
        If I'm missing something please explain. Thanks in advance for your help with this!!
        
        --joanie

Received on Wednesday, 4 April 2018 22:12:47 UTC