Sarai-WMDE added a comment.
> Mh, the reasoning given in that blog-post for using an icon instead of an asterisk is that the `aria-hidden` is not respected in focus mode. Sadly, it doesn't specify what screen reader or "focus mode" that refers to. But that article is from 2018, we should verify if this bug indeed still exists in 2022, over 4 years later. The article was only linked as a (probably redundant) reminder to, in case we included and icon, make it/keep it non-focusable. I didn't mean to bring it up as a case study comparing text v. icon. I also don't think the issue described by the article still persists, but it'd be good to keep it in mind. I was very hesitant about suggesting the use of an icon (due to both design and tech reasons). I thought it might be the easiest (?) way to control the size of this indicator in its current position (and avoid the inheritance issues derived from using text). Plus, it also allows triggering the tooltip (although I guess the label could also do this). Now, I agree to this: > //If// we want to use an icon instead, we should probably implement it only after we decided whether we want to go for the Codex Lookup. Makes sense. I'll have to search for validation and alignment with the DST again over the whole thing. They consented about the use of the asterisk, but this even contradicts the most recent state of the conversation about required/optional indicators (see T306427 <https://phabricator.wikimedia.org/T306427>). Of course, I'd be all up for replacing WiKit once a decision is made: in that case, we would probably have to contribute (the MVP of) a new component (either Label, or Field – see list of planned components <https://phabricator.wikimedia.org/T313357> for more information). > This space comes from Wikit and was probably designed for the tooltip-icon in Query Builder <https://query.wikidata.org/querybuilder/?>. We can override that Wikit style in a somewhat hacky and brittle way like this: > > .wbl-snl-lemma-input.wikit .wikit-TextInput__label-wrapper { > gap: 0.25em; /* we could also use a token here */ > } > > But it would probably also make sense to have clarity on whether we want to switch to the Codex Lookup for this. Let's put a hold on modifying the spacing until we agree on the nature and size of the visual element (and the component) we're going to use: increasing the size of the indicator might require keeping the current separation in relation to the label. >> This is a very commonly extended pattern, so I'm unsure that a tooltip would be essential to ensure understanding. Nevertheless, I've found some recommendations that encourage this practice for extra clarification. The browser default on hover will do. > > That's a simple change, we just need the copy. Copy: Required All in all: there are two paths we can follow, the DS friendly one, or the fastest track. The first, characterized by having to contribute to Codex and replace WiKit components, we will have to walk sometime. If we followed the latter, then I agree to opt for the least costly changes: we could apply contextual overrides to modify the size and spacing of/around the existing text asterisk. TASK DETAIL https://phabricator.wikimedia.org/T322683 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Sarai-WMDE Cc: Michael, Sarai-WMDE, Nikki, Lydia_Pintscher, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
