Repository navigation
[Toolkit][Shadcn] Fix a caller's aria-label being ignored on pagination, breadcrumb and questionnaire - #4058
Conversation
carsonbot
added
Bug
|
I quickly checked other components that i currently do not use, but same issue (
The same One extra thing: hard-coded English
Those can not have the same fix, and not sure if they should be handled in this PR, but wanted to mention them |
…cipes | Q | A | -------------- | --- | Bug fix? | yes | New feature? | no | Deprecations? | no | Documentation? | yes | Issues | Fix symfony#4051 | License | MIT The `breadcrumb`, `calendar`, `carousel`, `input-otp`, `navigation-menu`, `pagination`, `questionnaire` and `sidebar` recipes wrote `aria-label` as a literal attribute before `{{ attributes }}`, so a caller's own `aria-label` was emitted as a second, duplicate attribute. Browsers keep the first one, so the hard-coded default always won and the name could not be translated or made more specific. Each template now declares the label inside `attributes.defaults()`, e.g. `{{ attributes.defaults({'aria-label': label, class: ...}) }}`, so a caller's value wins and the attribute is emitted once. For the five recipes with a `label` or `ariaLabel` prop, that prop stays the documented way to set the name; `pagination`, `breadcrumb` and `questionnaire` had none, so their README accessibility notes now say a caller's `aria-label` replaces the default. The Toolkit linter rejected every `aria-*` key inside `defaults()`, a rule meant for state attributes such as `aria-expanded` that must always be present and must not be overridable. `aria-label` is an accessible name, not a state, so this PR lets it through.
a202f22 to
6d1de57
Compare
|
The But not the other one you mentioned, I don't see a use-case when their |
|
Thank you for the fix! For the others, it's not about changing the context, but more about applying a translation. |
Maybe in the future we can add a new feature to UX Toolkit to update app's translations...? |
|
That would be of course nicer and even remove the need for overwriting the attributes |
3 participants
Pagination,BreadcrumbandQuestionnaire:Progresswrote theiraria-labelas a literal attribute before{{ attributes }}, so a caller's ownaria-labellanded as a second, duplicate attribute instead of replacing it. Browsers keep the first one, so the hard-coded English label always won and the landmark could never be renamed or translated.Each template now declares the label inside
attributes.defaults(), for instance{{ attributes.defaults({'aria-label': 'pagination', class: ...}) }}.defaults()lets a caller's value win and emits the attribute once, which is exactly what an accessible name needs.The Toolkit linter used to reject every
aria-*key insidedefaults(), a rule meant for state attributes such asaria-expandedthat must always be present and must not be overridable.aria-labelis an accessible name, not a state, so this PR relaxes the rule for it.