UID 07 - Principi e strumenti per l’accessibilità con Marianna Cerato

Source: transcript Part 1 + Part 2 + slide deck
Speaker: Marianna Cerato
Related: UID 07 - Course Map, Accessibility, WCAG, Assistive Technology, Accessibility Testing, Cognitive Accessibility

One Sentence

This lesson frames Accessibility as a design framework: digital products should let as many people as possible act autonomously, regardless of permanent, temporary, or situational ability.

Core Thesis

Accessibility is not a final checklist or a legal patch at the end of a project.

It is a way of designing:

for autonomy
for dignity
for different bodies and minds
for different contexts of use
for legal compliance
for better usability
for stronger product quality

Marianna’s central point is that disability is part of human experience. Everyone’s body, attention, memory, vision, hearing, voice, and motor ability can change across a day or across a lifetime.

Lesson Map

flowchart TD
  A["What accessibility means"] --> B["Disability and context"]
  B --> C["Adaptive strategies and assistive technology"]
  C --> D["Legal framework"]
  D --> E["WCAG and POUR"]
  E --> F["Accessible UI guidelines"]
  F --> G["Tools, handoff, design systems"]
  G --> H["Testing with tools and people"]

Speaker Context

Marianna Cerato is an Experience Designer and Team Manager at Tangible.

Tangible’s design vision is to create digital products and services that generate positive impact for business, for the people who use them, and for the ecosystem around them. This matters because the lesson connects accessibility with ethics, business, law, research, design practice, and implementation.

What Accessibility Means

Accessibility is the possibility of accessing a place, resource, product, service, or technology.

In digital design, a product is accessible when it is designed and built so that it can be used effectively by as many people as possible, independently from their abilities or disabilities.

Two important ideas:

access is a right
autonomy is a right

So accessibility is not only about “helping disabled users”. It is about removing barriers that stop people from doing what they need to do.

a11y is a numeronym for accessibility.

The number 11 represents the letters between the first a and the final y. Similar numeronyms include i18n for internationalization and l10n for localization.

Disability Is Contextual

The lesson avoids treating disability only as a permanent medical category.

Marianna uses everyday examples:

using dark mode because the screen is tiring
using subtitles in a quiet place
dictating notes instead of typing
zooming text because it is too small
increasing brightness under sunlight
carrying a child and losing normal hand mobility
being tired, medicated, stressed, or sleep-deprived

These situations show that ability changes with context.

This is useful for design because a product can disable a person when it assumes only one ideal condition: perfect vision, quiet context, full attention, both hands free, strong memory, stable connection, and comfortable posture.

Types Of Disability

The slide deck groups disabilities into five main areas.

Area	Examples	UI consequences
visual	color blindness, low vision, blindness	contrast, text size, screen reader support, non-color cues
cognitive	ADHD, autism spectrum, memory issues, mental health, aging	clear writing, predictable flows, reduced memory load
hearing	partial hearing loss, deafness	captions, transcripts, alternatives to audio-only content
motor	tremor, paralysis, arthritis, missing limbs, repetitive strain	keyboard access, target size, voice input, alternative gestures
speech/language	mutism, stutter, Tourette, degenerative disease, temporary voice loss	alternatives to voice-only interaction

The important design question is not “what diagnosis does this user have?”

The better question is: “what barrier does my interface create, and what alternative can I provide?”

Scale Of The Topic

The slides mention that disability affects a large part of the population: millions of people in Europe, a significant share of the Italian population, and more than one billion people globally.

The lesson also notes that many people use at least one accessibility setting on their device, such as dark mode, larger text, bold text, zoom, or live captions.

Accessibility is not a niche edge case. It is normal use.

Adaptive Strategies

Adaptive strategies are the techniques people use to make digital environments fit their needs.

Examples:

increasing text size
changing screen contrast
using dark mode
zooming
enabling captions
navigating by keyboard
using voice input

Designers should respect these strategies. A layout that breaks when text is enlarged is not robust. A component that only works with drag gestures is not operable for everyone.

Assistive Technology

Assistive Technology includes tools that help people access digital content and controls.

Examples from the lesson:

screen readers such as VoiceOver, TalkBack, JAWS, NVDA, Narrator, ChromeVox, Orca
speech input and voice control
screen magnification
virtual keyboards
switch controls
eye control
text-to-speech and speech synthesis

The key point: when we design interfaces, we are also designing what assistive technologies will read, announce, focus, skip, and activate.

Keyboard Access

Keyboard access is one of the simplest ways to test whether an interface is operable without a mouse.

A usable keyboard flow needs:

every interactive element reachable by Tab
a logical focus order
a visible focus indicator
no hidden traps
no focus hidden behind sticky headers, cookie banners, or chat widgets
controls that can be activated without pointer-only gestures

Keyboard navigation is important for blind users, motor-impaired users, power users, and anyone using alternative inputs.

Accessibility As A Legal Issue

The lesson emphasizes that accessibility is also law, not only best practice.

Main legal references from the slides:

Reference	Role in the lesson
Italian Constitution, Article 3	equal dignity and removal of barriers
UN Convention on the Rights of Persons with Disabilities, Article 9	access to physical, transport, information, and communication environments
EU Directive 2016/2102	accessibility obligations for public administration websites and mobile apps
European Accessibility Act, Directive EU 2019/882	minimum accessibility requirements across EU member states
D.Lgs. 82/2022	Italian implementation of the European Accessibility Act
Legge Stanca	Italian accessibility law connected to public-sector digital accessibility
UNI EN 301 549	European technical standard for ICT accessibility
WCAG 2.2 AA	practical web criteria used as the current reference for web content

For study purposes, the practical message is:

Designers need to know whether their client and product fall under accessibility obligations, because this affects scope, testing, documentation, risk, and budget.

Accessibility Declaration

The slides discuss the accessibility declaration as a public document that states the accessibility status of a website or app.

It should communicate:

whether the product is conformant, partially conformant, or non-conformant
which content is not accessible
why it is not accessible
what accessible alternatives are available
how users can report problems
when the declaration is updated

The important design lesson: if accessibility is part of legal accountability, it must be planned from the beginning. It cannot be hidden in the final QA phase.

Avoid Accessibility Overlays

The lesson warns against accessibility overlays.

An overlay is usually a widget added on top of an inaccessible product to claim accessibility. Marianna’s position is that this is not a real solution because the underlying interface, code, content, and interaction problems remain.

Accessibility must be inside the product, not pasted over it.

WCAG And POUR

WCAG stands for Web Content Accessibility Guidelines.

The WCAG framework is organized around four principles, often remembered as POUR.

Principle	Meaning	Design question
Perceivable	information must be visible or audible to users	can the user perceive the content?
Operable	controls and navigation must be usable	can the user interact without barriers?
Understandable	information and operations must be clear	can the user understand what to do?
Robust	content must work with current and future technologies	can assistive technologies interpret it reliably?

POUR is useful because it turns accessibility from a list of isolated checks into a thinking model.

WCAG 2.2 Changes

The lesson highlights that WCAG 2.2 keeps the previous structure but adds criteria focused especially on cognitive disability, low vision, input methods, and mobile-like interactions.

Important examples:

Criterion	Meaning for UI design
Focus Not Obscured	focused elements should not be covered by sticky headers, banners, or chat widgets
Dragging Movements	drag actions need a single-pointer alternative
Target Size Minimum	clickable targets need enough size or spacing
Consistent Help	help should appear consistently across pages
Redundant Entry	do not ask users to enter the same information again in the same flow
Accessible Authentication	login should not rely on cognitive tests without alternatives

This is especially relevant for forms, checkout, login, and service flows.

Example: Paying A Bill

The slides use the example of Marco, a low-vision user paying a postal bill.

Common barriers:

visual-only CAPTCHA
fields with only placeholders
vague error messages
session timeout without warning
scanned PDF as image
errors shown only in red
impossible keyboard navigation

Accessible corrections:

audio CAPTCHA or alternative verification
persistent labels
specific error messages
timeout warning and extension
tagged PDF with selectable text
icon plus text plus color
logical focus order and visible focus indicators

This example is useful because it shows that accessibility is not one feature. It is the result of many small design and implementation decisions working together.

The slide deck gives a compact checklist for UI design.

Area	Guideline
color	minimum 4.5:1 contrast for text
color	minimum 3:1 contrast for UI components and focus rings
color	do not use color as the only carrier of information
typography	define a complete type scale
typography	use line-height around at least 1.5x for reading text
typography	avoid justified text for readability
layout	use sequential structure
layout	use a coherent heading hierarchy from h1 to h6
layout	provide skip links where useful
navigation	keep focus visible
navigation	make focus not obscured
navigation	keep patterns consistent across pages
forms	use permanent labels, not placeholders as the only label
forms	avoid redundant entry
forms	use clear error and success feedback
content	add alt text where images communicate meaning
content	provide transcripts and captions for multimedia
content	expand acronyms the first time they appear

Color

Accessible color design is not only about passing a contrast checker.

Main points:

text should have enough contrast against its background
UI controls and focus rings also need contrast
information should not depend only on color
charts should use labels, patterns, shapes, or direct text, not only color legends
color palettes should be built as a system, not adjusted randomly screen by screen

The lesson connects this to Design Tokens: accessible color decisions should become reusable tokens, so the system stays consistent over time.

Typography

Typography affects accessibility because it shapes reading effort.

Important design decisions:

define complete heading and body styles
create a coherent type scale
keep hierarchy clear
use readable line-height
avoid walls of text
avoid fully justified text when it damages rhythm and spacing
chunk content into understandable units

This is especially relevant for Cognitive Accessibility. Clear text helps everyone, but it is critical for people with attention, memory, reading, or comprehension difficulties.

Headings And Structure

Headings are not only visual style.

A coherent heading structure helps:

sighted users scan the page
screen reader users navigate by sections
users understand hierarchy
search and assistive technology interpret structure

Do not use headings only because they “look bigger”. Use them because the content structure requires them.

Focus Indicators

Focus indicators show where the user is while navigating by keyboard or assistive technology.

A good focus indicator should be:

visible
high contrast
not covered by floating UI
consistent
present on every interactive element

Removing the focus ring for aesthetic reasons damages accessibility.

Link And Button Labels

Labels should describe the destination or action.

Avoid vague labels such as:

click here
read more
more details
continue

Better labels explain what will happen:

Download accessibility report
Open billing details
Contact customer support
View course calendar

This improves accessibility, usability, and SEO.

Forms And Feedback

Forms are one of the highest-risk areas.

Accessible forms need:

persistent labels
visible required-field information
text error messages
not only red borders or icons
logical DOM order
visible focus
meaningful disabled states
accessible names, roles, and values
no unnecessary repeated fields

The lesson’s practical reminder: placeholders are not labels.

Alternative Text

Alt text should describe images that carry meaning.

Decorative images should usually be ignored by screen readers. Functional icons must have accessible names. Interactive icons need both a clear visual state and a meaningful accessible label.

Good alt text depends on context. The same image might need a detailed description in one page and no description in another if it is purely decorative.

Accessible Content

The content layer also needs accessibility.

Important practices:

use real lists instead of fake bullets typed manually
expand acronyms the first time they appear
keep accents in uppercase letters
avoid autoplay
provide controls for moving content
provide captions, transcripts, and alternatives for audio/video

Content accessibility is not separate from UI. It affects comprehension, navigation, screen reader output, and user confidence.

Tools And Deliverables

The lesson gives tools for different phases.

During Design

Useful checks:

color contrast
color blindness simulation
accessible palette generation
type scale generation
focus-ring visibility
target size

Examples mentioned in the slides include Stark, A11y Color Contrast Checker, Color Blind, Polychrom, Contrast Grid, WebAIM Contrast Checker, and type scale plugins.

During Handoff

Accessibility handoff should make design decisions explicit.

Annotate:

heading levels
alt text needs
form labels
button and link behavior
focus states
keyboard order
ARIA or semantic expectations when relevant
multimedia alternatives
error and success messages

This connects directly to Handover: the designer is responsible for making accessibility decisions understandable to developers, and developers should return with questions when implementation constraints appear.

In The Design System

A Design System can make accessibility sustainable.

If tokens, components, forms, states, and documentation are accessible from the beginning, the product ecosystem becomes easier to maintain.

This connects the accessibility lesson with Francesco’s design-system lesson: accessibility should live inside components and system rules, not only in final page checks.

Accessibility Testing

Accessibility Testing has two sides.

Type	What it can do	Limit
instrumental / automated testing	scans code, headings, contrast, missing labels, obvious WCAG issues	cannot judge whether content truly makes sense
qualitative testing	tests with keyboard, screen readers, and real users	takes time and planning, but reveals real barriers

Automated tools are useful, but they cannot prove that the experience is accessible.

For example:

a tool can detect that an error message exists
a real user can tell whether the message is understandable
a tool can detect that a label exists
a real user can tell whether the label helps them finish the task

Testing Checklist

Start with simple actions:

navigate by keyboard
check visible focus
zoom text and check whether layout still works
use a screen reader
check text contrast
check link and button labels
check heading hierarchy
check form errors
test with people with real disabilities when possible

The lesson’s practical advice is to start now, one step at a time.

Cognitive Accessibility

The Q&A returns to cognitive disabilities, which are especially relevant for my own research interests.

Marianna stresses that cognitive accessibility is important and often underestimated. It includes attention, memory, learning difficulties, comprehension, ADHD, dyslexia, autism spectrum, aging, dementia, and many other conditions or contexts.

Design implications:

clear content helps everyone
predictable flows reduce cognitive load
chunked text is easier to process
left-aligned text is often easier to scan
repeated input should be avoided
OTP and CAPTCHA can create memory and comprehension barriers
alternatives should always be considered
the interface should be understandable at a glance where possible

This connects accessibility with everyday UI quality. Good cognitive accessibility often looks like good design: clear, structured, predictable, forgiving, and respectful of attention.

AI And Accessibility

In the closing discussion, Marianna mentions that AI can help designers study, connect ideas, and simulate some user scenarios.

But she is careful about the limit: the only real user who can confirm whether something works is a human being.

So AI can support accessibility work, but it cannot replace Accessibility Testing with real people.

Main Takeaways

Accessibility is a right, not a bonus.
Autonomy is central: people should be able to complete tasks independently.
Disability can be permanent, temporary, or situational.
Accessibility improves usability for everyone.
Legal compliance matters, but law is the minimum, not the goal.
WCAG and POUR give a practical thinking model.
Designers influence accessibility through color, type, layout, labels, content, focus, forms, and handoff.
Automated checks are useful, but testing with people reveals real experience.
Accessibility should be embedded in the design system.
Inclusion is a design choice made repeatedly during the process.

How I Can Use This In My Own Work

For each UI project:

add accessibility to the brief
identify possible legal and product obligations
design color, type, and layout with accessibility from the start
test contrast and focus before high fidelity is finished
make forms predictable and forgiving
avoid placeholder-only labels and vague errors
write alt text and content rules during design, not after development
annotate accessibility decisions for developers
test with keyboard and screen reader
plan qualitative tests with real users when possible

Personal Study Questions

Which accessibility barriers could appear in my thesis project about dementia?
Where does my interface ask the user to remember something unnecessarily?
Does each form field have a permanent, clear label?
Can the interface be completed without a mouse?
Does the page still work when text is enlarged?
Are errors explained in text, not only with red color?
Which design-system tokens or components should include accessibility rules?
What can an automated tool check, and what must be tested with real people?

External Brain

Explorer

UID 07 - Principi e strumenti per l'accessibilità con Marianna Cerato