RE: Re: SVG naming computation

Thanks Carolyn,
Can you point me to the current doc for SVG 2 Candidate Rec?

What is the active status for this at present, and do you know if any of this is implemented within browsers as yet?

Thanks,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
Sent: Wednesday, June 12, 2019 12:15 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: public-aria@w3.org
Subject: Re: Re: SVG naming computation

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Further to Scott's further checks for unnamed SVG elements, the computation would need to also check for the following before flagging as "having to be hidden":
- zoomAndPan attribute on the svg or a descendant view
- user interface events on the svg or any of its descendants
- any interactive descendants, such as an anchor
- tabindex on the svg or any of its descendants (if SVG 2 Candidate Rec)
Unless the phrase "having to be hidden properly" includes having to remove any potential interactivity.
Carolyn

----- Original message -----
From: Scott O'Hara <sohara@paciellogroup.com<mailto:sohara@paciellogroup.com>>
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>, 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Cc:
Subject: [EXTERNAL] Re: SVG naming computation
Date: Wed, Jun 12, 2019 1:52 PM

Hi Bryan

Your steps to compute the accessible name of an SVG element are what I was speaking to Ian Pouncy about a few weeks back for possible inclusion in the SVG AAM. So yes, I agree with that!

Regarding unnamed SVG elements, that's a bit tricky.  If they were given role=img I would agree they should be flagged.  If not, then there'd need to be further checks to ensure there were no <text> elements that should be exposed within the SVG so as to not inaccurately tell someone to hide the SVG which does contain exposable content.

On 6/12/19, 12:53 PM, "Bryan Garaventa" <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>> wrote:

    Hi,
    I was asked recently what the proper naming computation is when dealing with SVG elements, and there has been much debate about this over the years, many things have been proposed, and none of it has really gone anywhere.

    So, for the sake of clarifying what is actually documented according to spec, here is what I found regarding SVG elements.

    Steps to compute the accessible name of an SVG (order of precedence):
    - aria-labelledby
    - aria-label
    - title element in the SVG
    - title attribute on the SVG

    The desc element would be treated like aria-describedby on the SVG element itself, and only set the Description property, which is not used to compute the accessible name.

    I derived this since these are the only elements and attributes documented in the AccName specification for this purpose, and no other SVG naming specification has gone through formal review to validate a different naming computation that I am aware of.

    If I've made any incorrect assumptions here, please let me know.

    Also, regarding the accessibility of unnamed SVG elements, do you believe these have the same status as unnamed img elements where they should be flagged  as having to either be hidden properly or given a valid name?

    Thanks,
    Bryan


    Bryan Garaventa
    Principal Accessibility Architect
    Level Access, Inc.
    Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
    415.624.2709 (o)
    www.LevelAccess.com<http://www.LevelAccess.com>