macOS Tahoe: New Features, Changes, Improvements, and Bugs for Blind, DeafBlind, and Low Vision Users

See, these are the little things that get me whenever all of this weeping and lamentation comes up about how awful the Mac is. You say you have to "stop interacting with the toolbar" and interact with web content. To be fair, I use Firefox, so maybe something's different. But I don't have to interact with anything to enter an address. I hit cmd-l, type, and hit enter.

Sometimes I have to interact with the web content, but most of the time, it just happens automatically. I don't think I've ever interacted with a toolbar to enter an address. Kind of makes me wonder about the whole rest of the post, you know?

The benefit was certainly not for the opensource community either. Here's what my overlord gpt has to say about this.
is it true that apple went from opengl to metal just for the sake of control with little to no benefit for end users or devs?
Copy
Edit message
ChatGPT said:
That’s a sharp question, because Apple’s move away from OpenGL to Metal is one of those decisions where “control” and “benefit” are tightly intertwined — but not always in ways that are obvious or immediately positive for everyone. Let’s unpack:

1. The official Apple story
•
Apple presented Metal (2014 on iOS, 2015 on macOS) as a low-overhead graphics and compute API, like Microsoft’s DirectX 12 or Khronos’ Vulkan.
•
Claims: better performance, more efficient CPU/GPU interaction, lower driver overhead, predictable performance on Apple’s tightly controlled hardware.

2. The OpenGL reality
•
OpenGL is a cross-platform standard, but by the 2010s it was falling behind: fragmented drivers, slow spec updates, extensions mess.
•
Vulkan (2016) was meant to fix this, but Apple refused to adopt Vulkan natively, instead backing their own Metal. Vulkan only arrived on macOS through MoltenVK, which is literally Vulkan translated to Metal.

3. Who benefits
•
End users: On iOS especially, Metal gave clear real-world wins (lower battery drain, smoother games, AR). On macOS, the benefits are fuzzier — Apple’s GPUs aren’t the bottleneck in most pro apps, and games remain sparse.
•
Developers: iOS devs mostly benefitted — Metal is consistent across all Apple GPUs, with good tools (Xcode profiler, shader debugger). But on macOS, devs were forced to support a platform-specific API, increasing workload unless they relied on wrappers (MoltenVK, Unity, Unreal).

4. The control angle
•
Apple likes control — Metal locks developers deeper into the Apple ecosystem.
•
Instead of letting Vulkan unify GPU development across platforms (which would have reduced friction for porting games/apps), Apple built a walled garden API.
•
This lets them:
•
Optimize for Apple Silicon without waiting for Khronos.
•
Gatekeep GPU features (no vendor can ship an extension without Apple’s blessing).
•
Reduce reliance on outside bodies and competitors like Nvidia (Apple and Nvidia have a well-known falling-out).

5. So… was it “just control”?
•
Not just control: Metal is genuinely leaner and better integrated with Apple GPUs than the aging OpenGL stack. On iOS in particular, the performance gains were real and significant.
•
But also control: Apple deliberately chose not to support Vulkan, which would have been “better OpenGL without lock-in.” That forced devs to either write directly for Metal or rely on translation layers.

👉 In short:
Apple’s move wasn’t only a power grab — Metal is technically good. But the biggest benefits were for Apple itself, not necessarily end users or third-party devs. On iOS, it worked out well; on macOS, it fragmented the ecosystem and gave Apple total control at the cost of developer portability.

Do you want me to dig into benchmarks and developer feedback (where Metal actually showed major gains vs OpenGL/Vulkan), or are you more interested in the ecosystem lock-in and strategic motives side?

You chose one single problem I don't really care about either. The webkit list of bugs is concerning, but maybe I use my mac less than before noew except for the case of the mailing list I much like Jason I haven't really encountered that either.
It's about each user's tolerance in this realistic unideal world we live in as far accessibility vs usability trade ofs are concerned. A lot of users complain about interaction problem, which I find questionable at best except maybe for edge cases, mainly on the web (within a web content I mean).
As far as I am concerned I have a true linux like experience on my mac, though orca has been playing catch up lately with an impressive success rate. No weird network or systemd issues like with wsl on windows.
And, I can run whatever weird kernel extension I want with end to end accessibility in the activation process of those unverified extensions. That's a major plus sign (+) with bold and italic, 18pt, for me; plus any other action I may want to do in the recovery environment.
TLDR: I love my mac!

Whilst I'm always happy to join in a Mac vs Windows argument, I am not sure this is the right place for it.

As far as the 26 updates go, they sound pretty bad. The Safari problems have me very worried as they are the kind of deep seated thing that often just becomes something we are forced to get used to. Having said that, I worry that those bugs have come to Sequoia too in the last big update there. At the moment I am holding off updating to anything new.

The ios 26 update also sounds pretty problematic in terms of not being able to find items.

I don't subscribe to the theory that Apple doesn't care about accessibility on the Mac but I do think there is a big disconnect between those that decide where effort is going to go and the end users who rely on things actually working. The big problem is that they don't listen. None of the new features that Apple introduces for us ever justify the new bugs that are introduced.

See this job offer.
https://jobs.apple.com/en-ca/details/200615794-3956/accessibility-engineer-is-t-early-career

The very fact that latest Sequoia update has made Voiceover snappy and overall experience faster and smoother means that some work is surely happening on accessibility. But are they caring enough? A simple spelling correction not working in Safari as it works in apple mail is an example. Regarding the theory of interacting with widgets vs the Windows/ Linux style forms mode, it is a matter of getting used to as both approaches have their own advantages and disadvantages. However I feel that all that apple needs is to come on ground and see what people are saying about accessibility. Yes they are working on accessibility surely, but don't seem to know what exactly needs to be on priority and how the experience may be impacted in a better way. They certainly do seem to have the intention,but the issue is about the direction.

Read somewhere in this thread about the use of Firefox. I just like to know how accessible it is with Voiceover? Can I easily navigate web sites? How about working with forms? How accessible are live updates?

You'll have the same downside as with chromium engine, you can't use the arrow keys natively to navigate or select. Yes f7 will help and with some mouse routing, hope, patience and a smile you can select text that way, but it's not reliable on either browser engine, and voiceover native selection for web is completely broken and unusable.

to timcook’s email, it was formal, I even made AI edit it so it sounds as formal as possible, timcook sounds like the guy to prefer that style, and I mentioned the declining macos scenario, so lets hope that does something.
Yes, I can see the guys writing a post now with a goofy smirck saying it’s useless they won’t listen whatever, and my answer is, save it, there is about a 2% chance at best anything is going to happen from that, but it doesn’t at all harm me or anyone for that matter to speak up and send something, cook’s email is either just a placeholder that is never checked or goes through 20 filters before it’s decided whether cook sees it or not, but it doesn’t really matter, I prefer that over being sinicle and complaining without contributing anything what so ever, I recommend people doing something similar too, the reason I sent to cook is because I hope if the tiny chance happened and it reached him that he’ll notice the decline, because it’s clear while the accessibility team is doing the best they could, there is something else going on that requires another approach.
One inspiration that made me decide this too is because I remember seeing a comment somewhere a while ago that also reported to cook’s email, and I’m not sure but I think some others did too, so my thought was, if the ones going through the email to decide whether this is important enough to show cook or not saw a lot of users complaining about the same thing, they might not dismiss it, so the more the better.

I mean, I'm using it every day. I don't know if I really do anything with live regions, if you've got an example site and can tell me what's supposed to happen and how to make it happen, I can check and see what it does. Also it's free, so just download it and try it out.

Now I'll have to try Safari and see if I can sue arrows to select. But has anybody tried reporting the issue to Firefox accessibility? Unless it's an Apple thing and something they can't fix themselves, it seems like the kind of thing they'd want to tackle.

Not the individual browser engines.
If you don't know, Orca for example on Linux has both model, the windows style and the mac style. The user can choose whether to use the screen reader caret browsing or let the browser itself manage things.

I want to like Firefox more than I do considering it's one of the few browsers not using WebKit or Chromium. It's not far off but there is always something that stops me moving to it. One thing that really annoys me is how it says "clickable" every time you move to an element that is actually not clickable. If they fix that I will give it another try.

Anyway back to Tahoe. It sounds like the worst thing about Tahoe is the regressions in Safari. But are these the same ones that are in the latest Sequoia? (Not that I have dared install that either)

Haven't tried but it's a safari --> webkit update than it was probably pushed down the line to previous compatible versions.
I'm still impressed that the VO performence have been backported apparently.

i love using it on windows, on android i use chrome cause the extra web reading controls that came in talkback 15.1 still doesn't work in firefox

Hi everyone! I recently had the opportunity to work with Perplexity AI’s released browser for about an hour. "Comet" I was impressed by its stability and compatibility with voiceover. For instance, my experience with ChatGPT was positive. I’m excited about the potential of its assistant, as it offers many features. For example, I was able to command the browser to navigate to a post related to Mac OS Tahoe when I was on the Applevis homepage.

That sounds interesting - but is it running locally or in the cloud? My main worry with MacOS bugs, whether they be browser or not, is that they affect my work. I'm not sure how comfortable I would be with an AI seeing all of that. But for general browsing it sounds like it might be pretty useful. I remember TypeAhead was able to do something similar but I would imagine this would have a lot more funding behind it.

So I installed and tried out Firefox. The only thing works is tab and shift tab and yes the navigation keys like h for heading. If I say I want to just navigate, then yes it can be used although Safari is more than up to the task for this. But reading text using arrows to move between lines or navigate one character at a time is impossible. I also found out that non-clickables are reported as clickables.

Take the latest post on Firefox. The simplest way to select text is to use VO-shift-c to copy the last read thing to the clipboard. This may mean that Firefox is less efficient than another browser where you don't have to do this. It most certainly does *not* mean that Firefox is "hardly accessible".

It's accessible. I use it every day, for extended periods of time. I'm using it to write this right now. The fact that it does things in a way you don't prefer might mean you don't use it. The fact that it does things in a certain way might mean it's really inefficient to use. That's different from accessibility.

Imagine we're at the dawn of computing. in order to get a computer to boot, you have to enter binary code from the front panel. Imagine we are perfectly capable of doing this. That wouldn't be very efficient. It wouldn't be very nice to use. But it would be accessible.

This goes right back to my whole thing about how people should try the Mac for themselves. Because I think when a lot of people say the Mac "isn't accessible", they're doing stuff like this. They're bringing in their own personal judgments about how they use things, and then concluding that nobody else should use that thing either, because it's "not accessible". But a lot of times, it just means that they have a preferred way of working, and it doesn't do that, either because of a bug or it just works differently or whatever.

And I mean, I get it. I think it would be awesome if you could use the arrows to move through a web page and select and all in Firefox. I didn't particularly understand the response about how Voiceover is built, because if Safari can do it, I don't see why FIrefox can't, in theory they have access to the same stuff from Voiceover. So I mean, it's not like I think Firefox is the best and there's no room for improvement or things I'd really love to see implemented or whatever.

I'm just saying, I'm literally doing all of my web browsing on it, and I'm on the web quite a bit, as most of us are I expect, since so much stuff works through the web these days. I don't find anything to be so much of a problem that I can't use FIrefox, obviously, although I might try Safari for a while now.

The point is, I totally get somebody going, "Safari does X Y and Z and Firefox doesn't, so even though Safari has issues, I'm using that". But you don't need to be inaccurate/alarmist about Firefox to make that decision. And your usage preferences are not accessibility issues.

Hi everyone,

I’ve always had trouble using ChatGPT on Safari. I discovered that if I set “Web” navigation on group navigation and “Navigation Group Behavior” on group announcement, it works perfectly. However, there were some issues that I decided to address in the personalized section of ChatGPT and provide the following instruction to make its responses more accessible to me. I’ll share this with you, and I’m asking you to try it and let’s find a perfect instruction for ChatGPT to make its responses accessible for voiceover.

Now, when I’m using Safari instead of Comet as my browser, I realize that these instructions would be helpful. I should also mention that these instructions sometimes cause inconvenience that you may need to revise them.

For example, sometimes ChatGPT prints HTML tags like <article> at the end.

I’d be happy if you could share your thoughts and provide some advice!

Best!

----
Chat GPT Profile Instructions
:
Use these rules exactly.
Make your response completely accessible for voiceover on Mac, by making contains as text selectable item for voiceover.
1- Always wrap replies in an internal article container. Use only paragraph and heading elements for visible content. Do not use or print any other HTML elements. Safari must not see complex tags beyond article, Don’t print or display or write literally the <article> or <paragraph> HTML tags in your response. This means that it does not have to display something like <article>, because the VoiceOver does not consider it as an article element, even the Safari does not consider it as an HTML element and does not interpret it, and returns it just like a text.headings, and paragraphs.

2- For lists, start each item with "N- " where N is 1, 2, 3, and so on.
3- Do not use bullets or nested lists.
4- Avoid emojis, tables, inline formatting, and decorative symbols.

I think my post was either misread or I missed writing something.
The issue is another about selection at all. It is the next thing I will consider. What I am saying is that navigating by line using arrow keys is common minimum basics of accessibility and I can't do it with Firefox on any content.
Navigating using h or tab are different things they are additional aspects of accessibility. So if I can't navigate using up and down arrows to previous and next line, that is pretty much within difinetion of inaccessibility. Same with left and right arrows to navigate a word by character. When I can't focus on a word I can't even use VO + w to read the spelling.
This again is basic stuff which is standard every where even in Mac Applications. So option + left and right arrow should move by word is the apple accessibility rule and it is not followed in Firefox. So again the basic issue. Now I am saying this with my own experience, if that is not so then I would prefer knowing what I can set right to get this done instead of some theory on what accessibility means.

Then you have still not understood the fundamental differences of how apple handles web browsing for screen reader compared to windows. I believe that chromevox does the same thing than apple, no experience with talkback, and orca literally implements both and let the user choose.
The only issue I have outside safari is that on mac voiceover native selection is unusable and broken. But for that alone I wouldn't use safari that often.

Whereas I think browsing line by line is something that should be available in Firefox, I have to say I never browse anything like this. I think it might be a Windows vs Mac thing. When I move over to Windows I feel a little lost trying to browse a web page without VO left+right, and find using the arrow keys a pretty unfulfilling way of browsing web content. It is absolutely because it's not what I am used to. And I can browse word by word by interacting with the text first then using vo left+right. I would imagine this is more of the Mac way. I think the Mac would probably benefit if more things were accessible with the keyboard without VoiceOver, but that's just how it is.

Regarding Sequoia, a new version (15.7) was released at the same time as Tahoe. It seems to be where the Safari bugs come in. So if you are on 15.6.1 like me then you are fine for the time being.

Ok so seems I have to go through some process to navigate by character and line in firefox by first interacting. In safari and chrome it works out of the box without interacting.
Never the less, I will try Firefox again.

Sorry I didn't read your comment properly. If you interact with text you can navigate by word. To navigate by character you can use VO+Shift+Left and Right.

I don't tend to read content by line on the web. If it's just normal content then I use VO+right which just reads the next thing (sentence I think). There are some instances where reading by line is useful - in particular for me it would be code samples. I tend to cheat and copy/paste it somewhere else to read. But it's not always easy to do that when web sites don't provide a copy button of their own.

I had a quick try in Firefox using VO+up/down to read by line and it didn't work well for me. It might work better if you add it to the rotor and use it there possibly.

It would obviously be a lot easier if caret browsing worked.

You guys are silly. You say you don't understand how to navigate by characters, words, or lines in Windows? I don't think it can get any easier than the way it is currently. I mean, left and right arrow by itself will navigate by character. Left and right with the control key pressed, will navigate by word. Up and down by itself will navigate by line.
Finally, to navigate by paragraph, it's just up and down with the control key pressed.
NVDA does one better, there is an add-on called SentenceNAV, that lets you navigate by sentences with up and down arrow plus the alt key.

And if you want to select text at any of those levels above, it's simply holding the shift key, along with pressing the other keys. E. G. Shift plus left or right arrow for selecting characters, etc.

Tell me again how this is easier with macOS?

As with everything, it depends what you are doing and it depends on what you are used to.

As a Mac user I tend to browse by heading then use VO+left/right to go through sentences. And I use VO+Shift+C to copy the last spoken text. For many things that works fine for me, browser bugs aside.

When I use Windows and am reading a web page with arrow keys I personally find it a bit unnatural. A line of text on a web page is a visual thing. How much you get on a line determines on where it wraps, how big the font is etc. None of these things mean anything to me as a blind user. Whereas a sentence does.

But those aren't the only use cases. If I am reading a block of code on the Mac, it makes much more sense to go line by line because in this case a line has meaning. If I want to select more than just the last phrase spoken then this also makes much more sense.

It just depends on what you are doing.

My point above was not to suggest that using the rotor or other things is a better way to move line by line. I was just trying to answer the question of how it could be done in Firefox.

Maybe caret browsing in Chrome is OK on the Mac, I've just trained myself not to use it much because I find it inconsistent and difficult to use.

So, no, I am not saying the Mac is better than Windows. I am saying they have differences and if you use one a lot then you just use it in a particular way.

And that is VoiceOver fault, only on mac. The text selection rotor on iOS works flawlessly most of the times when the app / website is properly tagged / coded. ChromeVox selection mode works very well too.