Safari 17
Apple has released Safari 17 for macOS 13 Ventura and macOS 12 Monterey with new features and security updates—it’s the version that ships with macOS 14 Sonoma (see “macOS 14 Sonoma Now Available,” 26 September 2023). The updated Web browser introduces profiles to keep your browsing separate for topics like work and personal, separating your history, cookies, extensions, tab groups, and favorites for each profile. It also brings enhanced private browsing that locks your private browsing windows when you’re not using them and blocks known trackers from loading; a streamlined search that provides more relevant, faster, and easier-to-read results; and support for multiple tab selection. Finally, Safari 17 addresses five security vulnerabilities. You can download Safari 17 only via Software Update. (Free, release notes, macOS 12+)
In Safari 16, when you go to the Window menu, if you have one or more Tab Group open, the Tab Group name will show in front of the window titles. This was useful sometimes to help me identify “Tab Group windows” vs “regular windows”.
In Safari 17, the Tab Group names are gone when you look at the Window menu (you only see the window titles without the Tab Group names in front of them. Is there any way to get them back?
It also fixed a bug that first appeared in v.16.4, where jpegs on some websites were completely distorted and/or even showed up in the wrong place, as this screencap from the Washington Post shows:
They took away the means to disable CSS from the Develop menu; now, I have no means to expose the state of form controls (like checkboxes) that have been concealed by some piece-o’-crap inaccessible javascript widget that controls the field under the hood but which itself doesn’t expose the state (very common with “switches”). This is a major, major blow, and unless I can find a way to get the feature back, I’m going to have to think about using Chrome in those situations where an extension can be used to unhide (and position offscreen) such skinned controls. Or, horror of horrors, use Windows, where screen readers already do this trick that Apple for some reason disdains to do.
I’m sorry to say that I can’t participate in Tidbits polls for a spell for this reason. I hope I can find a fix soon.
All right, nailed it. It’s now in the Inspector–not ideal, since working with the page while the inspector is visible is a bit more difficult from the keyboard. But, it appears possible. And I filled in the browser poll.
Phew! Faith restored, for a bit.
I was also concerned when “Disable Styles” was no longer in the Develop menu (along with “Disable JavaScript” and "Disable Images). Having them in a DevTools menu instead is sometimes less convenient but I welcome the change that checking them only affects that particular tab instead of all tabs and windows.
(I don’t know how this browser feature helped you to fill out the web browser poll, it doesn’t even have real checkboxes hidden under the hood! The poll already mostly works as-is with only a keyboard but it looks unusable with assistive technologies like a screen reader or voice control.)
Ditto, concerning convenience of accessing the feature. I had a keyboard shortcut for this in the past. Never mind–it’s nothing I find myself using all the time, anyway, I just need it when I do. And having it on just this tab is much less disruptive; turning off styles can turn some sites into absolute wrecks, closer to explosions when all the context menus pop open and grab keyboard focus away. The whole web ecosystem is just horrible, really–if the W3C standardised these commonest of common controls, I could use this feature a great deal less.
Concerning the poll, I found that disabling styles made it easier to navigate using the keyboard and hear each individual widget even if it was just announced as “Group” or something similar, but in trying it without I eventually found that I could just count the number of presses of Tab to reliably select each toggle, and press Enter to change the state. The giveaway that this worked is that the submit button was no longer dimmed. So you’re right, in this case the help it gives is actually pretty minimal. How are these polls implemented then, absent checkboxes?
Reading the HTML code, each option is an HTML list item that’s been added to the tab order. Instead of checkboxes, it has inline SVGs that are initially just an empty square and when you click anywhere in the list item (except the links within the list items), some JavaScript changes the SVG and keeps track of which ones are checked; the JavaScript also listens for the Enter key being pressed while the list item is focused but unlike a proper checkbox, pressing the Spacebar doesn’t work.
It’s a silly, needlessly complex way to have more control over a checkbox’s appearance, especially for these checkboxes, which are quite ordinary. There are better ways: Inclusively Hiding & Styling Checkboxes and Radio Buttons.
Thank you for the details! I wish things could be better for web accessibility, generally.