Tab Sync Explained: How It Works Under the Hood

What is the accessibility tree?

Every web page in your browser has two representations. The first is the visual one: the pixels you see on screen, the colors, the layout, the fonts. The second is the accessibility tree, a structured data model that describes the content and purpose of every element on the page. The accessibility tree exists so that screen readers (like JAWS, NVDA, or VoiceOver) can read web pages aloud to people who cannot see the screen.

When a calendar application like Outlook renders a week view, each event on that page has an accessibility tree node. That node contains information like the event title, start time, end time, and sometimes the location or attendees. This information is encoded in ARIA labels, role attributes, and text content that the browser exposes through its accessibility APIs.

Tab Sync reads this accessibility tree. It does not intercept network requests, modify cookies, inject scripts into other domains, or do anything that would require elevated browser permissions. It reads the same structured data that a screen reader would read. The difference is that instead of speaking the data aloud, the extension parses it into calendar events.

How the extension reads a calendar tab

When you add a tab calendar in manyCalendars, the extension stores the URL pattern for that tab (for example, outlook.office.com/calendar/*). On a configurable interval (default: every 15 minutes), the extension checks whether a tab matching that pattern is open. If it is, the extension reads the accessibility tree of that tab directly. If no matching tab is open, the extension silently opens the URL in a background window, waits for the page to load, reads the tree, and closes the window.

The parsing step is where the real work happens. Calendar applications do not use a standardized accessibility structure. Outlook uses a different DOM layout than Google Calendar, which uses a different layout than Apple Calendar on iCloud. The extension ships with parser modules for each supported calendar platform. Each parser knows how to navigate that platform's specific accessibility tree structure to extract event titles, times, and metadata.

Once parsed, the events are stored locally in the extension's storage (IndexedDB). They are merged with events from ICS feeds and manual calendars to produce the unified view. At no point does any of this data leave your browser. The extension makes zero network requests to any manyCalendars server as part of the syncing process.

Why this approach is privacy-safe

The privacy model of Tab Sync is straightforward: your calendars are read and merged on your device, not in our cloud. Compare this to API-based calendar aggregation tools, which require you to grant OAuth access to your calendar. When you do that, the third-party service receives a token that lets it read your entire calendar history, typically including past events, attendee email addresses, meeting notes, and recurring patterns. That data is then stored on their servers, processed by their infrastructure, and subject to their security practices and privacy policies.

Tab Sync eliminates this entire attack surface. The extension reads what is visible on the page (typically one week of events), parses it into a minimal data structure (title, start, end, location), and stores it locally. It does not have access to your calendar's API. It cannot read historical events that are not displayed on the page. It cannot access attendee details beyond what the calendar UI shows. It cannot modify your calendar in any way.

This is a deliberate trade-off. API-based approaches are more powerful (they can read all events, sync bidirectionally, access full metadata), but they require permissions that most contractors cannot get and create privacy exposure that most privacy-conscious users do not want. Tab Sync is less powerful but requires zero permissions beyond what you already have as a logged-in user.

Comparison to API-based approaches

API-based calendar integrations (like those used by Calendly, Reclaim, or Clockwise) work by requesting OAuth tokens from Google, Microsoft, or Apple. These tokens grant the third-party app read (and sometimes write) access to your calendar via the provider's API. This is the standard approach, and it works well when you have a single calendar provider and you control the IT settings for that provider.

For contractors, the API approach breaks down in two places. First, corporate IT departments frequently restrict which third-party apps can receive OAuth tokens. If your client's Google Workspace admin has not approved a specific app, the OAuth flow will fail with an "app not approved" error, and you have no recourse short of asking IT for an exception. Second, even if the OAuth flow succeeds, you are now trusting a third-party server with your corporate calendar data, which may violate your NDA or your client's data handling policies.

Tab Sync sidesteps both problems. It does not use OAuth, so there is nothing for IT to block. It does not send data to a server, so there is nothing to violate a data handling policy. The trade-off is that Tab Sync can only read what is currently visible on the page, and it requires the calendar to be loaded in a browser tab (even if only briefly in the background). For most users, this trade-off is well worth the zero-permission, zero-server-trust model.

Known limitations

Tab Sync is not a perfect solution. It has real limitations that you should be aware of. First, it can only see events that are rendered on the page. If you are viewing a week view, the extension sees that week's events. Events from next month are not visible and therefore not synced. The extension mitigates this by syncing frequently and by prompting you to navigate to the current week if it detects the tab is showing a different date range.

Second, if a calendar application renders events inside iframes or shadow DOM elements that the browser's content script cannot reach, the parser may miss them. This affects a small number of corporate Outlook tenants that use non-standard rendering. We add support for new rendering patterns as users report them.

Third, Tab Sync depends on your login session remaining valid. If your corporate Outlook session expires (most enterprise tenants enforce re-authentication every 8 to 24 hours), the next sync attempt will fail. The extension shows a "Needs sign-in" indicator when this happens, and you can resolve it by opening the calendar in any tab and signing in again.

Despite these limitations, Tab Sync remains the only practical way to aggregate calendars from locked-down corporate environments without IT cooperation. It works because it operates at the same privilege level as you, the logged-in user, rather than requiring elevated API permissions that you do not have.