w3c
noscript content should be excluded when scripting is enabled
HTML <noscript> elements, when scripting is not disabled, have as their content a text node representing the HTML source inside the <noscript> tag. If the element is not explicitly excluded from 'accessibility name' processing, therefore, you end up with complete nonsense as a result:
<a href="#">test <noscript><span>moo</span></noscript></a>
returns an "accessible name" of "test <span>moo</span>". This is clearly and unarguably wrong.
As you can see, many existing implementations get this wrong, suggesting that the specification is at the very least unclear.
I suggest that the spec should be amended to explicitly specify that child nodes of <noscript> elements should be excluded from processing when scripting is enabled for that element. The spec may also need to say what happens if the algorithm cannot determine whether scripting is enabled for an element. (I think possibly the HTML spec does not define a way to determine this?)
For reference HTML definition of <noscript> - https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element
"The noscript element represents nothing if scripting is enabled, and represents its children if scripting is disabled. It is used to present different markup to user agents that support scripting and those that don't support scripting, by affecting how the document is parsed."
My conclusion of this is that if scripting is disabled then the <noscript> element has no child nodes (as it represents nothing) in step 2F and should not be traversed.
I tested this with a few browsers using https://unequivocal.eu/aria.html
Chrome
JS on - test JS off - test
FF
JS on - test JS off - test moo
Safari
JS on - test JS off - test moo
So looks like there is a bug in Chrome where https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_object.cc;drc=014e218cc1aab1fbeac924548888c2fdfdc35ee8;l=3016 always ignores noscript even when JS is off. Not sure how important this is though as noscript is very seldom used these days.
@jnurthen
"The noscript element represents nothing if scripting is enabled, and represents its children if scripting is disabled. It is used to present different markup to user agents that support scripting and those that don't support scripting, by affecting how the document is parsed."
My conclusion of this is that if scripting is disabled then the
<noscript>element has no child nodes (as it represents nothing) in step 2F and should not be traversed.
I think you're misreading and misinterpreting the HTML spec there I'm afraid. <noscript> only "represents nothing" if scripting is enabled. If scripting is disabled then <noscript> represents its contents. And in neither case does it lack child nodes - if scripting is enabled then it has child text nodes that contain the HTML source inside it (but these text nodes "represent nothing" because they are not rendered), and if scripting is disabled then it contains any child nodes or elements that are valid in its context.
Chrome
JS on - test JS off - test
I'm not sure what you did there, but for me that page renders as "test moo" under Chrome with JavaScript disabled.
I'm not sure what you did there, but for me that page renders as "test moo" under Chrome with JavaScript disabled.
This is looking at the accessible name calculated by the browser - should have been clearer about that.
My conclusion of this is that if scripting is disabled then the
Sorry - I meant to say enabled there. This sentence should have read
"My conclusion of this is that if scripting is enabled then the
I'm not sure what you did there, but for me that page renders as "test moo" under Chrome with JavaScript disabled.
This is looking at the accessible name calculated by the browser - should have been clearer about that.
Oh yes, in that case you're right and I agree this is a bug in Chrome. With scripting disabled the displayed text of the link is "test moo" but the accessible name as Chrome calculates it is just "test".
Sorry - I meant to say enabled there. This sentence should have read
"My conclusion of this is that if scripting is enabled then the element has no child nodes (as it represents nothing) in step 2F and should not be traversed."
It does have child nodes though. If you mean it should be treated as if it has no child nodes then yes I agree.
The whole discussion comes down to what is meant by child nodes in Accname - and we have other issues open on that for slots https://github.com/w3c/accname/issues/93, aria-owns https://github.com/w3c/accname/issues/25 both of which IMO are more important to resolve than this. I propose that when resolving those we look into creating language which would resolve this one too. IMO we mean child nodes in the a11y tree - but never state this - but this needs to get resolved.
As far as I am aware there is no browser API to inspect the accessibility tree? So I would imagine that 100% of the existing implementations of this specification, except those internal to browsers, use the DOM tree not the accessibility tree. (Chrome's behaviour would appear to suggest it also uses the DOM tree.)
@cyns to raise an issue against HTML to clarify how noscript should be hidden
As far as I am aware there is no browser API to inspect the accessibility tree? So I would imagine that 100% of the existing implementations of this specification, except those internal to bowsers, use the DOM tree not the accessibility tree. (Chrome's behaviour would appear to suggest it also uses the DOM tree.)
You could look here: https://chromedevtools.github.io/devtools-protocol/tot/Accessibility/
As far as I am aware there is no browser API to inspect the accessibility tree? So I would imagine that 100% of the existing implementations of this specification, except those internal to bowsers, use the DOM tree not the accessibility tree. (Chrome's behaviour would appear to suggest it also uses the DOM tree.)
You could look here: https://chromedevtools.github.io/devtools-protocol/tot/Accessibility/
Sorry, I'm not sure why you're pointing me there. If you mean that's a way of inspecting the accessibility tree then of course you're right, but it's only available via the DevTools protocol so it's not applicable to 99% of scenarios. (As it happens it's almost useful for a project I'm working on - which is irrelevant to this thread - but even there I can't use it because it excludes hidden elements, which I need it not to do.)