#33034: accessible description

[estelle]

rewrote the glossary term.

fixes #33034

[github-actions]

Preview URLs

• /en-US/docs/Glossary/Accessible_description

External URLs (7)

URL: /en-US/docs/Glossary/Accessible_description
Title: Accessible description

• https://en.wikipedia.org/wiki/Web_accessibility (1 time) (Note! This may be a new URL 👀)
• https://w3c.github.io/accname/ (1 time) (Note! This may be a new URL 👀)
• https://w3c.github.io/aria/ (1 time) (Note! This may be a new URL 👀)
• https://webaim.org/ (1 time) (Note! This may be a new URL 👀)
• https://www.w3.org/TR/html-aam-1.0/ (1 time) (Note! This may be a new URL 👀)
• https://www.w3.org/TR/svg-aam-1.0/ (1 time) (Note! This may be a new URL 👀)
• https://www.w3.org/WAI/ (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2024-06-20 18:28:13)

[PassionPenguin]

@estelle for reader’s reference, will adding a link to related drafts/standards of many use?

[estelle]

Thanks @PassionPenguin. I committed your suggestions, then edited the page.

[PassionPenguin]

i do not have the access to approve, and, the preview page seems not to be synced with the latest commit, but as for the markdown content itself, it’s now way better. merci beaucoup! 😃

[estelle]

@pepelsbey Bumping in case you missed this round-robin assignment. Thanks for your review.

[PassionPenguin]

@estelle maybe we can improve links (to keep consistent with accessiblity, accessibility_tree and accessibility_name) (#34095)

[pepelsbey]

Sorry for the delay, I was away from the review process last week.

I have concerns regarding the SVG section of this PR: it follows what’s written in the spec, which is not always aligned with browser implementations. For example, the xlink:title attribute is deprecated, the aria-label attribute is not mentioned, and the whole “contents of the <desc>” part is too complicated.

Maybe we should consider writing HTML and SVG computing accessibility names guides and linking them from the glossary. Otherwise, this entry becomes too big and detailed, which is unusual for the glossary.

[PassionPenguin]

Sorry for the delay, I was away from the review process last week.

I have concerns regarding the SVG section of this PR: it follows what’s written in the spec, which is not always aligned with browser implementations. For example, the xlink:title attribute is deprecated, the aria-label attribute is not mentioned, and the whole “contents of the <desc>” part is too complicated.

Maybe we should consider writing HTML and SVG computing accessibility names guides and linking them from the glossary. Otherwise, this entry becomes too big and detailed, which is unusual for the glossary.

thats why i did put an issue but didn't purposed a pr - spec are all in TR.

Separating the computation out of glossary could be a good idea to avoid bloated/overstuffed with detailed information, but we now do not even have articles on desc and name than these two glossary entries. Maybe we can create them in web accessibility section.

What's your opinion @estelle ?

[estelle]

All good points. I wasn't too keen on adding the SVG, but i do think we need to explain the computation. When i used to present on web forms in 2011 or so, the "wows" came from the new HTML input types, but how the accessible name was computed was the part of the talk that got the most photos of my slides taken and seemed to be of interest to every. (https://estelle.github.io/forms/#slide13)

So, I combined the two, since SVG is based on the HTML "with some differences," and added the SVG elements to step 3 in order of precedence. I think it makes the page less overwhelming while keeping the content. Does that work?

[PassionPenguin]

All good points. I wasn't too keen on adding the SVG, but i do think we need to explain the computation. When i used to present on web forms in 2011 or so, the "wows" came from the new HTML input types, but how the accessible name was computed was the part of the talk that got the most photos of my slides taken and seemed to be of interest to every. (https://estelle.github.io/forms/#slide13)

So, I combined the two, since SVG is based on the HTML "with some differences," and added the SVG elements to step 3 in order of precedence. I think it makes the page less overwhelming while keeping the content. Does that work?

All good points. I wasn't too keen on adding the SVG, but i do think we need to explain the computation. When i used to present on web forms in 2011 or so, the "wows" came from the new HTML input types, but how the accessible name was computed was the part of the talk that got the most photos of my slides taken and seemed to be of interest to every. (https://estelle.github.io/forms/#slide13)

So, I combined the two, since SVG is based on the HTML "with some differences," and added the SVG elements to step 3 in order of precedence. I think it makes the page less overwhelming while keeping the content. Does that work?

LGTM. The computation is definitely needed (no matter detailed or brief it is) given NO computations are listed currently in the MDN documentations. How's your view on this update @pepelsbey ?

[pepelsbey]

The merged computation section looks much better now. It would be better to have it in a reference somewhere else, but for a quick win, this might also work. I’d also suggest improving the initial definition to make it a bit shorter and more straightforward.

[estelle]

Thanks @pepelsbey. Committed your suggested edits.

[pepelsbey]

Looks good! Thank you :)