Time trackers that ask for Accessibility permission, and one that doesn't

23 August 2026 · 6 min read

A Mac time tracker asks for Accessibility permission because it wants to read window titles, document names and browser URLs, and macOS will not hand those over without it. The permission itself is far broader than that: an app with Accessibility access can read the text of any window, watch every keystroke, and control other apps as if it were you. A tracker that only records which app is in front needs none of it, because macOS tells any app the name of the frontmost application for free. This post explains what the permission grants, why trackers want it, how to see which apps already have it, and what you give up with a tracker that never asks.

What Accessibility permission actually grants

The permission lives in System Settings, Privacy & Security, Accessibility, and its name undersells it. It was designed for assistive software (screen readers, switch controls, voice control) that has to see and operate every app on the Mac on the user’s behalf. To do that job, an app with the permission can:

• Read the title of any window in any app
• Read the text content of windows and controls, including the address bar in a browser
• Observe keyboard input system-wide
• Move the pointer, click, type and press keys in other apps

None of those can be granted separately. An app that wants the first one gets all four. That is why macOS puts the permission behind a lock, a password, and a warning, and why you should treat a request for it as “this app wants to see everything I do”, because technically that is what it is asking.

Accessibility permission on a Mac: what it grants and why apps ask goes through the permission in general. The rest of this post is about trackers specifically.

Why trackers want it

A tracker that knows only “Safari, 2 hours” cannot say which two hours. To write “docs.example.com, 40 minutes” or “Q3 budget.xlsx, 1 hour 10”, it has to read the window title or the URL, and that needs Accessibility (or, for the URL in some browsers, a scripting permission that prompts separately). Some trackers go further and take periodic screenshots, which needs Screen Recording, a different and equally broad permission; why a time tracker should never need Screen Recording covers that one.

The request is usually honest. Most trackers that ask for Accessibility do use it only for titles. But “we only use it for titles” is a promise, not a property of the permission, and you are trusting the app’s code, its update pipeline, and its eventual acquirer to keep the promise. For a tool whose entire job is to sit in the background for years, that is a long time to trust.

There is also what the titles themselves contain. A window title is a document name, a subject line, a page heading, a client’s company name, a patient’s file. A record of every title you had in front all day is a diary you did not write, stored wherever the tracker stores it. Why most time trackers want your window titles, and what that means is about that record.

How to check which apps have it now

Worth doing once, whether or not you change trackers.

1. Open System Settings.
2. Click Privacy & Security in the sidebar.
3. Click Accessibility.
4. Read the list. Every app with the switch on can do everything in the section above.
5. For each one, ask whether you know why it is there. Window managers, clipboard tools, text expanders and assistive apps usually have a reason. A time tracker has a reason only if you want titles on your report.
6. Turn off anything you cannot account for. If an app then stops working, it will tell you, and you can decide whether the feature was worth it.

While you are there, look at Screen Recording and Input Monitoring too. A tracker in any of those lists is reading more than app names.

What a tracker can do without the permission

macOS tells every running app which application is frontmost, without any permission, through ordinary system notifications. That is enough to build a complete record of the day at the app level: the editor for this long, the browser for that long, the chat app for the rest. It is not enough to know which document or which site, and no amount of cleverness changes that.

Punchcard is built on exactly that boundary. It asks for zero permissions: no Accessibility, no Screen Recording, no Full Disk Access, no Input Monitoring. It records app names only, never window titles, document names, URLs, keystrokes or screen contents, and it cannot be updated into doing so without starting to ask. At the closing time you set it prints a receipt of the day, itemized by app with a total, and that is the whole product.

The cost is that the receipt says “Safari, 2h 10m” and not which sites. If you need the sites, Punchcard is the wrong tool and a tracker that asks for Accessibility is the right one; that is a real trade and not a trick. If what you want is the shape of the day, the app-level record turns out to be what you actually read anyway, and the titles were a liability you were carrying for a line you skimmed.

There is a second consequence. Because Punchcard holds nothing sensitive, it does not need to protect anything with an account, encryption at rest, or a cloud: the record is a single SQLite file on your Mac, exportable as CSV and deletable with one button. An app with no networking code at all has nowhere to send window titles even if it had them.

Deciding what you actually need

Ask one question: will I read the detail?

If you bill clients per document, or you audit your own browsing, the titles earn their place and the permission is the price. Grant it to a tracker you have chosen deliberately, check the list once a year, and accept that the record is sensitive and store it accordingly.

If you want to know where the day went, the app-level record answers it, and a tracker that never asks for Accessibility is a tracker you never have to think about again. What Mac apps can see about you, permission by permission is the broader map if you want to audit everything else on the Mac the same way.

Questions

Is Accessibility permission dangerous on its own?

It is broad rather than dangerous. A well-behaved app with the permission does only what it says. The issue is that the permission cannot be narrowed, so you are trusting the app entirely, for as long as it has the switch on.

Can a tracker read window titles without Accessibility?

Not reliably. Some information leaks through other channels for some apps, but the supported way to read another app’s window titles is the Accessibility API, and a tracker that shows titles has that permission or a scripting equivalent.

If Punchcard cannot see titles, how does it know I was working?

It does not. It knows the editor was in front for three hours, and it prints that. Whether the three hours were work is a judgment it leaves to you, which is also what the title-reading trackers leave to you, after collecting a lot more.

Does revoking Accessibility from my current tracker break its history?

No. The history is already stored. Revoking the permission stops new titles from being collected; the old ones stay wherever the tracker keeps them until you delete them. How to delete everything an app knows about you covers finding and removing that.