Skip to main content

Week 10: Access + Accountability

October 27, 2025

Texts to have read / watched
Writing to turn in

Plan for the day:

  • First half: Let’s discuss!
    • Warm-up writing: tensions, takeaways, confusions, questions
    • Discussion: Questions, comments, connections
    • Writing to remember (around 10:20)
    • Sharing (around 10:30)
  • Break (10 minutes)
  • Second half: Let’s practice!
    • Writing alt text
    • Inspecting accessibility
    • Headings and document outlines
    • EXT: Studio.
  • Homework for next time:
    • machines + learning
    • looking ahead

First half: Discussion

Warm-up writing: tensions, takeaways, confusions, questions

I’d like you to start by calling to mind the readings for this week. What stands out to you as a particularly important take-away, something memorable or surprising? What stands out as an unresolved point of tension or confusion?

Depending on your own practices, you may want to make lists or freewrite, or even draw a picture or diagram. Either way, I want to spend 5 minutes on this composing-to-center. I won’t collect it, but I will ask for volunteers to share.

Discussion: Questions, comments, connections

Let’s discuss! We can take notes at bit.ly/dsam2025fall-notes.

If we get to grok-writing by around 10:15, that should give us about equal time to play with the concepts now and to play with the methods in the second half.

Who would like to share?

Starting points, should we need them
  1. How do Yergeau, Brewer, Kerschbaum, Oswal, Salvo, Selfe, and Howes take advantage of the digital medium in "Multimodality in Motion: Disability and Kairotic Spaces" to do things that wouldn't be possible on paper or in person? In what ways do they follow their own advice to make their webtext accessible and hospitable?
  2. Perceivable, operable, understandable, robust. How are these terms defined in relation to accessibility? How do they relate to digital studies concepts from earlier in the semester, including the affordances of digital media that we discussed way back in lesson 1, that things made of digital bits are characterized by: numerical representation, modularity, automation, variability, and transcoding – or, alternately, that they are by virtue of their digital nature capable of sustaining procedural, participatory, encyclopedic, and spatial characteristics? What do you notice differently about those earlier framings in light of the WAI terms?

  3. We'll talk more about generative AI in week 11, but given what you already know about GenAI, would you want to automate the creation of alt text? What could be the benefits? What could go wrong?

    How about video transcripts: is the risk/reward calculation the same?

  4. Yergeau et al write,

    Universal design is a process, a means rather than an end. There’s no such thing as a universally designed text. There’s no such thing as a text that meets everyone’s needs. That our webtext falls short is inevitable.

    But to say that no text will be universally accessible is not a justification for failing to consider what audiences are invited into and imagined as part of a text. It matters who reads, in matters who engages, and it matters who is conceptualized as a reader.

    Consider the "public-facing deliverable" you've been iteratively developing for your own project. Who is "conceptualized as a reader" by your design choices so far? In what ways do you / will you invite access to your project?

EXT: The fairness conundrum of presentations 3 & 4.

Grok writing

Spend some time putting marks on a page to help you think through, and consolidate for yourself, what we discussed today. What do you want to remember? What are you left wondering?

After a few minutes, I’ll ask everyone to share one thing, to which the only response will be “thank you.”

Break (10 minutes)

I’m guessing we’ll hit the break at around 10:40 or so. Try to be back for a 10:50 start, so we have a full hour to get hands-on.

Second half: Let’s practice!

I have way more we could do than we’ll actually have time for. Let’s start at the top, and move self-paced through the rest – but I’ll periodically cut in to make sure you get at least a little time with each of the following:

  1. writing alt text
  2. using headings to make document outlines
  3. testing accessibility with plug-in and built-in tools

Any extra time you have is for studio; just save me a few minutes at the end.

Writing alt text

As we’ve seen, the context of an image is essential to deciding what would be appropriate as a textual alternative: it depends what you’re trying to communicate. Rather than ask you to work within an artificial context, then, I’m going to choose one you all have already: your own project presentations from last week.

Of the images you included, which do you think you’ll want to show again – whether as part of your public-facing project or as part of a process reflection for this class?

If you haven't yet done so, take some time now to write text alternatives for at least a few of the images you plan to use.
  • If you’re working within a presentation, you can probably right-click on the image in your presentation software to enter alt text
  • If you’re working on a website, including a web-based README file, you have several options:
    • The image tag can take an alt attribute: <img alt='description goes here' src='path/to/filename.png'>
    • You can add a caption, linked to the visual using <figure><figcaption></figcaption></figure>. (For an example, right-click one of the images below and Inspect Element to see the underlying markup.)
    • You can use body text alongside the image to parallel what the image is “saying,” so you can use empty alt text (alt="") without losing meaning.
  • If you don’t yet have screenshots of your project-in-progress, go ahead and take some now! You can write draft alt text in a text file, to save for a future presentation or process reflection. Just be sure to include the image filename, so you know what the text corresponds to.

Headings and document outlines

Even if you don’t know much HTML, it’s good to know about headings, because they’re also present in other places like Word documents, Google docs, and Markdown files (such as a GitHub README).

In general, you shouldn’t choose a heading level based on what it looks like – you can always change what it looks like to suit your preferences. Instead, use a logical nested sequence:

  • Use a single <h1> (or # in Markdown) at the top of the page: this is more or less your title. Each document should have one, but only one, h1.
  • Use <h2> (or ##) for the main sections of the page: the first column of the outline, essentially. Don’t skip straight to <h3> or below.
  • You can, however, jump back up to an <h2> if you’ve gotten down past <h3> to <h4>
  • In general, differences in heading levels past the fourth are too hard to discern or keep track of, and you should probably look to restructure or just use a list or boldface (or both) to structure whatever’s going on at that level of detail.

Let's have a look at our notes document: are the headings properly structured? Are there any days when additional structure would be beneficial?

How about the README for your project (if you have one)?

Inspecting a website’s accessibility

There are multiple ways.

  1. We might try the WAVE browser extension/plugin.
    course homepage with the WAVE extension enabled
    The WAVE extension will quickly summarize both inhospitable features (errors, alerts) and hospitable features (features, structural elements) of the current web page, and labels them with icons. Further tabs provide details and reference materials you can use to improve.
  2. Firefox has a pretty great built-in Accessibility Inspector. Just right-click anywhere on the page and choose "Inspect Accessibility Properties."
    course homepage with the Firefox Accessibility Inspector activated
    Available by default in Firefox, the Accessibility tab of the Inspector tool can check for contrast, keyboard navigation, and text labeling issues. It can also simulate various kinds of color-blindness.
    • NB: Look for the "check for issues" button at the start of the inspector tab; you may have to change it from "None."
      close-up of firefox accessibility inspector's check issues button
      Issues to check for include color contrast, keyboard navigation, and the availability of text labels for navigable or interactive components of the page.
  3. Did you know that PowerPoint will also let you check color contrast and reading order for keyboard users? On the Review tab, select the option to "Check Accessibility." This tip courtesy of PR company Current Global's "Accessible By Design" 21-Day Challenge.
Choose one of the above and check your own project pages, my course pages, or any other web interface you're interested in improving.

EXT: Studio

Finished with all the above? Use the remaining time to move your project forward – or to produce transcripts of your video/audio files from last week. (Check the resources page for my current favorite AI transcription tool – or suggest others!)

Save 10 minutes at the end: five for a quick exit note in the google doc and another five to look ahead at the next few weeks.

Homework for next time

As always, continue working on your project – now with a little more feedback – and take notes in your Mindful Practice Journal.

Next week we’ll talk about machine learning and GenAI, and the week after that I’m asking you all to bring in example projects in your fields that are awesome and inspiring. So if you haven’t yet looked around at what your digital project is in conversation with, consider this a two-week warning! ;) (But no, your example doesn’t have to be on the exact same subject.) Alison will be joining us for both of those, and for the second she’ll be hosting in person while I Zoom in from New York.

For next week, I’ll also ask you to add your thoughts to the discussion forum after reading. For our lead responders, I believe we’re back to John, Rose, Tunga, Scylla, and Yuqing.

In preparation for week 11, please watch / read:

Back to the calendar