New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Fixed
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Sign in to add a comment

Expose SVG title element as accessible name

Reported by, Dec 5 2015 Back to list

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Open page in Chrome Canary or Stable on OSX with Voiceover running.
2. Tab onto button containing SVG with <title> describing a visual icon. Compare to additional demos using ARIA attributes.
3. Observe "native title" example does not have an accessible name, compared to the others.

What is the expected behavior?
When a screen reader user tabs onto a button containing an SVG icon with alternative text specified using the SVG <title> element, that child element's content should be exposed as the name of the button (in the absence of other text). Currently, an accessible name can be achieved using `aria-labelledby` or `aria-label `on the SVG element, but not using the native, semantic <title>. This is an oversight.

What went wrong?
The <title> element in SVG should be exposed to assistive technology through the accessibility tree, according to the Accessibility API Mappings spec. In Chrome, the correct naming behavior occurs when a developer provides content in an `aria-label`, or binds the `<title id="uniqueId">` to its parent using `<svg aria-labelledby="uniqueId">`.  Name mapping should work with any method, according to the mappings spec. 

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? Yes 

Chrome version: 46.0.2490.86  Channel: stable
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 19.0 r0
3.1 KB View Download
Labels: Cr-UI-Accessibility

Comment 2 by, Dec 6 2015

Labels: -Cr-Blink
Status: Untriaged
Status: Assigned
Rerouting to Elly for a11y bugs.
Status: Fixed
Fix landed; this should be fixed now :)

Verification steps in the original comment no longer reproduce this bug for me.
Labels: Needs-Feedback
@holla: The attached output is observed on Google Chrome Dev Version - 49.0.2623.0. Could you please let us know if this is the expected behavior.

Thank you.
1.5 MB Download

Sign in to add a comment