♿ A11Y Lutèce #6 at Upfast: Accessibility as a Process, Not a Backlog Item

on September 16, 2026

The sixth A11Y Lutèce was held on Wednesday, September 16, 2026, at Upfast’s offices at 7 rue Blondel in Paris. One year after the group was launched by Jean-Pierre Gay and Sébastien Bénard, the meetup has become a bimonthly event: six events, a room that fills up, and a simple format—an hour and a half of talks, followed by time for discussion over drinks.

Doors open at 6:40 p.m., and the talks begin at 7:10 p.m. The Meetup page states it plainly: there is an elevator, but no wheelchair access or accessible restrooms. For an accessibility meetup, this is information that should be treated as key information, not as a footnote.

Upfast, an IT freelance staffing firm, is hosting this event. The host puts it plainly, without marketing jargon: since the European Accessibility Act, accessibility is no longer an item pushed to the end of the backlog “for when we have time.” It has become a legal requirement—and therefore a skill we look for when hiring. TF1, BNP, Sanofi, Accor: the clients mentioned in the session are also, in part, in the audience.

Three talks, three levels of scope. Nicolas Barcacci explains how a mobile team integrated screen readers into the development process for the All Accor app. Bertrand Keller expands on the legal role of the accessibility lead and maturity indicators at Sopra Steria. Guillaume Barbier gets back down to the HTML level: a “layered” table can be semantically correct and yet still unusable for a screen reader.

The common thread isn’t “we have to make things accessible.” It’s harder than that: specifying isn’t enough. A process, a schema, or a headers attribute are all just intentions. Execution—sprint, governance, screen reader runtime—determines whether that intention reaches the person who needs it.

Implementing Accessibility Within the All Accor App

• Speakers: Nicolas Barcacci (LinkedIn)
• Type: Experience Sharing
• Language: French
• Date: September 16, 2026 · Upfast, Paris

A talk on mobile engineering, not an accessibility statement. Nicolas Barcacci, a senior Android developer at Accor, explains how the All Accor app team moved from identifying technical debt during retrospective reviews to a process where screen readers are integrated into the design, acceptance criteria, and sprints.

Implementing Accessibility in the All Accor App

The All Accor app is a consumer-facing product: hotel listings, ratings, and a loyalty program. For someone using VoiceOver or TalkBack, each screen is a sequence of focus points, not a visual composition. The talk explores this disconnect and how a mobile team tried to make it visible to everyone—including designers.

What This Talk Covers

The starting point wasn’t a sudden RGAA audit. It was a retrospective: there were too many accessibility issues in the app, and no one had a systematic approach. The team began with a weekly one-hour workshop. We build our skills, we investigate, we fix issues. Then we realize that fixing things screen by screen isn’t sustainable. We need to represent the expected behavior of the screen reader in a way that sighted people can annotate.

This led to three initiatives, presented in this order: a visual convention for annotating mockups, a process change to stop creating technical debt, and then a series of concrete cases—images, grouping, screen titles, and backend content.

Important Technical Points

Annotate the Screen Reader, Not Just the Screen

The team takes screenshots and annotates them. The color code presented in the session is not a public design system; it’s an internal language for specifying what the accessibility runtime should do:

• blue: quick navigation structure—headings/landmarks, the “table of contents” that allows users to skip a block and navigate the screen other than node by node;
• green: elements that are less structuring than a heading, but which must be read as a single block;
• gray: behavior intended for sighted users, which is not replicated as-is for users who are blind.

The purpose is not cosmetic. As long as the screen reader remains an invisible API, the design cannot account for it. An annotation transforms an accessibility intention into a design artifact, just like a flow or a loading state.

Change the process before exhausting the backlog

Addressing the debt alongside delivery—one hour per week—has an obvious limitation: we spend our time fixing what the process continues to produce. The team therefore incorporates accessibility into the acceptance criteria. A user story is no longer “complete” until the mockups have been updated to include accessibility.

Identified points of contact are added:

• accessibility leads on the iOS and Android sides, within the tech team, not in a separate unit;
• a requirement for a consistent user experience across sub-apps and between iOS and Android;
• sprint capacity dedicated to cross-functional topics—not just the current issue.

The point of contact here is not the legal point of contact for the multi-year plan (the subject of the next talk). It’s a team role: we know who to ask, and we don’t scatter knowledge across three Slack channels and a dead wiki.

Images: Decorative or Meaningful

A simple case, and one that’s already been largely addressed in production. Many interface images are decorative. Leaving them in the accessibility tree clutters an already lengthy read. We ignore them.

Some images convey information. The example of the room is the hotel rating: a “5” next to graphic stars. Before the correction, the screen reader announced something like “5-star hotel”—the number, not the unit. Sighted people see five stars. Others do not have the same information. The correction is universal, across all languages: a description (content description / accessibility label) so that the focus announces “5-star hotel .”

Grouping Nodes Without Overwhelming the Screen

A mobile screen reader moves node by node—swipe right, swipe left. Without any adjustments, a hotel listing is a jumble of elements: name, city, type, “ 5,” image of stars, rating. The example given during the session resembled a Sofitel listing: each gesture moves the user forward by a single element. People who speed up text-to-speech lose even more time on these micro-blocks.

The solution is to group together what belongs together. “Hotel” + “5” + “stars” makes sense as a single statement. Having the entire screen in a single block doesn’t make sense: if I want to know whether the hotel is part of the ALL program—Accor Live Limitless—I shouldn’t have to wait until the end of a lengthy description.

On Android, the property shown is the grouping of descendants—mergeDescendants in Compose; the idea is the same in classic View: one group, one focus, one label. The engineering issue isn’t the API. It’s the decision: what to group, what not to group.

Screen title, loading, backend

Three other, more structural issues:

• Many screens have no title. A sighted person scans. A person using a screen reader navigates. A screen title summarizes the page and is accessible to assistive technology, even if it isn’t visually “presented.”
• A loading screen must be announced. Otherwise, the interface is simply silent while the application is working.
• As long as the text is generated on the app side, the team can refine it. As soon as content comes from the backend—CMS, business terminology, uncontrolled text—the front end can no longer fix it. Nicolas addresses the issue openly: the backend must provide accessible text, not just text visible to sighted users.

The in-session demo is meant to show the result in the app, not to run through an API catalog.

Key Takeaways

Mobile accessibility isn’t just about checking off boxes at the end of a ticket. At All Accor, it starts with making the screen reader visible in the design, then by incorporating it into the Definition of Done. Local fixes—stars, grouping, headings—are only sustainable if the process stops creating new technical debt, and if the backend stops sending content that the front end cannot make accessible.

Darkwood’s Thoughts

This highlights an issue of orchestration rather than widgets. The team had people, one hour per week, and a list of bugs. It wasn’t a workflow: no entry criteria, no DoD, no points of contact, no reserved capacity. As soon as accessibility becomes a named step in the delivery process—just like dark mode or large fonts in the design flow—it stops being a “Friday night hero.”

Node grouping teaches the same lesson, at the runtime level: too much granularity, and the user pays for every action; too much aggregation, and useful information gets buried. It’s a step boundary issue— not a “no more ARIA” issue. AI agents that generate screens without this judgment will reproduce the fragmented hotel listing—only faster. Ifaccessibility isn’t part of the design process—annotated mockups, acceptance criteria, prompt skills—it will disappear from the generated code just as it disappeared from the backlog.

Event page

Sopra Steria Accessibility Strategy: Building Performance Metrics

• Speakers: Bertrand Keller (website · LinkedIn)
• Type: Case Study / Strategy
• Language: French
• Date: September 16, 2026 · Upfast, Paris

Bertrand Keller changed the title during the session. Away from the Meetup’s slogan, toward the real question: the obligation to evaluate, the ability to improve, strategy. The talk does not promise an audit toolkit. It describes what the law requires of an accessibility coordinator, why a single coordinator cannot handle it alone, and why the average RGAA score is not an indicator of maturity.

The Obligation to Evaluate: The Coordinator, the Framework, and What RGAA Scores Don’t Measure

Bertrand Keller attends a lot of DevFests. He says it right off the bat: accessibility often ends up in a small room at these events. Here, the audience is already on board. So he can talk about governance without spending twenty minutes justifying why the topic matters.

What the talk covers

Two concepts, explored in depth. Should you plan before acting? Not always—but for a standard, the law tends to say yes. And what, exactly, what exactly is that?

The position is mandated by law. Digital accessibility is one of the few disciplines made mandatory: public services, and companies exceeding the revenue threshold set for public service obligations (Bertrand cites 250 million euros). The European Accessibility Act adds another framework; the talk doesn’t go into the details of the legislation. The operational core, however, is clear:

1. a multi-year plan (governance, objectives, maximum of three years);
2. annual action plans;
3. evaluations.

This is not just an internal quality control ritual. It is the cycle that the law transposes from an international framework: plan, action plan, evaluation—and it is the evaluation that unlocks the resources. Bertrand’s analogy—deliberately offbeat—is that of donors and equality indicators: no one is imposing a framework from another context on you; you are being asked to build your own, to demonstrate growing maturity.

The Sopra Steria 2025–2027 Multi-Year Plan is the deliverable of this project: the first such plan published by the group, with a designated point person and a link to CSR and responsible digital practices.

Important Technical Points

The coordinator is not an auditor with a title

The plan is not open-ended. The law sets out its main components—Bertrand refers to mandatory “H2” sections. The designated representative must then oversee the following, often alone:

• the management of the plan (scope, authority, name);
• procurement: in a large group, 80 to 90% of products are purchased; the law also covers internal tools (vacation, HR, intranet), not just what is sold;
• commercial bids, when working with service providers;
• HR: a digitized hiring process, but also physical accessibility (for people with disabilities, noise levels, color schemes);
• training for the entire company, not just developers—including e-learning, which must itself be accessible and sometimes multilingual;
• budgets, which are often lacking;
• audits and building expertise.

It’s a diverse landscape. Someone evaluated across all these areas at once is “out of the running” as soon as one area falls outside their personal background. Setting up accessible in-house training can be a full-time job. But there’s still everything else to do. The accessibility lead works with HR, communications, and content. They report to IT, or communications, or senior management—and their manager often doesn’t understand accessibility.

Sopra Steria: Start with the framework, not with the average audit scores

Sopra Steria, in Bertrand’s words: “a small company” with ~5 billion in revenue, ~20,000 employees in France, ~50,000 worldwide, including an Indian division. The challenge wasn’t “the France division.” It was the entire group. It falls under CSR, specifically the responsible digital initiatives component, within the context of CSRD: companies subject to these requirements must publish social data, and the 2016 French law already mandated a designated accessibility officer.

The organizational pitfall is immediate. Stakeholders view accessibility as a chain of audits. The law mandates disclosures, which require audits, so the coordinator “must audit.” Bertrand flips this on its head: his mission is the framework. Action plans and assessments come later. Without a framework, we just pile up scores.

Maturity models cannot be copied

Several models exist. Bertrand introduces at least three of them to the room:

• the W3C Accessibility Maturity Model, which focuses more on practices, with levels such as Launch and Integrate;
• a model that’s more organizational in nature (integration within the company);
• a model focused more on design/product (the acronym DAM/AMM mentioned during the session refers to this family of models, alongside the Microsoft model).

Each carries significant weight—it involves approximately 150 criteria, sometimes across 5 levels (not launched, reactive, anticipatory, proactive, widespread) and 7 dimensions that do not overlap. A single evaluator cannot simply “check off” all of this. Universities have matrices that incorporate students. A small organization needs a matrix tailored to its size. Microsoft, a producer of operating systems and hardware, does not measure the same things as an IT services company.

We can measure capabilities, practices, and results. These are not interchangeable. The law, as Bertrand interprets it, requires organizations to develop their own indicators—not to import a predefined grid.

The actual scope extends beyond public websites to include corporate social networks, emails, PowerPoint presentations, and internal PDFs. All of this should be accessible. This brings us to processes and culture. The most obvious obstacle highlighted in the talk: executives are out of touch with the front lines, don’t understand accessibility, and often choose between AI or accessibility—not both.

The RGAA average is not a management tool

All affected websites, apps, and intranets must have a declaration, which requires an audit. The RGAA generates a score. What organizations do: list, audit, calculate the average, and aim for 100%.

Bertrand is clear: it doesn’t work. It measures mandated compliance, not maturity. Maturity cannot be mandated by law because it is specific to each organization. Measuring for the sake of measuring doesn’t show what’s improving. The role of the accessibility lead is to know what’s making progress, not to display an average.

AI is breaking the accessibility rituals of the old world

The last third is the most current. Everything designed for accessibility—audits, checklists, training for dev teams—targets the old way of doing things. Today, “the dev is a guy talking into a box” who’s making the model shoulder an increasing share of the software.

Questions left open, intentionally:

• Where does accessibility fit into this workflow?
• What does the accessibility lead measure?
• Is an additional section needed in the multi-year plan?
• Does the prompt include accessibility?
• Is there a specific skill involved, and does it get overlooked as the conversation progresses?
• Will slow user testing survive against very fast AI code?

The organizational conclusion: a single point of contact, with no budget, no experts, and a poor understanding of the law, cannot make progress. This is no mystery. It is an under-resourced system.

Key Takeaways

The accessibility coordinator is not a mere auditor. The law requires a framework, plans, and evaluations—a maturity cycle— not an average of RGAA scores. The W3C and vendor matrices are sources of inspiration, not checklists to be applied in isolation. And the accessibility process designed for teams that write code by hand has not yet been adapted to modern automated workflows.

Darkwood Reflections

This is the talk that comes closest to what Darkwood calls a workflow. The multi-year roadmap is an orchestration: named stages, owners, metrics, and failures. The classic mistake organizations make—starting with the audit because it’s the visible deliverable—is the same as deploying ten agents without defining the Definition of Done. You end up with activity (scores, traces) but no throughput (maturity).

AI widens the gap. A developer who codes quickly skips the time-consuming user testing process. If accessibility isn’t a step in the workflow—prompt, skill, review, test—it doesn’t exist, just as it didn’t exist in the “we’ll see later” backlog. An evaluator who measures only RGAA compliance won’t see this gap: yesterday’s score says nothing about the code generated this morning.

Sopra Steria Multi-Year Plan 2025–2027

When tables break: stratified tables

• Speakers: Guillaume Barbier (Paris Web · 24 Days of Web)
• Type: Technical talk
• Language: French
• Date: September 16, 2026 · Upfast, Paris

Guillaume Barbier, a business analyst at Razorfish, is returning to A11Y Lutèce for the second time. His specialty: CMSs that don’t cause too many accessibility issues when contributors aren’t properly trained. Complex tables have, by his own admission, been a recurring failure. The talk focuses on one pattern: the layered table.

When Tables Break: Layered Tables

A data table isn’t just an Excel grid pasted onto a page. It’s a structure of headers that gives meaning to the cells. The “stratified” pattern looks simple to the eye: header bands that divide the table into groups. For a screen reader, these bands often represent unmet implicit expectations.

What This Talk Covers

The case study consists of a single grid. Three columns—name, job title, and direct supervisor—and seven rows. Four employees, plus two “full-width” rows: Information Systems Department (ISD), followed by the Marketing Department. Visually, you can instantly connect Abdel Cherif, a developer, to Nathalie Nguyen and the IT Department; Samia Réno, a system administrator, to the same department.

None of this information is in the employee cells. It’s a spatial association. To recreate it in the code, Guillaume links each cell to its headers: “Name” column, “ISD” level, “Job Title” column, and the note that the developer is Abdel Cherif. In HTML, this is the cumbersome approach: id on the headers, headers on the cells. He asks the room to trust him with the markup. Then he launches the screen reader.

It doesn’t work.

Important Technical Points

Visual Implicitness Isn’t in the Tree

Sighted people cross-reference the top columns and the stratum band without thinking about it. The screen reader only has what the accessibility tree provides. Recoding this association is the real work—not “making a table.” Guillaume rejects the 20-minute HTML lesson. The issue is functional: Have I made explicit what my eye does on its own?

It’s the same problem as with the Accor stars, on a grid scale: the information is in the layout.

Correct markup can still fail at runtime

The demo is the highlight of the talk. The reader announces a 3-column, 7-row table, then associates headers with the first cell that Guillaume hadn’t linked—IT and marketing department all at once. Further down, Samia Réno finds herself stuck with IT “like a mystery.” As long as you stay within a column, it holds together more or less. As soon as you change rows, the rendering breaks down.

The conclusion, without any grandstanding: the semantic structure is in place, but the screen reader can’t make sense of it. Guillaume doesn’t have time to explain the technical reasons behind it (browser, accessibility tree, AT combinations). He draws the engineering lesson from this: beyond a certain point, “writing good HTML” is no guarantee of proper rendering. Tables that are too complex break, even when properly specified.

This is documented in greater detail in his article Are Accessible Complex Data Tables Possible? (24 Days of Web, 2025). The meetup is a live demonstration of this concept, using the “strata” motif.

Two approaches: flatten or split

Rather than piling on more ids/headers, take a step back: do we really need this complexity? The same information can be presented in a more robust way.

Flatten. The strata become just another column—“Service.” We lose the instant visual grouping. We gain a regular grid that screen readers can navigate.

Split. One table per layer. A <caption> identifies the service (IT, marketing), as the reader announces upon entering the table. Less compact. Simpler. Two independent datasets perhaps didn’t need to coexist in a single grid.

In both cases, we stop asking the accessibility runtime to perform a sequence of actions that browsers cannot support.

Key Takeaways

A layered table is easy on the eye but difficult for screen readers to navigate, even when properly marked up. The solution isn’t more attributes. It’s a different form: a service column, or multiple tables with captions. Visual complexity isn’t a business requirement.

Darkwood’s Thoughts

Once again: the specification is not the implementation. headers and id are a contract. The screen reader is the runtime. If the runtime does not honor the contract, the system is flawed for the user, regardless of whether the specification is followed.

This is the same diagnosis as with Flow or an agent: orchestrating steps that are too granular, or a graph that is too dense, produces an unreadable trace. Flattening (one more column) or splitting (two workflows) are architectural choices. CMSs that let contributors merge cells “to make it look nice” create inaccessibility by design—Guillaume has been saying this for ten years. Agents who churn out <table> from an Excel file will do the same thing, only faster, unless the workflow prohibits the pattern.

Guillaume is leading the workshop [Thinking the Implicit, Thinking the Invisible] on September 24, 2026, at Paris Web(https://www.paris-web.fr/2026/atelier/penser-limplicite-penser-linvisible). The meetup was already a teaser for it: the visual implicit, once left unsaid, becomes a barrier.

Article: 24 Days of the Web

What Holds the Evening Together

Three levels, a single divide.

At Accor, screen readers didn’t exist in the process: we made them visible (annotations), then mandatory (DoD), then equipped them with tools (references, iOS/Android standards, sprint capability). At Sopra Steria, auditing was overemphasized: we had to go back to the big picture, to maturity indicators, and admit that a single point of contact cannot handle procurement + HR + training + AI. At Guillaume’s, HTML was overemphasized: the “strates” pattern is “correct” but broken.

Accessibility isn’t making progress because of a lack of checklists. It moves forward when we stop confusing activity with results: RGAA average, attributes set, tickets closed. The result is a person who understands the hotel form, who can hire, who can read a table. The rest is just orchestration.

AI, in all three talks, isn’t just a bonus chapter. It’s the new software runtime. If we don’t include accessibility in the workflow—mockup, criteria, prompt, skill, user test—it will be generated the same way we used to generate tables in strates: pretty, implicit, and silent.

Thanks to Jean-Pierre Gay, Sébastien Bénard, Upfast for hosting, and the three speakers. The group will continue to meet every two months; proposals for talks are still welcome. Pizza, chips, beer: networking isn’t just an afterthought. That’s where we recruit the skills that the EAA has made non-negotiable.

Meetup #6 A11Y at Upfast