From Retrofit to Born Accessible: Using Google Gemini, Anthology Ally, and WCAG 2.1 AA in your everyday teaching work
BJ Kitchin, Executive Director of Academic Services, University of Maine at Augusta | UMA Faculty Institute, May 14, 2026
Welcome
How to use this kit
This Starter Kit is for faculty and staff who want practical ways to create more accessible digital content from the beginning. It is built around a simple stance:
AI helped. I am still responsible.
Important: Always access Gemini at gemini.google.com using your Maine.edu login. This ensures your work stays within the University of Maine System's Workspace for Education environment and its data protections — whether you are pasting text, uploading files, or sharing Google Docs, Slides, or PDFs. Do not use a personal Google account for course-related content.
Use the prompts and workflows as first-draft support. Then review, revise, and validate with the right platform tools and human judgment before sharing content with students or the public.
This kit focuses on everyday work in Google Workspace, Brightspace, Kaltura, Zoom, Gemini, and Anthology Ally where available.
How to use it
For a specific task right now: go to The 44-prompt library, find the prompt you need, copy it, paste into Gemini, upload any relevant file using the attachment icon, fill in the brackets, and send.
For a habit you want to build: the Born Accessible Loop is the seven-step pattern that all the workflows share. Internalize it and the rest follows.
It is not a substitute for the campus accessibility office, disability services (at UMA: UMA Disability Services), or feedback from disabled students.
It is not a guarantee. WCAG conformance is judged against the final published content, not against whether you used AI to draft it.
Why this matters: from steep steps to universal design
Jay Dolmage's Academic Ableism (University of Michigan Press, open access) describes three ways institutions handle access. The goal of this kit is the third one.
Steep steps
The content is simply inaccessible. The disabled student is on their own. A PDF with no tags, a video with no captions — these are digital steep steps. We don't do this in physical buildings anymore, but we do it constantly in digital ones.
The ramp
A fix added after the fact, often around the side. The retrofit. A student emails, we find a workaround, we patch. Better than nothing, but still a visible repair on an old design. The labor falls on the people who can least afford it: disability services, a few accessibility-aware staff, and the disabled students who have to advocate for themselves.
Universal design
The same front door for everyone. Alt text written when the image was inserted. Captions ordered before the video was published. Born accessible from the start. This is not just better for disabled students — it is better for everyone, and it is better for the people doing the work.
"Refuse to accept an ongoing series of retrofits and slapped-on accommodations."
— Jay Dolmage, Academic Ableism
One-page summary
For sharing, posting, or printing. Everything important in one page.
People-First Digital Accessibility at UMA
Federal law (ADA Title II, 2024 DOJ rule) requires UMA web content to meet WCAG 2.1 Level AA by April 26, 2027. The University of Maine System provides Google Gemini as the contracted GenAI tool, and Brightspace ships Anthology Ally as the in-LMS accessibility tool.
Use Gemini at gemini.google.com to draft alt text, clean up Zoom and Kaltura transcripts, revise dense text into plain language, and check your content before publishing. If you have an upgraded Gemini for Workspace license, the same prompts work in the Gemini side panel inside Docs, Slides, and Gmail. Use Ally inside Brightspace to remediate files already uploaded to your courses.
Always review what AI produces.
Always run the Brightspace Accessibility Checker before publishing HTML.
Always run accessibility checkers on content — Grackle for Docs, Slides, and Sheets; Microsoft Accessibility Tools; Adobe Acrobat; and others.
Always review gauges in Ally for Brightspace.
Captions and transcripts must be human-verified.
Audio description requires planning, not just AI.
AI helped. I am still responsible.
Help: UMA Faculty Development Center; UMA Academic Services Unit; UMA Disability Services.
The Born Accessible Loop
If you remember nothing else from the session, remember this loop. It works for an alt text on a single image. It works for a 60-minute Zoom recording. It works for a syllabus. The loop scales.
Plan access before creating content. Ask who might use this, what formats they may need, what visual or auditory content is essential, whether there is a video that will need captions and audio description.
Draft with structure. Real headings, real lists, real tables, descriptive link text, image alt at the moment of insertion. Plain language. Color not used alone.
Use Gemini for first-pass support. Gemini at gemini.google.com works for all tasks. If you have an upgraded Workspace license, the side panel in Docs, Slides, and Gmail works too. Prompts that explicitly ask Gemini to flag uncertainty.
Review with human judgment. You are the accessibility expert for your content's meaning. AI is the assistant.
Validate with platform and accessibility tools. Brightspace Accessibility Checker for HTML. Ally for files in Brightspace. Kaltura caption editor for media. Microsoft and Google checkers for documents.
Revise before publishing. Fix what tools flag. Spot-check with keyboard navigation. Spot-check with a screen reader for high-stakes content.
Gather feedback and improve. Ask disabled students what worked. Iterate at the syllabus and template level so the next course starts higher.
Two things to notice. Gemini is step 3, not step 7. AI assistance comes after planning and structure and before validation. Step 7 is not optional. Feedback is how the next course starts higher than this one. Disabled students are the ideal source. Where that is not accessible, the UMA Faculty Development Center — just ask, they'll help — disability services staff, and accessibility-informed colleagues are all good partners.
Born Accessible checklist
Three short lists. Print, tape to a wall, work through one at a time.
Opens a copy in your own Google Drive. Sign in with your Maine.edu account.
Before you create content
Who might use this? What formats might they need?
Will there be a video? Does it need captions and audio description?
Are there images that carry information, not just decoration?
Will there be a quiz or form? Where will it live?
Is there a template I should start from instead of a blank page?
While you create
Real headings (H1, H2, H3), not just bold large text
Real lists (bulleted or numbered), not just dashes or asterisks
Real tables only for tabular data, with header rows
Descriptive link text that says where the link goes
Alt text inserted at the moment each image is added
Plain language with disciplinary terms defined on first use
Color never used alone to convey meaning
Document language set correctly
Slide titles unique and descriptive
Before you publish
Brightspace Accessibility Checker run on any HTML page
Ally instructor feedback reviewed for any uploaded file
Kaltura caption review pass on any video
Transcript posted alongside any video or audio
Contrast check on any custom color choice
Keyboard spot-check (Tab through the page, can you reach everything?)
For high-stakes content: screen reader spot-check (NVDA is free)
"AI helped. I am still responsible." review checklist
The eight questions to ask yourself for every piece of AI-assisted content before it reaches a student.
I read the entire Gemini output before publishing.
I verified every name, value, and disciplinary term.
I confirmed Gemini did not invent details not in the source.
I confirmed Gemini did not omit anything required.
I ran the platform accessibility checker (Brightspace, Ally, Kaltura caption editor, or document checker).
For visual content, a disability-aware reviewer or, where possible, a disabled user has reviewed it.
I disclosed AI involvement where appropriate, especially for AI-generated images of people.
I documented this workflow so the next iteration starts higher.
GenAI accessibility review checklist
Five questions to ask of every Gemini output before you trust it.
Is anything in this output not actually in my source material? If yes, remove it or verify it.
Did Gemini guess any name, term, value, or visual detail? Replace guesses with verified content or mark as uncertain.
Did Gemini soften anything that should stay precise? Restore disciplinary terms, qualifications, deadlines, and policy language.
Did Gemini omit anything required by the assignment, policy, or accessibility standard? Add it back.
Would I be comfortable defending this output if a disabled student told me it was wrong? If not, revise before publishing.
The 44-prompt library Core tool
Copy-and-paste prompts for Google Gemini, organized by content type. Each prompt is opinionated about output format and explicitly asks Gemini to flag uncertainty. Fill in the bracketed placeholders before sending.
How to use a prompt: Click the Copy button on any prompt. Open Gemini at gemini.google.com. Paste the prompt and fill in the brackets. If the prompt calls for a document, image, or file, upload it using the attachment icon before sending. Then review the response against the "Review before using" notes. If you have an upgraded Gemini for Workspace license, the same prompts work in the Gemini side panel inside Docs, Slides, and Gmail.
Not sure where to start? The UMA Faculty Development Center is here to help. Whether you have a question about a specific prompt, want to walk through a workflow together, or just need a place to start — just ask, we'll help.
If you are at another UMS campus, your campus teaching and learning center or instructional design team can help you apply these prompts to your specific courses and tools.
Filter by category
1 Draft alt text for a meaningful image
Alt text
When to use: You are inserting a non-decorative image into a Brightspace page, Doc, or Slide.
Before you send: Open Gemini at gemini.google.com. Click the image/attachment icon (paperclip or image button) and upload your image. Then paste this prompt and fill in the brackets.
Write alt text for the image I have provided. Context: [describe what the image is for and what surrounding text says]. Audience: [course level]. Length: under 125 characters. Describe content and function, not appearance. Do not start with 'image of' or 'picture of'. If the image contains text, include the exact text. If you are uncertain about any visual detail, flag with [UNCERTAIN] rather than guessing.
Review before using: Verify names, terminology, and any on-screen text the AI claims to see.
Common mistakes: AI inserts plausible details not actually in the image. AI starts with "image of."
When to use: You have alt text that exists but is generic, too long, or wrong.
Before you send: Open Gemini at gemini.google.com. Click the image/attachment icon (paperclip or image button) and upload your image. Then paste this prompt and fill in the brackets.
I will give you an image and the existing alt text. Rewrite the alt text to under 125 characters, describing content and function in the context below. Do not invent details. Context: [paste context here]. Existing alt: [paste alt here]. Flag uncertainty with [UNCERTAIN].
Review before using: Compare to image and surrounding text. Make sure the revision is actually shorter and more accurate.
Common mistakes: AI keeps the original problem (e.g. starts with "image of") while changing other words.
When to use: You are not sure if an image needs alt text or should be marked decorative.
Before you send: Open Gemini at gemini.google.com. Click the image/attachment icon (paperclip or image button) and upload your image. Then paste this prompt and fill in the brackets.
I will describe an image and its context. Tell me whether this image is decorative (should have empty alt or be marked decorative) or meaningful (needs alt text). Justify in two sentences. If meaningful, draft alt text under 125 characters. Context: [paste]. Image description: [paste or attach].
Review before using: You make the final call. If the image is purely decorative (background flourish, separator), mark it decorative.
Common mistakes: Treating branding, icons, or separators as meaningful when they are not.
When to use: A chart, infographic, or complex diagram needs more than 125 characters.
Before you send: Open Gemini at gemini.google.com. Click the image/attachment icon and upload your image or screenshot. Then paste this prompt and fill in the brackets.
Write a long description of the attached complex image for a [course level] student who cannot see it. Begin with a one-sentence summary (the takeaway). Then give the structured description in paragraph form. End with a 'Key data' bullet list of any numeric values or labels. Total length 150-300 words. Do not invent values. Flag uncertainty with [UNCERTAIN]. Surrounding context: [paste].
Review before using: Verify data, emphasis, and that the takeaway matches your instructional point.
Common mistakes: Invented values, made-up trends, or descriptions that miss what students are supposed to learn.
When to use: You have a chart with underlying data and need both short alt and a long description.
Before you send: Open Gemini at gemini.google.com. If you have the chart as an image, upload it using the image/attachment icon. If you have the underlying data as a spreadsheet, paste it into the prompt where it says [paste or attach]. Both together give Gemini the most to work with.
I will provide a chart and its underlying data. Write: (a) short alt under 125 characters naming the chart type and topic; (b) long description with the trend, two or three key values, and the conclusion. Do not infer beyond the data. Data: [paste or attach]. Context: [paste].
Review before using: Confirm the numbers and the conclusion. AI sometimes describes a trend in the wrong direction.
Common mistakes: Saying only "chart showing data" with no specifics, or inferring causation beyond what the chart shows.
When to use: A labeled diagram or process image needs accessible text.
Before you send: Open Gemini at gemini.google.com. Click the image/attachment icon and upload your image or screenshot. Then paste this prompt and fill in the brackets.
Describe this diagram step by step for a student who cannot see it. Start with the diagram's purpose. Then list the steps or parts in the order a sighted reader would follow. Use plain language. If labels are present, quote them. Diagram context: [paste]. Length: 100-250 words. Flag uncertainty.
Review before using: Make sure the sequence is correct and the labels are quoted accurately.
Common mistakes: Describing layout (top-left, bottom-right) instead of meaning. Getting the sequence backwards.
When to use: You have raw ASR output from Zoom, Kaltura, Otter, or similar.
Clean up this auto-generated transcript for publication as an accessibility transcript. Fix punctuation. Restore paragraph breaks at natural turn changes. Fix obvious mishears of common vocabulary. Do not change content. Do not summarize. Do not invent. If a word is unclear, write [INAUDIBLE]. Preserve timestamps exactly as given. Transcript: [paste transcript here].
Review before using: Listen through the audio while comparing. Catch every mishear of names, jargon, and assessment-relevant content.
Common mistakes: Silent corrections to uncertain words. AI guessing at unclear audio instead of marking [INAUDIBLE].
8 Create a speaker-labeled transcript
Transcripts
When to use: You have a transcript with multiple voices and a roster.
Reformat this transcript with speaker labels. Roster: [paste roster of names]. Use the format '**Name (HH:MM):** text'. Preserve every word. If you cannot identify a speaker confidently, label as 'Speaker 1', 'Speaker 2', etc. Do not invent attributions. Transcript: [paste transcript here].
Review before using: Verify each named attribution. AI cannot reliably identify voices.
Common mistakes: AI guessing names from context. Using participant lists as proof of who spoke when.
When to use: You have a clean transcript that needs navigation markers.
Add a timestamp at the start of every paragraph and at every speaker change in this transcript. Use the format (HH:MM:SS). Preserve every word. Do not change punctuation more than necessary. Transcript with original timing markers: [paste].
Review before using: Spot-check timestamps against the actual recording at random points.
Common mistakes: False precision. AI inventing timestamps that look right but do not match the recording.
10 Identify unclear transcript sections
Transcripts
When to use: You want a list of likely problem spots before you do a listen-through.
Read this transcript and list every span you think contains a likely transcription error (mishear, missing word, garbled phrase). For each, give the timestamp, the suspect text, and a brief reason. Do not rewrite the transcript. Transcript: [paste].
Review before using: Resolve every flagged span against the source audio.
Common mistakes: Treating the AI list as exhaustive. There will be errors AI did not flag.
11 Create a descriptive transcript for a video
Transcripts
When to use: Your video has visual information that the audio alone does not convey.
Before you send: Open Gemini at gemini.google.com. If attaching screenshots, upload them using the image/attachment icon. Then paste this prompt with the transcript text in the brackets. You can upload multiple images in one message.
Using the transcript and screenshots below, write a descriptive transcript suitable for a blind student. Interleave bracketed visual descriptions with the dialogue. Describe only instructionally relevant visuals: actions, slide changes, on-screen text, demonstrations, gestures that carry meaning. Keep descriptions concise. Do not invent visuals. Flag uncertainty with [UNCERTAIN]. Transcript: [paste]. Screenshots and slide notes: [paste/attach].
Common mistakes: Over-describing decorative visuals. Inventing visual details not in the screenshots.
12 Draft an audio description script
Audio description
When to use: You plan to record or generate AD audio for a video.
Before you send: Open Gemini at gemini.google.com. Upload screenshots using the image/attachment icon — one per key visual moment is enough. Then paste this prompt with the transcript in the brackets.
Draft an audio description script for this video. Use the transcript and screenshots provided. Insert AD lines at natural pauses in dialogue (longer than 2 seconds). Each AD line should be under 12 seconds when read aloud. Describe actions, scene changes, on-screen text, and key visuals. Do not describe anything not visible. Do not duplicate information already in dialogue. Output as a table with columns Timestamp, Pause length (sec), AD line. Flag uncertainty. Transcript: [paste]. Screenshots: [attach].
Review before using: Test pacing against the actual recording. AD lines must fit pauses without interrupting key speech.
Common mistakes: AD lines that talk over essential dialogue. Long descriptions in short pauses.
When to use: You are not sure whether your video needs audio description.
Review this transcript and the list of visuals from the video. List moments where a blind student would miss instructionally important information from the visuals. For each, give the approximate timestamp and a one-sentence description of what the visual is. Transcript: [paste]. Visuals list: [paste].
Review before using: Confirm against the recording. Decide which flagged moments are truly essential.
Common mistakes: Treating every gesture or scene change as essential.
14 Review captions for accuracy and readability
Captions
When to use: You have a caption file (SRT or VTT) and want to find likely problems.
Review this caption file for likely errors and readability issues. List: (a) likely mishears with timestamp; (b) places where punctuation makes captions hard to read; (c) places where speaker identification would help; (d) lines that exceed 32 characters and might be hard to read on screen. Do not rewrite the file. Captions: [paste SRT/VTT].
Review before using: Compare flagged moments against the recording. Fix in caption editor.
Common mistakes: Trusting the AI review as complete. Replacing human listen-through with AI scan.
15 Rewrite assignment instructions for cognitive access
Plain language
When to use: Students keep misreading or asking clarifying questions about an assignment.
Rewrite these assignment instructions for cognitive access. Use 9th-grade plain language. Preserve all academic content, requirements, and disciplinary terminology. Convert long sentences to shorter ones. Use headings for: Purpose, What to do, How to submit, Grading. End with a Quick checklist. Flag any place where the original instructions are ambiguous. Original: [paste assignment instructions here].
Review before using: Confirm academic rigor stays intact. Restore any disciplinary term Gemini softened.
Common mistakes: Removing required complexity. Deleting grading criteria. Replacing precise terms with vague ones.
16 Rewrite dense course language in plain language
Plain language
When to use: A passage of course prose is hard to scan or parse.
Rewrite this passage in plain language at a 9th-grade reading level. Preserve all key disciplinary terms; define each term in parentheses on first use. Keep all qualifiers and conditions intact. Do not change meaning. Original: [paste].
Review before using: Check disciplinary accuracy. Make sure no qualifications were dropped.
Common mistakes: Oversimplifying core concepts. Losing nuance that the original carried.
17 Preserve academic rigor while improving clarity
Plain language
When to use: You want clearer language without softening the academic content.
Rewrite this passage for clarity while preserving full academic rigor. Do not remove technical vocabulary; instead, briefly define each technical term on first use. Do not delete qualifications. Do not change conclusions. Mark any sentence where you had to interpret the author's meaning with [INTERPRETATION]. Original: [paste].
Review before using: Confirm unchanged essentials. Resolve every [INTERPRETATION] tag.
Common mistakes: AI replacing precise terms with vague ones while claiming to preserve rigor.
18 Create descriptive link text
Links
When to use: Your content has "click here" links or bare URLs.
Review this page and rewrite every link's anchor text so it is descriptive out of context. Replace 'click here', 'here', 'read more', and bare URLs. Each new anchor should say what the link goes to in 3-8 words. Page content with links: [paste].
Review before using: Verify each destination. Make sure two different links do not have identical labels.
Common mistakes: Duplicate link labels for different destinations.
19 Review a course announcement for accessibility
Document review
When to use: You are about to post a Brightspace announcement and want a numbered list of specific edits to make, not a full rewrite.
Review this Brightspace announcement for accessibility. Check: heading structure, link text, plain language, length, presence of a top-line summary, descriptive subject line, any images that would need alt text, and any reliance on color alone. Suggest specific edits with reasoning. Do not rewrite the whole announcement; produce a numbered list of edits. Announcement: [paste Brightspace announcement here].
Review before using: Apply edits in the Brightspace HTML editor. Then run the Brightspace Accessibility Checker.
Common mistakes: Letting AI change dates, policies, or required institutional language.
20 Review a syllabus for accessibility and cognitive load
Document review
When to use: You are revising a syllabus and want a structured review.
Review this syllabus. Identify: (a) heading structure issues; (b) sections that are too dense for first-week cognitive load; (c) places where requirements are buried; (d) places where accommodation, mental-health, or basic-needs statements should be added or improved; (e) any image without alt text. Output as a numbered list of recommendations. Syllabus: [paste].
Review before using: Confirm policy language is preserved exactly where required.
Common mistakes: Changing required institutional wording without approval.
21 Convert long instructions into steps
Structure
When to use: A process is buried in prose paragraphs.
Convert these instructions into a numbered step list. One action per step. Use the imperative voice. Preserve all required content. If a step depends on a prior step, state the dependency. Original: [paste].
Review before using: Check sequence and completeness. Make sure no required step was merged or dropped.
Common mistakes: Breaking one task into misleading mini-tasks.
22 Create a student-friendly checklist
Structure
When to use: You want a companion checklist for a complex set of instructions.
From these instructions, create a student-friendly checklist titled 'Before you submit'. Use plain language. 5-10 items. Each item starts with a verb. End with one sentence about where to get help. Original instructions: [paste].
Review before using: Compare against original to ensure nothing important is missing.
Common mistakes: Treating the checklist as the only version. Always pair with full instructions.
23 Create multiple formats of the same content
UDL
When to use: You want a summary, an outline, and a checklist version for different learners.
From this content, produce three equivalent formats: (a) a 2-3 sentence summary; (b) a structured outline with H2/H3 headings; (c) a 5-8 item checklist. All three must contain the same essential information. Content: [paste].
Review before using: Cross-check consistency between the three formats.
Common mistakes: Conflicting versions where one says something different from another.
24 Summarize a complex reading or policy
Summarize
When to use: Students need a student-friendly overview of a dense reading.
Summarize this reading for [course level] students. Preserve the author's argument, key terms, and any qualifications. Length: 200 words. Add a 3-bullet 'What you should remember' list. Do not add interpretations not in the text. Flag with [UNCERTAIN] anywhere you had to interpret. Reading: [paste reading here].
Review before using: Compare to the source. The summary supplements, never replaces, the original.
Common mistakes: Replacing the source with the summary. AI adding interpretations not in the text.
25 Prepare a document before an accessibility checker
Document review
When to use: You want to fix obvious problems before running a formal checker.
Review this document for likely accessibility issues before I run the official checker. Check: heading structure, list usage, descriptive link text, image alt presence, table header rows, color reliance, and any place a screen reader user would lose context. Output a numbered list of specific issues with locations. Document: [paste].
Review before using: Apply fixes, then run the actual checker (Microsoft, Adobe, Brightspace, or Ally).
Common mistakes: Thinking the AI list replaces the formal checker. It does not.
26 Review slides for accessibility barriers
Slides
When to use: You want a pre-check before running a slide accessibility check.
Review these slide contents (text plus image descriptions if available) for accessibility barriers. For each slide, list: missing alt text, duplicate or missing slide titles, dense text blocks, color-only meaning, low-contrast risk indicators. Output as a table with columns Slide, Issue, Suggested fix. Slides: [paste deck content here].
Review before using: Open the deck, fix slide titles and reading order. Then run the slides accessibility checker.
Common mistakes: AI cannot evaluate actual reading order, focus order, or true contrast from text alone.
27 Suggest accessible slide speaker notes
Slides
When to use: You will record narration over slides and need notes that describe visual content.
For each slide below, write speaker notes that describe any image or chart on the slide and read out any on-screen text. These notes will be read aloud during recording, so a blind viewer needs to understand the slide from listening. Keep each slide's notes under 60 seconds spoken. Slides: [paste].
Review before using: Confirm visual importance. Speaker notes should add information, not just repeat slide text.
Common mistakes: Just repeating the slide text without describing the image or chart.
28 Create an accessibility checklist for a specific document
Checklists
When to use: You want a tailored quick-check list before publishing.
Build a one-page accessibility checklist tailored to this specific document. Include only items relevant to what is actually in it. Group by Headings, Images, Links, Tables, Color, Language. Document: [paste].
Review before using: Use the checklist during final review, then run platform tools.
Common mistakes: Overly generic advice that does not match what is in the document.
29 Review tables for accessibility issues
Tables
When to use: You have a table that might be hard to read or improperly structured.
Review these tables for accessibility. For each table, identify: missing header row or column, merged cells, layout-only tables that should be lists, missing caption or summary, and any cell that mixes data types. Output as a numbered list. Tables: [paste].
Review before using: Fix actual header markup in the source. Split complex tables if needed.
Common mistakes: Keeping complex tables that should be split into simpler ones.
30 Identify accessibility barriers in LMS content
LMS
When to use: A Brightspace HTML page feels cluttered or hard to use.
Review this Brightspace HTML content. List every likely accessibility issue with location and a one-line suggested fix. Cover headings, alt text, link text, color, tables, language, and any embedded media. Content: [paste HTML content here].
Review before using: Apply fixes. Run the Brightspace Accessibility Checker.
Common mistakes: Assuming LMS HTML is accessible by default. It usually is not.
31 Review a Brightspace announcement for accessibility
Brightspace
When to use: You want Gemini to suggest a fully revised version of your announcement, not just flag issues.
Treat this as a Brightspace announcement going to a class of mixed prior knowledge. Review for: subject line clarity, top-line summary, heading structure, plain language, descriptive link text, alt text needs, and length. Suggest a revised version. Announcement: [paste Brightspace announcement here].
Review before using: Check final HTML and links in Brightspace. Run the Accessibility Checker.
Common mistakes: Relative dates without clarity ("next week" instead of a specific date).
32 Rewrite Brightspace module overview for clarity
Brightspace
When to use: You are drafting or revising a module overview page.
Rewrite this module overview for students who are new to the topic. Use this structure: 'In this module you will...', 'What to read or watch', 'What to do', 'How you'll be assessed', 'Where to get help'. Plain language. Preserve all disciplinary terms with brief definitions. Module overview: [paste].
Review before using: Confirm local course details (instructor name, office hours, support links).
Common mistakes: Vague overviews with no action cues. AI filling in placeholder course details.
33 Review Brightspace assignment instructions for hidden assumptions
Brightspace
When to use: Students keep asking clarifying questions about an assignment.
Review these assignment instructions for hidden assumptions: unstated prior knowledge, unexplained jargon, unclear submission steps, implicit cultural references, ambiguous grading criteria. Output a numbered list of specific places where a student new to the field, or new to U.S. higher education, would struggle. Instructions: [paste assignment instructions here].
Review before using: Confirm what to keep as required disciplinary content versus what to scaffold.
Common mistakes: Removing discipline-specific expectations that are pedagogically necessary.
34 Create a checklist from Brightspace assignment instructions
Brightspace
When to use: You want a "Before you submit" checklist as a companion to your assignment.
From these Brightspace assignment instructions, produce a 'Before you submit' checklist for students. 6-10 items, each starting with a verb. Plain language. Include a final item: 'I asked for help if I needed it (contact info)'. Instructions: [paste assignment instructions here].
Review before using: Compare against the original. Make sure all submission requirements are captured.
Common mistakes: Using the checklist without keeping the full instructions visible.
35 Review a Brightspace discussion prompt
Brightspace
When to use: Your discussion prompt may be too abstract or have hidden assumptions.
Review this discussion prompt. Check: clarity of expectations, open-endedness, presence of multiple valid entry points, plain language, length, descriptive link text, and any image alt text needs. Suggest a revised prompt with explicit expectations. Discussion prompt: [paste].
Review before using: Ensure the prompt still matches your learning goals after revision.
Common mistakes: Letting AI narrow open inquiry too much.
36 Clean up a Kaltura transcript
Kaltura
When to use: You have an exported Kaltura auto-generated transcript.
How to get your transcript: In Kaltura MediaSpace or your Brightspace course, open the video. Go to Actions → Caption & Enrich (or the Captions tab). Download the machine-generated caption file as a .txt or .srt. Open it and copy the text.
Clean up this Kaltura auto-generated transcript for student-facing publication. Fix punctuation. Add paragraph breaks at natural turn changes. Fix obvious mishears of common vocabulary. Preserve timestamps. Do not summarize. Do not invent content. Mark unclear spans [INAUDIBLE]. Transcript: [paste Kaltura transcript here].
Review before using: Re-import to Kaltura caption editor. Do a human pass listening to the video.
Common mistakes: Assuming the ASR knew course-specific vocabulary (it usually does not).
37 Speaker-labeled transcript from Kaltura captions
Kaltura
When to use: You have Kaltura captions and want to convert to a readable speaker-labeled transcript.
How to get your transcript: Same as above — download the caption file from the Captions tab in Kaltura. Also prepare a simple roster: first and last names of all speakers, one per line.
Reformat this Kaltura caption export as a speaker-labeled transcript. Use the roster provided. Format: '**Name (MM:SS):** text'. Preserve every word. Mark unknown speakers 'Speaker 1', etc. Captions: [paste]. Roster: [paste].
Review before using: Verify each named attribution against the recording.
Common mistakes: Inferred names without evidence.
38 Descriptive transcript for a Kaltura video
Kaltura
When to use: A Kaltura video has visual content that the audio does not convey.
Before you send: Open Gemini at gemini.google.com. If attaching screenshots, upload them using the image/attachment icon. Then paste this prompt with the transcript text in the brackets. You can upload multiple images in one message.
Using this Kaltura transcript and the screenshots from the video, write a descriptive transcript. Interleave bracketed visual descriptions where they carry instructional meaning. Do not describe purely decorative visuals. Flag uncertainty. Transcript: [paste]. Screenshots/slide notes: [attach or paste].
Review before using: Compare against the recording. Cut over-description of background or clothing.
Common mistakes: Describing irrelevant scenery instead of instructionally important visuals.
39 Audio description script for a Kaltura video
Kaltura
When to use: You will record AD or generate TTS audio for a Kaltura video.
Before you send: Open Gemini at gemini.google.com. Upload screenshots using the image/attachment icon — one per key visual moment is enough. Then paste this prompt with the transcript in the brackets.
Draft an audio description script for this Kaltura video. Insert AD lines only in pauses longer than 2 seconds. Each AD line under 12 seconds spoken. Describe actions, scene changes, on-screen text, and key visuals. Do not duplicate what dialogue already says. Output as a three-column table: Start time, Pause length, AD line. Transcript: [paste]. Screenshots: [attach].
Review before using: Test pacing against actual video. Order through Kaltura REACH if available.
Common mistakes: AD lines that do not fit the available pause. Long descriptions where dialogue resumes quickly.
40 Clean up a Zoom transcript
Zoom
When to use: You have a Zoom cloud recording transcript (VTT or text).
How to get your transcript: In the Zoom web portal (zoom.us), go to Recordings, open the session, and download the Audio Transcript (.vtt file). Open the file in a text editor or Google Docs and copy the contents.
Clean up this Zoom audio transcript for student-facing publication. Fix punctuation. Restore paragraph breaks at natural turn changes. Keep all speaker names Zoom assigned. Fix obvious mishears of common vocabulary. Preserve timestamps. Mark unclear spans [INAUDIBLE]. Transcript: [paste Zoom transcript here].
Review before using: Listen through. Catch jargon mishears and any content that affects assessment.
Common mistakes: Silent corrections without evidence. Deleting false starts that actually mattered.
41 Speaker-labeled transcript from a Zoom recording
Zoom
When to use: A Zoom session had multiple speakers and you have a participant roster.
How to get your transcript: Same as above — download the .vtt from zoom.us. Also prepare your participant roster. Note that Zoom uses display names, not always real names, so the roster helps Gemini normalize them.
Reformat this Zoom transcript as a speaker-labeled transcript using the roster. If Zoom's display name differs from the roster name, normalize to the roster name. Format: '**Name (MM:SS):** text'. Preserve every word. Mark unknown speakers as 'Speaker 1' etc. Transcript: [paste Zoom transcript here]. Roster: [paste].
Review before using: Verify names carefully, especially for guest speakers and student participants.
Common mistakes: Exposing student names without consent. Using the participant list as proof of who spoke when.
42 Student-facing Zoom session summary (does not replace transcript)
Zoom
When to use: You want a study-friendly summary for students alongside the full transcript.
Write a 250-word student-facing summary of this Zoom class session. Cover: main topics discussed, key terms introduced, decisions or announcements, action items for students. State at the top: 'This is a summary. The full transcript is the official record.' Do not paraphrase quoted student remarks. Transcript: [paste].
Review before using: Publish the summary alongside, not instead of, the full transcript.
Common mistakes: Calling the summary an accessibility transcript. They are different things.
43 Identify places needing visual description
Visual content
When to use: You suspect a recording has visual-only explanations that need description.
Review this transcript and the timestamped list of visuals (slides shared, screen shares, demonstrations). Identify moments where a blind student would miss instructionally important information. For each, give the timestamp and a one-sentence note. Transcript: [paste]. Visuals timeline: [paste].
Review before using: Confirm against the video. Decide which moments warrant description.
Common mistakes: Assuming every visual reference needs description.
44 Convert transcript into study guide (preserve transcript separately)
Study aids
When to use: You want accessibility and study support both, without conflating them.
Treat this transcript as the official accessibility record. Do not modify it. In addition, produce a separate student study guide containing: key terms with definitions, three to five main ideas, two to three review questions, suggested further reading from sources actually mentioned in the transcript. Mark the study guide as 'Study guide (derivative). The full transcript is the accessibility record.' Transcript: [paste].
Review before using: Keep the transcript and the study guide as two separate resources.
Common mistakes: Using the study guide as the official record instead of the transcript.
Brightspace, Kaltura, Zoom, and Gemini workflow guide
Five common workflow chains that connect your draft to a published, accessible artifact. Each follows the Born Accessible Loop.
1. Brightspace announcement workflow
For an announcement, module overview, assignment, or any HTML content page.
Draft in Google Doc→Gemini review→Paste into Brightspace HTML editor→Brightspace Accessibility Checker→Publish
Alternative for files already in Brightspace: use Anthology Ally's AI Alt Text Assistant directly in the Instructor Feedback panel. See Two tools, two moments for when to use which.
Speaker-labeled transcript workflow
A transcript in which each utterance is attributed to a named speaker. Essential for seminars, panels, interviews, group discussions, and any class where who is speaking is part of the content.
When you need one
Seminars, panels, and interviews where speaker identity matters to meaning
Group projects, oral histories, recorded discussions
Any session where a Deaf or hard-of-hearing participant needs to follow the conversation, not just the lecture
How it differs from related artifacts
Captions are synchronized text overlaid on video.
Plain transcripts are running text without speaker labels.
Speaker-labeled transcripts add structure showing who said what.
AI meeting notes or summaries are a paraphrase, not a verbatim record. They never replace a transcript for accessibility purposes.
Three quality levels
Poor
"yeah um so what i was thinking is that the thing right the protein right is the thing"
Better (after Gemini cleanup)
"Yeah, so what I was thinking is the protein is the key thing."
Strong (after human review)
"Student A (12:34): Yeah, so what I was thinking is the protein is the key thing. [referring to the diagram on slide 7]"
Handling edge cases
Unknown speakers: label as "Speaker 1," "Speaker 2," etc., until identified.
Student speakers: follow FERPA and institutional policy. Default to first-name only or "Student" unless you have explicit consent for named publication.
Meaningful non-speech audio: [laughter], [applause], [door opens], [video clip plays]. Remove any that Gemini invented.
Timestamps: useful every 1-2 minutes or at major topic changes.
Privacy: redact off-topic personal disclosures even if they were said publicly.
Prompts that apply
Prompt 8: Create a speaker-labeled transcript (any source)
Prompt 37: Speaker-labeled transcript from Kaltura captions
Prompt 41: Speaker-labeled transcript from Zoom recording
Audio description workflow
A narrated audio track that, during natural pauses in dialogue, describes visual information a blind or low-vision viewer would miss. Required at WCAG 2.1 AA (SC 1.2.5) for prerecorded video with information-bearing visuals.
Definitions
Audio description (AD): spoken narration of essential visuals, fit into natural pauses.
Extended audio description (EAD): the video pauses while a longer description is read. Supported in Kaltura.
Descriptive transcript: a text alternative that interleaves visual descriptions with dialogue (separate section below).
WCAG choice point
SC 1.2.3 (Level A) allows audio description OR a full media alternative (descriptive transcript).
SC 1.2.5 (Level AA) requires audio description specifically. A descriptive transcript no longer satisfies AA by itself, except where all visual information is already conveyed in the audio (a "talking head" with no information-bearing visuals).
Practical sequence: draft a descriptive transcript first (easier, cheaper), then order AD through Kaltura REACH or generate it with voice talent or high-quality TTS using the script.
What to describe (and what to leave out)
Describe: actions, scene changes, on-screen text, gestures that carry meaning, chart data, software demonstration steps.
Skip: clothing, background scenery, decorative details that do not carry instructional information.
Avoid duplication: if the narrator already says what is on the screen, do not describe it again.
Three quality levels
Poor
"The professor is wearing a blue shirt and is in front of a whiteboard."
Better
"The professor writes pH = -log[H+] on the whiteboard."
Strong
"She writes pH = -log[H+] and circles the negative sign."
Pacing constraints
AD lines fit into pauses of 2 seconds or longer.
Each AD line should be under 12 seconds when read aloud.
If the script does not fit the available pauses, switch to a descriptive transcript or use Kaltura's Extended Audio Description.
A text transcript that interleaves visual descriptions with dialogue. Often the realistic first step before producing audio description, and a valuable companion resource even when AD exists.
When a descriptive transcript is the right choice
The video has dense visual information with limited dialogue pauses (AD would not fit)
You need a text-based alternative for students who prefer reading
You want a step on the way to producing AD audio
Your video is short and a transcript is the proportional response
How to decide what to include
Describe only what carries instructional meaning. A useful test: if a sighted student took notes from this video, what visuals would appear in their notes? Those are the visuals that belong in the descriptive transcript.
Three quality levels of descriptive transcript entries
Poor
[The slide changes.]
Better
[Slide 7: bar chart titled "Maine workforce by sector, 2020-2025."]
Strong
[Slide 7: bar chart titled "Maine workforce by sector, 2020-2025." Healthcare leads at 22%, retail at 15%, manufacturing at 11%.]
Prompts that apply
Prompt 11: Create a descriptive transcript for a video
Prompt 38: Descriptive transcript for a Kaltura video
Before-and-after examples
Quick reference set of common improvements. Use these as targets for your own revision.
"Students will produce a sustained analytical engagement with the assigned primary texts, employing the theoretical framework foregrounded in Week 3, and arriving at a synthesis that adjudicates between the competing interpretive positions surveyed in the secondary literature. Length: 10-12 pages. Due end of Week 8."
After (human-reviewed)
Purpose: Use the Week 3 framework to analyze the primary texts.
What to do: Take a position. Use evidence from primary texts. Engage at least two of the secondary readings.
"The professor is wearing a blue shirt and is in front of a whiteboard."
After
"She writes pH = -log[H+] and circles the negative sign."
Two tools, two moments: Gemini and Ally
UMA has two AI-assisted accessibility tools available. They handle the same task (drafting alt text and other accessibility content) at different moments in your workflow. Same review rule applies to both.
Gemini in Docs and Slides
While you are authoring, before upload.
Use Gemini at gemini.google.com for all prompting work. Content you paste, upload, or share — including Google Docs, Slides, PDFs, and images — stays within the Maine.edu tenant under Workspace for Education terms. If you have an upgraded Gemini for Workspace license, you can also use the Gemini side panel inside Docs, Slides, and Gmail — the prompts work the same way. Gemini is more flexible than Ally because you control the prompt, can give discipline-specific context, and can ask it to flag uncertainty.
Best for: drafting from scratch, alt text, transcript cleanup, plain-language revision, accessibility review of HTML before pasting into Brightspace.
Ally inside Brightspace
After upload, for files already in your course.
Anthology Ally is the accessibility tool that sits inside Brightspace. Ally's AI Alt Text Assistant is enabled across the University of Maine System — click the colored gauge icon next to a file or image and the Instructor Feedback panel opens with an Auto-Generate Description button. Ally also gives students alternative formats (audio MP3, ePub, electronic Braille, translated versions) automatically.
Best for: remediating files already uploaded, fixing images inside HTML content in Brightspace, getting alternative formats to students with zero additional work.
Same review rule. The AI drafts. You verify content, context, and accuracy. Nothing publishes to students until you save it.
When to reach for each
If the content is still being authored: use Gemini. You have more control over the prompt and the output.
If the file is already in Brightspace: use Ally. It is right there in the Instructor Feedback panel and updates the file in place.
If a file in Brightspace was authored elsewhere: either works. Ally is faster (one click). Gemini gives you more nuanced control.
If you need alternative formats for students (audio, Braille, ePub, translated): Ally provides these automatically, regardless of whether AI Alt Text is enabled.
Ally AI Alt Text Assistant is enabled across the University of Maine System. You do not need to request it or confirm with IT. Open any file in your Brightspace course, click the colored gauge icon, and the Instructor Feedback panel will include the Auto-Generate Description button.
Resources for continued learning
A short list of the most useful primary sources, organized by what you might want to do.
For ongoing campus conversation about AI use in teaching, including responsible-use guidance.
Office hours
Available by appointment for one-on-one consultation on a specific accessibility problem in your course.
About this kit
A few honest caveats so you know what this is and what it is not.
Generative AI capabilities change quickly. Specific Gemini features cited here reflect Google documentation as of mid-2026. Verify current behavior before relying on a specific capability.
Auto-caption accuracy figures (around 85% for both Zoom AI Companion and Kaltura machine ASR) come from vendor documentation and one University of Colorado OIT internal study. Local accuracy varies with audio quality, accents, vocabulary, and overlapping speech.
The DOJ Interim Final Rule of April 2026 extended compliance dates but is open for public comment through June 22, 2026. Further rulemaking is possible. The substantive WCAG 2.1 AA requirement is unchanged.
WCAG 2.2 (2023) is not yet the DOJ-incorporated standard, but the 2024 rule allows entities to use a later WCAG version if they prefer.
UDL is a values-aligned framework with a growing but contested empirical base. Use UDL as design orientation, paired with WCAG (testable) and disability-studies values, not as a settled empirical program.
Gemini for Workspace data protections cited here come from Google's published Workspace for Education terms. Faculty or staff with questions about specific data terms should check with UMS IT or their campus IT office.
Disabled users are not a monolith. A workflow that helps a blind screen-reader user may not serve a Deaf student well, and neither may serve a student with a cognitive disability. Wherever possible, design with multiple disabled perspectives in the room, and prefer formats that offer choices rather than single solutions.
AI is not the goal. Access for students is the goal. If Gemini stopped working tomorrow, the seven-step loop and the WCAG 2.1 AA standard would still hold, and that is the right way to plan the work.
People first. AI in service. Access by design.
Share your feedback
Did this kit help? Was something unclear or missing? Your response goes directly to the UMA Academic Services Unit and helps improve this resource.
Found this kit useful? Was something unclear or missing?
