Grackle Docs Step by Step Guide

Accessibility is a collective responsibility.

By adopting these straightforward guidelines, you ensure your documents reach everyone, including people with disabilities. This approach moves beyond mere regulatory compliance, fostering a truly inclusive environment where information is available to all. The effort invested today is a direct contribution to a more equitable world.

How does it work:

Grackle analyzes your document by categorizing content into images, headings, tables, and text. The accessibility check panel provides an initial summary of passed checks, then guides you through each category. It highlights specific elements requiring attention with alerts while marking compliant items with a checkmark.

Follow the steps below to bring your document into compliance then export to PDF to distribution.

Use any of your Google Doc files or try Grackle with this Sample Google Doc.

Document

Document title is required

Your document title typically defaults to the Google Doc name, but you can confirm and edit your document title if needed.

Open Grackle Docs.
Select Document title is required.
Select Edit or check Use the Google Doc name.

Document language should be specified

Your document’s language will most likely be predetermined. If you need to change your document’s language:

Select File in the top menu.
Select Language.
Choose your desired language from the list.

Images

Images should have alternative text or mark as artifact

Select the image that is being flagged.
Select Image Options.
Select Alt Text.
Enter your alt text into the Description text field.

Drawings should have alternative text or mark as artifacts

Select the image that is being flagged.
Select Image Options.
Select Alt Text.
Enter your alt text into the Description text field.

Equations should be described

Mathematical equations in Google Docs are not fully accessible and need alt text added.

Select Equations should be described.
Select TAG.
Add accurate alt text in the description box.

Headings

Headings should be used

If text is visually a heading, it must also have a programmatic heading.

To add a heading:

Select the text you want to make a heading.
Select the Styles dropdown in the toolbar.
Select a heading level.

A single “Heading 1” should be used

Each document should have at least one “Heading 1”.

Select the text you want to make the Heading 1.
Select the Styles dropdown in the toolbar.
Select Heading 1.

Headings must be properly nested

Use heading levels in order and do not skip heading levels.

Example of a correct heading structure:

Heading 1: Main title

Heading 2: Subheading

Heading 3: Sub subheading

Heading 2: Subheading

To change a heading tag:

Select the text you want to make a heading.
Select the Styles dropdown in the toolbar.
Select your desired heading level.

Tables

Tables must be tagged or marked as layout tables

It is best practice to only use tables for tabular data, not for page layout.

To tag a table:

Open Grackle Docs.
Select Tables must be tagged or marked as layout tables.
Select TAG.
In the pop-up window, mark header and column rows appropriately, or mark the table as a layout table.
Select Update.

The use of merged cells is not recommended

Keep your table structure simple by avoiding merged or split cells. This ensures that every data point is clearly associated with its correct header, making your information accessible to everyone.

The use of empty cells is not recommended

Tables are maps of relationships. An empty cell breaks the link between a row header and a column header, leaving the user without the necessary context to understand the surrounding data. Instead of leaving a cell completely blank, use a placeholder that provides clarity. This confirms to the reader that the missing data is intentional.

When creating accessible tables, "white space" is actually your enemy. While a blank cell might look clean visually, it creates a significant barrier for anyone using assistive technology.

Context is King

For a sighted user, an empty cell is just a gap. However, for a user navigating with a screen reader:

The "Lost" Factor: When a screen reader encounters a series of empty cells, the user may wonder if the document is broken, if they’ve reached the end of the table, or if the software has skipped content.
Logical Disconnect: Tables are maps of relationships. An empty cell breaks the link between a row header and a column header, leaving the user without the necessary context to understand the surrounding data.

Better Alternatives

Instead of leaving a cell completely blank, use a placeholder that provides clarity. This confirms to the reader that the missing data is intentional.

Strategy	Example	When to Use it
Explicit Negation	"N/A" or "Not Applicable"	When the category doesn't apply to that specific row.
Zero Values	"0" or "None"	When the cell represents a numerical count.
Descriptive Text	"No data available"	When information is missing or pending.
Placeholder Symbols	"—" (Em-dash)	Use sparingly, and only if the dash is tagged with alt-text.

Landmarks

Headers and footers should be used

You can add your document’s title to the header and additional content (like page numbers or update dates) to the footer of your document. Headers and footers are not required to make a document fully accessible but you may see a “Pass with warning” in the Grackle interface.

Lists should be used where appropriate

Unordered lists (typically seen as bullet-point lists) should have an “unordered list” tag applied.

Order lists (typically seen as numbered lists) should have an “ordered list” tag applied.

Tag lists by:

Select the text you want in your list.
In the toolbar, select Bulleted list or Numbered list

Documents should not contain unsupported contents

"Unsupported contents" are things that Google Docs doesn’t understand or can’t show properly. If you import a document with these elements, they might not appear correctly or could be removed.

Some examples of unsupported content are custom fonts or specialized styling from Microsoft products.

These will need to be removed or edited in your Google Doc.

Fine print should be avoided

Use easy to read sans serif fonts, such as Crimson Pro or Figtree. Make sure your font size is at least 12 points.

All-caps styling should be avoided

For users with visual impairments or dyslexia, all-caps can be a major roadblock:

Screen Readers: Some assistive technologies interpret all-caps as acronyms and may read your text letter-by-letter (e.g., reading "STOP" as "S-T-O-P").
Crowding: For those with dyslexia, the lack of distinct word shapes makes the text appear to "blur" together, increasing the likelihood of skipping lines or losing their place.

Adjusted alignment not suggested for non-heading text

Standard alignment isn't just about "neatness"; it’s a functional requirement for many:

Dyslexia: Constant starting points help readers track their place. When lines start in different spots, it becomes much easier to skip lines or read the same line twice.
Low Vision/Screen Magnification: Users who use screen magnifiers only see a small portion of the screen at once. If text is right-aligned or centered, they may scroll to the left (where they expect the text to be) and find nothing but empty white space, leading them to believe the page is blank.

Links should be informative

Providing informative, descriptive links is one of the most impactful things you can do for accessibility.Screen reader users often use a shortcut to pull up a list of every link on a page to navigate faster.

The Problem: If a user hears a list that says "Click here, Click here, Read more, Read more," they have zero context. They don't know which "Click here" leads to a PDF and which one leads to a contact form.
The Solution: Link text should be descriptive enough to make sense out of context. Instead of "Click here," use "Download the 2024 Financial Report."

URL Fatigue

Raw URLs (e.g., https://www.scu.edu/accessibility/accessible-google-docs/grackle-docs-step-by-step-guide/) are a nightmare for accessibility. For users with learning disabilities, a long string of random characters is overwhelming and hard to process. Additionally, a screen reader will read out every single character, slash, and dash in a URL. Hearing "h-t-t-p-s-colon-slash-slash..." for thirty seconds is an exhausting experience that drives users away.