| smustgrave |
@mherchel my question on this ticket is could we break out the Olivero piece from navigation to narrow the scope? |
| mherchel |
Just replied. Thanks for the nudges 🙂 |
| mherchel |
You making it to Chicago? |
| mherchel |
cause pretty sure I owe you a beer or three |
| smustgrave |
I am! |
| mherchel |
Sweet! |
| rkoller |
i like the suggestion by curtis in #19 using a dialog element. that would also solve the problem that at the moment you are unable to close the menu by pressing the esc key (edited) |
| smustgrave |
btw don’t forget to vote if this is the issue we want to focus on |
| KentR |
Voting for this b/c: What @catch said about “fixing“ old Toolbar issues by replacing it with Navigation makes a lot of sense. This is already Major priority. IMO it should be a blocker b/c it's already Major and b/c StatCounter says that 800x600 resolution is a significant portion worldwide for desktop browsers (which they say includes laptops). I can’t personally explain this, but it appears to be mostly driven by South America and Africa. Maybe it’s netbooks? IIRC the “mobile“ nav appears for me at <1024px. If StatCounter is correct and those users see the “mobile” nav on desktop, it's a big chunk of users. That said, after Navigation settles down I’d really like to see old Major / Critical issues land. |
| Curtis Wilcox |
Note that if a "mobile" navigation is contained within a , it exists a a copy separate from the one used in "desktop" layouts; you can't drag the viewport narrower/wider to switch between CSS breakpoints of the same element.Some JavaScript could at least partially create that kind of experience: use a matchMedia() event that's triggered when the viewport width is below a threshold, if focus was within the desktop nav, open the mobile dialog, move focus() to the corresponding element within. When the mobile nav is open, if viewport gets wider, I would stay in the mobile nav, keeping the desktop version hidden while dialog:open. |
| Curtis Wilcox |
Some of those 800x600 screens in stats are probably not physically that size but the users have lowered the resolution in the OS to make everything bigger.It's just like how "mobile" viewport sizes aren't necessarily on physically smaller screens, they could be in desktop windows that are filling the whole display or they are big windows but Page Zoom is making the CSS pixels larger. |
| KentR |
In that case (lowered resolution), would that make it behave like a smaller viewport and make the “mobile” version appear? For me, the “mobile“ version appears in Edge when I zoom up three clicks with Command +. IIUC, StatCounter determines “desktop” and “mobile” by the UA. For South America and Africa, StatCounter shows 29.74% and 18.04% respectively for 800x600. I guessed netbooks b/c they're relatively inexpensive, and it would make sense if they are popular in those places. |
| rkoller |
in regard of tracking, you want to use the tag to get an issue on the radar for these meetings or documenting which of the issues were discussed during and or because of the meeting? from my perspective the latter documenting which issues were discussed would make more sense, for raising and issue the person would only have to comment when a meeting takes place? |
| smustgrave |
Mainly trying to use it the same as we use bugsmash or needs-review-queue-initative.So in a few months we can say as a group we fixed 15 issues, triaged 20, etc |
| rkoller |
ah yep then it is the latter, any comments/work that is done on an issue as a "consequence" of these meetings should get tagged. thanks for the clarification. i agree |
| dww |
FWIW, I tag every core bug I'm involved in with "Bug Smash Initiative", even if it was never directly mentioned in #bugsmash (either triage or regular meetings). |
| dww |
Maybe that's not entirely accurate, but I consider myself a "bug smasher", and any time I'm fixing core bugs now, I'm doing it "on behalf of" that initiative. ¯\_(ツ)_/¯ |
| smustgrave |
I do the same! |
| smustgrave |
Not sure how to better word this. But sometimes I see that those with the accessibility minds sometimes need a developer to implement or vice versa. So how do we better build collaboration. I’m not a top dev but if anyone needs an developer eye or feedback feel free to ping me! |
| dww |
Love this! Also not sure exactly what to say or do. :sweat_smile: I consider myself a very solid dev, but with moderate accessibility knowledge. Definitely open to pings for accessibility fixes that need my dev skills. I try to bring accessibility awareness to anything I'm touching in core, but I'm sure I miss things all the time. |
| dww |
My a11y knowledge is almost entirely from being involved in a11y issues and reviews. I have 0 formal training in it. So at some level, I think the suggestion would be "learn by doing". But maybe there's more that could be done. |
| smustgrave |
Same boat. I was technically a DHS 508 certified test back in like 2017 but have since let that knowledge and cert lapse |
| the_g_bomb |
Ditto to the above, happy to be a dev ally for the a11y. #a11yAlly |
| smustgrave |
Can confirm the issue and almost positive that user used AI for the fix |
| rkoller |
ah is a comment like " // :white_check_mark: Correct logic: read the real current open state." an indicator for the use of a LLM? (edited) |
| smustgrave |
yup that green checkmark was the give away |
| Curtis Wilcox |
Why does details-aria.js even exist? elements inherently have an aria-expanded state that's changed when its is opened and closed.If it's meant to correct times when there have been browser bugs (looking at you, Safari), perhaps there should be a comment in the file, justifying its existence.If it should remain, iInstead of acting on a 'click' event on the , it should act on the toggle event on the . |
| rkoller |
hm i am not a developer and that kind of details are too deep into the weeds for my level of knowledge. but i searched a bit more in the code and looked what is triggering details-aria.js - it looks like details.js is triggering it. and its comment provides some more context. it looks like, it might provide some answers on the reasoning behind? * Open parent details elements of a targeted page fragment.
*
* Opens all (nested) details element on a hash change or fragment link click
* when the target is a child element, in order to make sure the targeted
* element is visible. Aria attributes on the summary
* are set by triggering the click event listener in details-aria.js.and looking at the comment in details-aria.js * Handles `aria-expanded` and `aria-pressed` attributes on details elements.i also wonder why aria-pressed is listed there? aria-pressed isnt used neither on the desktop nor on the smartphone i've just tested with. so as you said the entire approach might need some reevaluation |
| Curtis Wilcox |
I saw a previous commit already removed aria-pressed from details-aria.js.Expanding to expose targeted fragments within is a nice idea for details.js to attempt. elements automatically have the .ariaExpanded = true property when their element is in the open state so there shouldn't be any aria-expanded attributes on them at all.BTW, opening to expose targeted fragments is now native behavior, at least within browsers that support the new global attribute value, hidden="until-found" (note that Firefox and Safari apparently have bugs so they'll open them but not scroll them into view). It might go back a little further, to when browsers switched closed contents from being display: none to content-visibility: hidden. or when they supported the ::details-content pseudo-element. |
Comments
Comment #2
rkolleradded the accessibility tag. guess for future discoverability that might be handy.
Comment #3
smustgrave commentedComment #4
smustgrave commented