I needed to post an announcement in Brightspace. Nothing particularly exciting. College of the Mainland was kicking off Spring 2027 registration, and the first 200 students who could show proof of registration would receive a free T-shirt. There would be refreshments, giveaways, and a duck mascot waving pom-poms.
My job was to get the flyer in front of students. Five minutes, right?
Of course, the flyer was an image, and like many promotional graphics, it contained all the important information. The date, location, registration website, and free T-shirt offer were baked into the design. That works well enough for students who can see and read the flyer, but someone using a screen reader needs that information presented another way.
So I opened ChatGPT, uploaded the flyer, and asked a simple question: “Can you read all that?”
It could. ChatGPT pulled out the relevant information, including the smaller print and registration URL, and even pointed out that the flyer didn’t include an event time. That was useful, but not particularly remarkable. The interesting part came when I asked it to help me turn the flyer into an accessible Brightspace announcement.
When the first answer isn’t the right answer
I asked ChatGPT to write the announcement text, provide a registration link, and develop alt text and a longer image description that would support accessibility.
The announcement itself was fine, but the image description sounded like someone cataloging evidence. It included the mascot, the jersey, the number on the jersey, the pom-poms, the gymnasium, and the anniversary branding. I looked at that and wondered whether we really needed all those details. I’m trying to make a registration announcement accessible, not file a missing-person report for a duck.
I pushed back and asked for something more narrative, something that communicated the visual personality of the flyer without turning every design choice into a required reading assignment. ChatGPT revised the description, and we arrived at something that sounded more natural.
Then I ran into a problem that wasn’t really about the description itself. Brightspace has a relatively limited alt text field, and even our improved description was longer than I wanted to squeeze into it. I could put the description underneath the image, but that meant students would see a paragraph explaining the same flyer sitting directly above it. It felt redundant and cluttered, especially for what was supposed to be a simple announcement.
My first thought was to make the description white so it wouldn’t be visible against the background.
I know. Not exactly my finest accessibility idea.
ChatGPT explained why that wasn’t a good approach. White text could create contrast problems, and hiding information by matching the background color isn’t the same as making it appropriately accessible. More importantly, I realized I was asking about a specific solution when what I really needed was help solving a presentation problem. I wanted screen reader users to have access to the description without making everyone else read a second version of the announcement.
That led us to visually hidden text.
Wait. Explain that like I’m 13.
Apparently, CSS can be used to keep text in a webpage while hiding it from the normal visual presentation. The text still exists in the HTML, but the browser doesn’t display it in the usual way. When implemented correctly, screen readers can still access that information.
I’ve worked with HTML for years. I can read it, modify it, and generally make it do what I need. CSS, on the other hand, is where my confidence occasionally exceeds my competence.
ChatGPT provided a block of code using properties like position:absolute, overflow:hidden, and clip:rect(0,0,0,0). I understood what the code was supposed to accomplish, but I didn’t understand exactly how it worked. Rather than copying and pasting something I couldn’t explain, I asked ChatGPT to break it down like I was 13.
We worked through the individual properties, including how CSS could shrink the visible area of a paragraph, clip its contents, and keep it from affecting the normal page layout. We also discussed the difference between hiding something visually and using display:none, which generally removes an element from the accessibility information exposed to screen readers.
I wasn’t planning to spend my afternoon learning about the browser’s accessibility tree, but here we were.
That conversation was probably more valuable than the code itself. I could ask questions about unfamiliar concepts, request simpler explanations, and connect what I was learning to the actual problem I was trying to solve. I wasn’t following a tutorial or copying something from a forum and hoping it worked. I was working through the reasoning behind the solution.
Of course, understanding what the code was supposed to do didn’t mean it would actually work in Brightspace. Learning management systems have a habit of modifying HTML, and there was no guarantee that the editor would preserve the CSS after I saved the announcement.
We’d have to test it.
Fixing one problem, creating another
Before getting to that, I shared the HTML I’d assembled with ChatGPT for another review. It contained the flyer, the registration link, regular announcement text, and the visually hidden description.
ChatGPT pointed out something we’d overlooked. Most of the hidden description repeated information that was already available in the announcement itself. Someone using a screen reader could end up hearing the registration details twice.
We’d spent so much time figuring out how to make the image accessible that we’d lost sight of how someone would experience the entire announcement. The individual parts made sense, but together they were unnecessarily repetitive.
So we revised it again.
The regular announcement would contain the important information: the date, location, giveaways, and registration link. The image would have functional alt text because it was also a clickable link. The hidden paragraph would focus on describing the visual elements of the flyer, particularly the mascot and the atmosphere of the graphic, rather than repeating information already available elsewhere.
This was also a reminder that accessibility involves more than screen readers. Visually hidden text isn’t necessarily useful to someone with low vision who relies on enlarged text rather than a screen reader. Keeping the essential information in regular HTML and providing a direct link to the registration website helped address that concern.
What we ended up with was actually simpler than where we’d started. Not because ChatGPT had produced a perfect solution on the first attempt, but because we’d worked through several imperfect ones.
Trust, but verify
With the revised HTML in place, I published the announcement and opened it in Brightspace. The flyer displayed correctly, the registration information was there, and the hidden description wasn’t cluttering the page.
That was encouraging, but it didn’t prove much. The text could have disappeared because Brightspace removed it entirely, which would have defeated the purpose.
So I opened Chrome’s Developer Tools and inspected the published announcement. I searched the page’s HTML for the CSS properties we’d used, and there they were. Brightspace had preserved the visually hidden paragraph, including the positioning, clipping, and overflow settings.
Next, I opened Chrome’s accessibility tree, which shows how the browser represents webpage content to assistive technologies.
And there was our description.
The accessibility tree included the paragraph describing the duck mascot waving pom-poms in the gymnasium, even though the paragraph wasn’t visible on the page. The clickable image also had its accessible link name, and the regular announcement text appeared in the same structure.
We now had evidence that Brightspace preserved the code and that Chrome exposed the hidden description through its accessibility tree. That didn’t replace testing with an actual screen reader such as NVDA, which would be necessary to confirm the reading experience, but it was a meaningful step beyond simply assuming the code worked.
I found this part of the process particularly satisfying because it completed something that can easily get overlooked when working with AI-generated solutions. ChatGPT hadn’t just given me code and sent me on my way. We’d discussed how the code worked, considered its limitations, revised the implementation, and then investigated whether the published result behaved as expected.
And yes, this was still all for a registration flyer.
The conversation was the point
We spend a lot of time talking about AI as a productivity tool in education. Write an email, generate a rubric, summarize a document, build a quiz. Those are useful applications, but I think they sometimes overshadow another benefit: AI can provide a place to work through a problem, especially when you don’t know exactly what you need at the beginning.
In this case, I knew what I wanted students to experience, but I didn’t know the best way to make it happen within Brightspace. I used ChatGPT to explore that gap. I questioned recommendations that didn’t fit, asked for explanations when I encountered unfamiliar techniques, and revised the solution when new problems became apparent.
I also had to question ChatGPT itself. Its first image description wasn’t inaccurate, but it wasn’t particularly useful for my purpose. Its initial hidden-text solution worked toward the goal I’d described, but became redundant once the announcement included accessible HTML text. At several points, getting a better result required me to recognize that the answer I’d received wasn’t quite the answer I needed.
That’s an important distinction when we talk about AI literacy.
We encourage people to verify AI-generated information, and for good reason. These systems can be confidently wrong, and a convincing explanation doesn’t guarantee that the underlying information is correct. But verification is only one part of using AI effectively. We also need the confidence to question answers that might be technically reasonable but don’t fit the situation.
The process reminded me of working through a technical problem with a colleague. You describe what you’re trying to accomplish, consider an approach, discover something you hadn’t anticipated, and adjust. Sometimes the other person knows something you don’t. Sometimes you catch something they’ve missed. The value comes from the exchange rather than any single suggestion.
Of course, ChatGPT isn’t a colleague in the human sense, and it doesn’t carry responsibility for the final result. That remained with me. But having a conversational resource available to explain concepts, propose alternatives, and respond to follow-up questions made it easier to work through an unfamiliar problem without abandoning it or settling for something I didn’t fully understand.
What does this mean for digital learning?
I think there’s a direct connection to how we approach AI in teaching and learning. If we only teach students to use AI to produce answers, we’re overlooking the learning opportunities that can happen along the way.
Consider a student learning programming. They could ask AI to write a piece of code and submit the result without understanding much about it. Or they could use the same tool to understand why the code works, question a particular approach, explore alternatives, and test the results. The second approach doesn’t guarantee learning, but it creates more opportunities for it.
The same applies to writing, statistics, research, and many of the other areas where students are already experimenting with AI. What changes when we encourage students to ask follow-up questions, challenge explanations, and explain why they accepted or rejected an AI-generated suggestion?
The responsibility for evaluating the work doesn’t disappear. Students still need subject knowledge, reliable sources, and opportunities to demonstrate what they understand independently. AI can reinforce misconceptions as readily as it can help clarify them. But those limitations are reasons to teach students how to engage critically with AI, not simply reasons to focus on whether they used it.
There’s also a broader accessibility lesson here. Posting a registration flyer shouldn’t require this much technical work. Our educational technology platforms need to make accessible content easier to create without requiring faculty and staff to understand HTML, CSS, and the accessibility tree. The fact that we could work through a solution doesn’t mean the underlying design problem has disappeared.
Still, I came away from this experience with something useful. I learned more about visually hidden text, saw how browsers expose content to assistive technologies, and developed a better understanding of how to evaluate an accessibility workaround. That knowledge will carry into the next announcement, course resource, or faculty support question.
All this for a free T-shirt
Did ChatGPT save me time? Probably not, at least not if we’re measuring the time it took to publish one announcement. What began as a five-minute task turned into a conversation about WCAG accessibility, HTML, CSS, screen readers, browser developer tools, and the limitations of our learning management system.
But I learned something, and I was able to apply that learning immediately. Rather than simply accepting a generated answer, I could explain the approach, make changes based on the experience I wanted students to have, and verify important parts of the result.
That’s the part of AI use I’d like to see us talk about more often in education. Productivity matters, but it isn’t the only measure of value. Sometimes the benefit isn’t finishing a task faster. It’s understanding something better when you’re finished, even if getting there takes a little longer.
All this work for a free T-shirt.
And the duck wasn’t even giving one to me.
