Quip - Collaborative documents & messaging

Quip offers a straightforward platform for teams to collaborate on living documents. It merges chat, documentation, task lists, and spreadsheets into a single application, facilitating swift and easy collaboration. Bypass the tedious back-and-forth of emails, meetings, messages, and multiple document versions by using Quip on your desktop, tablet, or mobile device. Experience your team's productivity truly come to life.

DOCUMENT AND TASK LIST SHARING

- Collaborate on documents with colleagues in your office

- Take notes at work and modify them from your mobile device

- Share grocery lists with family members

- Organize tasks for both home and office environments

- Work together and communicate with any group or team on projects and documents

- Task lists allow for real-time updates, so you are notified immediately when someone completes a task

MESSAGE AND CHAT FUNCTIONALITY

- Real-time messaging is seamlessly integrated with your documents and spreadsheets

- Access your conversations from your smartphone, tablet, or computer to stay updated

- The chat function works across various devices, allowing communication regardless of the technology used by others

- Form group chats effortlessly for friends or colleagues

SPREADSHEETS

- Comprehensive spreadsheet features with support for over 400 functions

- Customized mobile keyboard options enhance the editing experience on any device

- Spreadsheets can operate independently or be included within your documents

- Collaborative spreadsheet work simplifies maintaining office contact lists or organizing social events

- Features enable comments and annotations on a cell-by-cell basis

ACCESSIBILITY ACROSS ALL DEVICES

- Your chats, documents, task lists, and spreadsheets are accessible on all devices—smartphone, tablet, and desktop

- Review modifications, comments, and annotations on your documents and spreadsheets easily from anywhere

- Offline capabilities ensure you can always access your documents and spreadsheets

- Automatic synchronization occurs across devices once you reconnect online

IMPORTING AND EXPORTING

- Bring in documents from services like Dropbox, Evernote, Google Drive, Box, and Google Docs

- Export documents to PDF or Microsoft Word formats

- Export spreadsheets directly to Microsoft Excel

- Import your contacts from email providers such as Gmail, Yahoo, Hotmail, Microsoft Outlook, or Google

Quip is also available for desktops (Mac and PC).

If you're interested in participating in testing an upcoming version of Quip, consider joining our beta program.

Collaborate without leaving Salesforce

Quip brings documents, spreadsheets, and chat together in one place in Salesforce.

Documents that drive a culture of practice

Quip documents unify teamwork and communication so you can get everything done in one place.

Offline mode Permissions Version history

Spreadsheets that turn numbers into decisions

Create strategic sales documents that accelerate decisions and advance deals with live Salesforce data and real-time chat.

Mobile compatible Collaborative editing Embedded documents

Chat that breaks down information silos

Streamline your workflow with team chat built into every doc and spreadsheet, plus chat rooms and 1:1 messaging.

Comment on anything 1:1 chat Team chat rooms

Making the Quip editor accessible

In our last blog post, we gave an overview of the work that Quip’s dedicated accessibility team has been doing since 2020. But the story didn’t start there!

Back in 2018, I was part of a brief initial effort spun up by Quip to explore and fix our most glaring accessibility-related issues. We quickly realized that the worst of the roadblocks were fundamental challenges with the centerpiece of the product: our multiplayer document editor, which allows for all sorts of embedded rich objects (such as user mentions, embedded spreadsheets, and live apps).

ContentEditable support = false

Quip’s editor is based around an article node with contenteditable=true set on it. This single HTML attribute caused some browsers and screen readers to suddenly stop supporting even the most commonly-used ARIA attributes used to manipulate the accessibility tree. Our initial explorations quickly found that our problems wouldn’t be solved just by fixing markup that didn’t meet WCAG guidelines: we would also need to actively uncover (and work around) idiosyncrasies in screen reader and rendering engine implementations that didn’t behave according to standards.

Given limited time, the 2018 team decided to focus on more modest goals. For one thing, we unblocked screen reader users from at least reading document content by introducing a keyboard shortcut (now Cmd+Opt+R or Ctrl+Alt+R) that removed the contenteditable attribute on the editor HTML node, disabling editing but allowing for a much better reading experience. We also built affordances that let screen reader users semantically navigate many oddly-structured types of editor content.

As an example: for performance reasons, all bulleted list sections in Quip — regardless of how many nested sublists they contain — are rendered as a single flat ul element, with each li child indented to an appropriate level using CSS to limit how much of the DOM are touched during indentation changes. However, screen readers have no awareness of the visual hierarchy of sublists that results from this indentation. To resolve this, we constructed a parallel DOM structure to express that hierarchy via aria-owns.

While we managed to make navigating basic content types much clearer in read-only circumstances, we were still left with the unsolved problem of a coherent editing experience. When the current accessibility team spun up in 2020, we knew we had to focus on finding a technical approach that would solve this problem while minimally disturbing our vast and complex editor codebase.

The roads not taken

Before work started, we conducted a comprehensive survey of screen reader behavior in other document editing products. The approach we found in many of these products avoided fixing behavior or markup inside the document editor itself, instead choosing to use a separate off-screen aria-live="assertive" region to interrupt whatever the screen reader usually reports after an action. For example, navigating down a line or typing a character would replace the text in this live region with that line of text or that character.

This approach initially appealed to us, as it would allow us to abstract accessibility behavior from the rest of the codebase, and our team only would only have to maintain a single HTML node instead of dealing with the intricacies of existing editor objects. However, we ultimately decided not to head down this path. From an engineering standpoint, we were wary of how much micromanaging we would need to do — everything a user could possibly do in the editor would need to manually update the content of the live region. Between the complexity of our editor code and how many other engineers were modifying it regularly, this would have created a breeding ground for bugs.

More importantly, we received clear community feedback that this approach wasn’t ideal for real screen reader users for several reasons. For one, our lack of direct control over the timing of the screen reader queue meant that users might end up with an unreliable reading experience. Moreover, this approach forces a single screen reader experience onto all users—we would override all of their preferences, as well as potentially deviate from their expectations about how different actions and elements are announced.

Another approach we floated but quickly abandoned was the idea of creating a simpler, less dynamic markdown-only editor. Though this might have been a lot simpler as a short-term solution, we realized it would ultimately create a second-class experience with many drawbacks for our users while introducing a new divergent surface for us to continually maintain and update.

We made a conscious decision to do the right thing by our users (and our future selves) even if it would be hard in the short-term: take advantage of what the ARIA spec supported and fix the behavior of the elements actually in the DOM.