Status Update
Comments
me...@adrianroselli.com <me...@adrianroselli.com> #2
In the console (from the developer tools, DevTools), empty parentheses after "Symbol" return an error, whereas without empty parentheses, it returns what is stated in the information "URL to the relevant page on
16:11:31.288 Symbol( "String" ) === Symbol().for( "String" );
16:11:31.291 VM590:1 Uncaught TypeError: Symbol(...).for is not a function at <anonymous>:1:36 (anonymous) @ VM590:1
16:11:52.488 Symbol().for( "String" ) === Symbol().for( "String" );
16:11:52.490 VM594:1 Uncaught TypeError: Symbol(...).for is not a function at <anonymous>:1:13 (anonymous) @ VM594:1
16:12:02.226 Symbol( "String" ) === Symbol( "String" );
16:12:02.239 false
From the Gemini AI support in DevTools itself (once enabled in the DevTools settings), with some simplifications made by me:
Explanation
The error "Uncaught TypeError: Symbol(...).for is not a function" indicates that the for method you're trying to call is not available on a Symbol object.
Here's the breakdown of why this happens and how to fix it:
Understanding the Issue
Symbol() creates unique, anonymous symbols: When you call Symbol(), you get a brand new, unique symbol. These symbols are distinct even if the description is the same (e.g., Symbol("String") !== Symbol("String")). They are meant for internal use within your code and are not shared or registered.
Symbol.for() creates and retrieves global symbols: Symbol.for(key) is a static method on the Symbol constructor, not on a specific instance of a symbol. It's used to create or retrieve a symbol from a global registry using the given key (a string). If a symbol with that key already exists, it returns the existing symbol. Otherwise, it creates a new one and registers it.
The Error in your Code
In your code:
Code (Use code snippets with caution)
Symbol().for( "String" ) === Symbol().for( "String" );
You're mistakenly trying to call for as a method on the result of Symbol() which is a unique anonymous symbol object.
The Correct Usage
The correct way to use Symbol.for() is as a static method of the Symbol constructor:
Code (Use code snippets with caution)
Symbol.for( "String" ) === Symbol.for( "String" ); // This is correct
Explanation of the Correct Code
Symbol.for("String") (First Instance):
The JavaScript engine checks if a symbol with the key "String" exists in the global symbol registry.
If it doesn't exist, a new symbol is created, registered with the key "String", and returned.
If a symbol with the key "String" already exists, it's retrieved from the registry and returned.
Symbol.for("String") (Second Instance):
The same process repeats. Since "String" was already used as a key, the engine looks for an existing symbol with this key.
It finds the symbol created in the previous step and returns it (the same object!).
=== (Strict Equality):
Because both instances of Symbol.for("String") return the same object, the strict equality comparison (===) evaluates to true.
Summary
The error Symbol(...).for is not a function arises from incorrectly trying to call for as a method on a unique, anonymous symbol instance. The correct usage is Symbol.for(key), where for is a static method on the Symbol constructor, and key is the string used to register and retrieve the globally registered symbol.
Revised Code (Correct)
Code (Use code snippets with caution)
console.log(Symbol.for( "String" ) === Symbol.for( "String" ));
This code will now work correctly and output true.
ar...@gmail.com <ar...@gmail.com> #3
It has now been a year since this bug(s) was raised. It encodes WCAG failures and as a result opens up legal risk for anyone who follows the advice in this post.
Is anyone going to address this?
I am fine continuing to warn devs and clients that this article cannot be used as-is and let them decide how that reflects on the rest of the content on the site. I had hoped Google's regular statements about its commitment to accessibility would not make that necessary nor put its primary developer relations site at odds with that message.
ar...@gmail.com <ar...@gmail.com> #4
Any movement on this? I still see no corrections.
ts...@google.com <ts...@google.com>
ni...@gmail.com <ni...@gmail.com> #5
ni...@gmail.com <ni...@gmail.com> #6
me...@adrianroselli.com <me...@adrianroselli.com> #7
I see the author is promoting another, newer "accessible" tool-tip component on the Chrome for Developers YouTube channel:
Is there any chance that Google or Chrome or whomever is in charge can get him to update the post covered by this issue?
The new technologies he covers in the video are nifty when they work, but many sites will need to wait a while for support and in the meantime the article this issue references is still promoting guidance that creates legal risk for those who follow it and barriers for real people.
la...@outlook.com <la...@outlook.com> #8
si vous pouvez me débloqué merci ;;;
Description
What page(s) need to be updated?
Why is this update needed?
2 significant changes needed, 3 changes warranted, 2 bits of feedback:
1. The demo is 404
I realized I could file a PR to fix that, so I did: #8958
2. WCAG violations
The tool-tip demo as written creates a WCAG Success Criterion 1.4.13: Content on Hover or Focus failure:
The specific WCAG violations:
3. Inaccurate description of screen reader
From the article:
That screen shot is from the Chrome developer tools. That represents what Chrome sends, not necessarily how something is exposed, recognized, nor announced. While the distinction may seem small, it feeds into the ongoing misunderstanding of where browsers stop and screen readers start, resulting in blame landing on the wrong tools when things don't work as developers expect.
4. Advice makes tooltip part of accName / content
From the article:
The code presented makes the tooltip part of the content itself, meaning a screen reader use in particular is required to hear it. The ARIA spec on the is clear that it should be part of the accDescription, not the accName:
tooltip
roleIf you want to dive more into the #979 Clarify the use of role=tooltip
tooltip
role, I encourage you to read this ARIA discussion:5. Localization concern
From the article:
6. Probably do not use Designcember as an example
The Designcember site has problematic disclosures / tool-tips. I raised this issue last year. The author acknowledged it. Even now it is problematic (although I am pleased to see the modals dismiss on
Esc
). I encourage you not to use it as an example.7. Abbreviation freebie
I know the accessibility supported ) and expand the text as you would the printed page. Eg: HyperText Markup Language (HTML).
<abbr>
is used only as an example, but a best practice is to not use it (since it is not8. Remove autoplay
While I am here, can you please remove the autoplay on the Designcember example and allow the controls to display? Doing so will get around the current SC 2.2.2: Pause, Stop, Hide issue.
What's the deadline?
Ideally before anyone copies this code into their projects, given using it will create a WCAG conformance error and potentially expose them to legal risk (low risk, but still).
A few additions:
inert
The article's entire accessibility approach relies on an
inert
child being part of its parent's accessible name. While that currently happens in Chromium, I don't believe that is a safe assumption going forward. While it isn't in HTML AAM yet, my assumption is thatinert
should map toaria-hidden=true
(which is what the polyfills do), and a node witharia-hidden=true
will not be included in the parent's accessible name.This means that the text of all the tooltips in the article would not be exposed to screen reader users at all. This is a major accessibility issue, and should be corrected ASAP, in my opinion.
name vs. description
I also want to just emphasize how big a problem this recommendation is:
In addition to asking for screen-reader-only localization problems, the fact that this text is added is a clear signal that the tooltip should be a description, not part of the name (as Adrian mentioned).
I'm actually not strongly opposed to the idea of broadening the
tooltip
role's usage for accessible name content, but if it is used as a name, it should be used as the name, not an extra description tacked onto the name. A good example of this would be using a tooltip to expose the name of an icon button -- this is fine, and the tooltip would have a straightaria-labelledby
relation to the button, or be its sole text content.preventing user selection
In the Styles section, the article recommends adding this:
This is actually an accessibility issue as well, since several reading-related tools rely on the user being able to select text (e.g. looking up definitions, parts of speech, getting simpler language, etc.). These styles should not be added to any meaningful, user-readable text.