Shift-left for more accessibility

posit::conf(2026)

Dr. Björn Fisseler

bjoern.fisseler@fernuni-hagen.de

2026-09-14

Open science means open insights, not just open data

…but whom do we leave out?

brick wall as a symbol for barriers

Dr. Björn Fisseler

FernUniversität in Hagen
Educational Technology Specialist
Research and Expertise
- Accessibility Evangelist (Universal Design & Digital Inclusion)
- Inclusive Digital Education & AI
- Support for Learners with diverse accessibility needs
Reach out to bjoern.fisseler@fernuni-hagen.de

Portrait Björn Fisseler, middle-aged man with grey hair, dressed in a professional blazer and white shirt.

QR code linking to https://2026positconf.bfisseler.de, where these slides are available.

Slides available at https://2026positconf.bfisseler.de

Everyone should experience our research with the same clarity and detail

Ability isn’t binary. It’s easy to picture ‘disability’ as one fixed category, someone either has a certain condition or they don’t. But that’s not how it actually shows up in front of a screen.

Someone might be permanently blind, reading your report with a screen reader.

Someone else is only temporarily affected, having a broken wrist. But suddenly they’re navigating everything by keyboard, no mouse, for six weeks.

And someone else isn’t impaired at all in the usual sense — they’re just glancing at your dashboard on a tablet, outdoors, in bright sunlight, and the contrast is too low.

These three people hit the exact same wall. No alt text is no alt text, whether you’re permanently blind or just glanced away for a second. No keyboard navigation is no keyboard navigation, whether it’s permanent or a six-week cast. And bad contrast is bad constrast, temporary or not.

You are not designing for a narrow group. You’re designing for anyone who happens to hit that barrier. That’s the multiplier effect of accessible design.

So if that’s the goal why doesn’t it happen by default? Why is accessibility so often something we bolt on at the very end, if we get to it at all?

a permanently blind person using a screen reader
a temporarily injured person navigating by keyboard only
a situationally distracted person glancing at a tablet in bright light

Disabilities can be permanent, temporary, or situational; illustration from Microsoft Inclusive Design.

Source: Microsoft Inclusive Design

Retrofitting accessibility is inefficient and costly

So why don’t we get there? In practice, accessibility usually gets handled at the end. After the report is written, after the chart is built. And retrofitting is expensive in multiple ways.

It costs time you didn’t budget for — going back through a finished document, reworking what was already done.

It’s patchwork, not built-in. If accessibility isn’t baked into the initial build, it feels and looks like an afterthought. Just like this wooden ramp built on the backside of an already ex

We want ‘accessible by design,’ not ‘accessible by correction.’

And it shows — you can usually tell when accessibility was bolted on afterward.

None of this is because people don’t care. It’s because accessibility sits at the end of the workflow, as a check. Instead of at the start, as a default. So what if we moved it?

It costs you time you didn’t budget for
It rarely matches the quality of an initial build
It shows — retrofits look and feel bolted-on

Wooden ramp on the backside of an old building.

Accessibility by design, not by correction.

“Shifting left” in the Quarto workflow closes the gap

Four principles carry every accessibility decision

Before we get practical, one bit of vocabulary.

The Web Content Accessibility Guidelines — WCAG — have dozens of success criteria, and three conformance levels, and a numbering scheme, and honestly nobody memorises them. But underneath all of it there are only four principles. You just need to remember one word, one acronym: P O U R - pour. (click)

P stands for Perceivable: can all readers receive the content? That’s alt text on a figure, that’s not encoding your groups in colour alone. (click)

O is for Operable: can the document be navigated and acted on? Heading levels in order, so a screen reader can jump. Link text that means something in a list of links. (click)

U like Understandable: can the document be made sense of? Short sentences. Expanded acronyms — like the one I just expanded. A table that says which column a number belongs to. (click)

And R is for Robust: does it survive? Your source outlives the format you render it to today. That’s the one people forget, and it’s the one Quarto is unusually good at. (click)

This is not a checklist you tick off at the end. It’s four questions you can ask at any point while writing — and every slide from here on is one of these four. I’ll name which one as we go.

Perceivable — can the content be received at all?
Operable — can it be navigated and acted on?
Understandable — can it be made sense of?
Robust — does it survive the format?

Semantic structure builds the accessible foundation everything else stands on

So here’s the shift: instead of fixing accessibility at the end, we build it in from the first line of Markdown. And the foundation for everything else — alt text, tables, output formats — is something you’re probably already halfway doing: structure.

When you write # or ## in Quarto, you’re not just making text bigger. You’re declaring a document outline — the same outline a screen reader uses to let someone jump straight to the section they need, the same outline a browser uses to build a table of contents automatically.

This is the cheapest win in the whole talk. If you’re already writing Markdown headings in order, you’ve already done most of the work. The failure mode isn’t ‘no structure’ — it’s usually skipped levels: jumping from an H1 straight to an H3 because it looks right. This breaks the outline even though the page still looks fine visually.

So provide a structure with appropriate headings, put relevant metadata in the YAML header, and use the various markdown elements for a semantic structure of your document.

Well-structured content allows more efficient navigation and processing. Everyone can more easily find and prioritize content in your document. Screen reader users can navigate directly to the content that is important to them. And if you are using a keyboard only,

Nest headings in order: #, ##, ###
Let one H1 (or the YAML title) anchor the document
Set lang and additional attributes in your YAML header
Use different markdown elements for better semantic structure

---
title: "Accessible Reporting"
lang: en
author: Jane Doe
---

## Introduction

### Background

### Methods

Headings tree, from the top, Accessible Reporting, one below, Introduction, one below, Background, Methods

Small writing choices remove barriers

Two more small choices — one very specific, one more of a general habit.

‘click here’ fails because screen reader users often pull up a list of every link on a page to navigate directly. If that list just says ‘here, here, here,’ it’s useless. Describing what the link actually leads to fixes that instantly.

The second one is less a rule than a mindset: write for clarity first. Short sentences. Expand an acronym the first time you use it. Even something as familiar to us as WCAG isn’t obvious to every reader.

This isn’t just good writing advice — it’s accessibility. Complex language is a barrier for people with cognitive disabilities, for non-native readers, for anyone skimming under time pressure. Clarity isn’t dumbing down. It’s designing for the reader who’s not you.

Write meaningful link text

Not: “…click here for more information.”

But: “…more information about the data source.”

Keep content clear and concise

Short sentences and paragraphs over long, complex ones
Expand acronyms on first use, e.g., Web Content Accessibility Guidelines (WCAG)

Screen reader link list with five uninformative entries: here, here, click here, here, more

The same link list with descriptive entries such as information about the data source and WCAG 2.2 quick reference

Visual information is for everyone, even those who cannot see them

There is also a lot of information that is not text, for example charts, plots, or diagrams. Visual information is important. Many images are helpful, as they are making content easier to understand. Images add value for example for neurodiverse people, people who are deaf, and also people from non-academic backgrounds. But for others, visual information is invisible, and they need a translation, an alternative text at least.

Not every image needs an alt text. If it is purely decorative, an image gets an empty alt text and a screen reader can skip ride past it. If it is informative, describe the key takeaway, but not every visual detail.

And if it is complex like a chart or a diagram, you need to describe more details. You provide information on the type of the chart, the data it shows, why it is included and you describe the pattern.

But you also need to make the visual itself accessible. First, think about the chart type. Some chart types are more difficult to understand than other. And, second, most of the package defaults are rarely colorblind-safe. So make sure to use a colorsafe palette. And distinguish data with more than just color, with shape, line style, or pattern.

Choose alt text based on image type

Decorative → empty alt text (alt="")
Informative → describe the key takeaway
Complex (charts, diagrams) → describe the pattern, not just “a chart”

alt=“Chart type of type of data where reason for including chart” plus link to data source somewhere in the text (Cesal, 2020)

Scatterplot distinguishing three penguin species by color alone — red, green, and blue points.

“Scatterplot of flipper length vs body mass across Palmer Penguins where Gentoo penguins show the largest flipper length and the highest body mass.”

But don’t rely on color alone

Make visual output accessible

Package defaults are rarely colorblind-safe

Distinguish data with color, shape, line style, or pattern

Consider adding the data

Scatterplot distinguishing three penguin species by color alone — red, green, and blue points.

Scatterplot includes different colors and different shapes, circles, triangles, squares, for the data points representing three penguin species.

Data

			body
Comparing wing span vs weight
	flipper		mass
Species	length		g
Species	avg	sd	avg	sd
Adelie	189.9536	6.539457	3700.662	458.5661
Chinstrap	195.8235	7.131894	3733.088	384.3351
Gentoo	217.1870	6.484976	5076.016	504.1162

Scatterplot distinguishing three penguin species by color alone — red, green, and blue points.

AI can help you write your alt text

(click)

Writing alt text is cumbersome and slow. And when the plot changes, you have to adjust the alt text to reflect the change. (click)

But with all these large-language-models, there is help on the way. You can use a multimodal LLM to automatically generate thje alt text for you. When the plot changes on the next rendering of the document, the alt text gets automatically updated, too. You can try various prompts to reflect alt text recommendations for different chart types.

This all is relatively easy with packages such as ellmer or btw. (click)

You just have to connect the package to the LLM you want to use, provide the chart plus some instructions to the model, and voila (click)

It writes the alt text for you. But remember that you are always responsible for the alt text the model has generated.

Writing a good, detailed alt text by hand is slow and easy to forget
With a multimodal LLM, you can generate it automatically from the rendered plot
Use the ellmer package (or the new btw package) to connect to an LLM

generate_alt_text <- function(ggplot_obj) {
  ggsave(save_path, ggplot_obj)
  alt_text_chat <- chat_openai_compatible(base_url = "...", model = "...")
  alt_text_chat$chat("Describe this chart for someone who cannot see it...", 
                      content_image_file(save_path))
}

Scatterplot of flipper length vs. body mass across three penguin species. Gentoo penguins show the largest flipper length (210–230mm) and highest body mass (4500–6000g)..."

Structured tables transform complex data into navigable, inclusive information

Both columns show the same five days from airquality. On the left is what I wrote, on the right is what the audience sees. And on the right, this looks fine. Seven columns, grouped under Measurement and Time, missing values on the fifth of May.

But markdown has exactly one header row. There is no syntax for a second level, so the grouping isn’t a header at all — it’s the header, and the real column names are the first row of data. Ozone, Solar.R, Wind: those are values now. A screen reader moving across row one announces 41 as belonging to Measurement. Not to Ozone. The column names have quietly become content, and every value in the table has lost the one label that would let you interpret it.

[click]

Same data, same visual result. Different source.

Not much on the right has moved. The two renderings are close enough that you have to look twice to tell them apart.

What changed is that every part of the table now has a much better structure. tab_header() gives you a header. tab_spanner() gives you a second header level, which comes with a colspan saying how far the group reaches. sub_missing() turns an empty cell into the words “no data”, because a blank is ambiguous and “no data” is information.

None of this is styling. It’s the same table, described properly, and the description survives into the markup. That’s why I picked the gt package. Accessibility isn’t a feature you switch on, it’s a by-product of writing the table down honestly.

| Measurement |  |  |  | Time |
| ---: | ---: | ---: | ---: | ---: |
| Ozone | Solar.R | Wind | Temp | Year |
| 41 | 190 | 7.4 | 67 | 1973 | 
| 36 | 118 | 8.0 | 72 | 1973 |
| 12 | 149 | 12.6 | 74 | 1973 |
| 18 | 313 | 11.5 | 62 | 1973 |
| NA | NA | 14.3 | 56 | 1973 |

The two-level header is faked with an extra row.

It looks right but is read as data.

gt(airquality_m) |>
  tab_header(
    title = "New York Air Quality Measurements",
    subtitle = "Daily measurements, May 1-5, 1973"
  ) |>
  tab_spanner(
    label = "Time",
    columns = c(Year, Month, Day)
  ) |>
  tab_spanner(
    label = "Measurement",
    columns = c(Ozone, Solar.R, Wind, Temp)
  ) |>
  sub_missing(missing_text = "no data")

The two-level header is a real header.

It looks the same but is read as structure.

Measurement				Time
Ozone	Solar.R	Wind	Temp	Year
41	190	7.4	67	1973
36	118	8.0	72	1973
12	149	12.6	74	1973
18	313	11.5	62	1973
NA	NA	14.3	56	1973

No caption, no grouping, no footnotes, no units.

Every cell reads the same.

Table 1

Measurement				Time
New York Air Quality Measurements
Daily measurements in New York City (May 1-5, 1973)
Ozone	Solar.R	Wind	Temp	Year	Month	Day
41	190	7.4	67	1973	5	1
36	118	8.0	72	1973	5	2
12	149	12.6	74	1973	5	3
18	313	11.5	62	1973	5	4
no data	no data	14.3	56	1973	5	5

Caption, spanners, footnotes and units each have a slot.

Every cell knows which column it belongs to.

One Quarto source, many formats

Three renders of the same file. HTML in front, PDF behind it, Word at the back. The only difference between them is three lines of YAML.

They look similar, and that’s not the interesting part. That’s what a typesetting system is for. What matters is underneath. Each format carries the accessibility you implemented in the source document. The Word file has real heading styles. The PDF has a tag tree, because Typst writes tagged PDF by default now.

I wrote none of that three times. I wrote it once.

Headings in markdown, fig-alt on the figure, lang in the YAML. Each format mapped it onto whatever structure that format has.

This is the practical case for shifting left. Retrofit accessibility at the end and you pay per output: fix the Word file, the PDF is still broken. Fix the PDF, and the next re-render undoes it. Do it in the source and you pay once — including for the format someone asks you for next year, which you don’t know about yet.

The work sits in your source, not in a repair step afterwards.

Accessibility that travels as far as the format allows.

One single document enables multiple formats
Semantics and content are written once
Each format maps them to its own structure

Fix it once in the source, or retrofit it once per output.

Same document rendered three ways, Word in the back, PDF on second layer, HTML page in a browser in front

Small habits applied in the source make a document accessible by default

Accessibility: necessary for some, useful for everyone.

Structure your content
Take care of your visuals
Render the format your readers need

Ramp and stairs combined, leading to a building entrance

Openness is only complete when the results are accessible.

We started with a question. We’ve made our data open, our code open, our methods open. But have we made our conclusions open?

Everything in this talk was small. A heading level in the right order. A sentence of alt text. A table that describes itself instead of faking a header row. Three lines of YAML. None of it was hard, and none of it needed a specialist.

What it removes is a cost — one we don’t pay. Every barrier left in a document is work handed to a reader who didn’t choose it, on top of the work of reading the research.

And doing it at the start rather than the end isn’t about virtue, it’s arithmetic. Accessible by design costs one pass. Accessible by correction costs one pass per output, every time you re-render.

Open data. Open code. Open methods. And then a wall in front of the conclusions.

Let’s stop leaving them behind it. Shift-left on Quarto to ensure accessibility for everyone.

Shift-left on Quarto to ensure accessibility for everyone.

Take it with you

Dr. Björn Fisseler
FernUniversität in Hagen

posit Open Source blog on Quarto: https://opensource.posit.co/software/quarto/

QR code linking to https://2026positconf.bfisseler.de, where these slides are available.

Slides available at https://2026positconf.bfisseler.de