Meet Dr. Asha Mehta

Dr. Asha Mehta

Senior Lecturer, Digital Media & Communications — Northgate College

  • 52 years old; 20 years in higher education
  • Teaches a second-year unit on digital communication and online presence
  • Uses a university Windows laptop and Firefox browser, often on a ageing tablet in meetings
  • Has mild colour-vision deficiency (deuteranomaly) and relies on high-contrast text to read comfortably
  • Expects professional, navigable websites from anyone who describes themselves as a digital practitioner

The Discovery

It was a Tuesday afternoon in the middle of term, and Dr. Asha Mehta was fifteen minutes from a two-hour lecture on digital portfolios. She had been handed a student's printout with a web address scrawled in the margin: John E. Parman — creative communication practice. A colleague had recommended it as a real-world example of a practitioner building their online presence. Asha pulled it up on the projector.

The homepage loaded. The heading was there — john e. parman — and below it a subtitle in what she could only describe as "that orange." On her ageing projector bulb, the amber text against the white background simply disappeared. She leaned closer. Nothing. She could tell something was written there but could not read it. A student near the front squinted. Another asked, "Is that broken?"

"Is the text supposed to be invisible? I genuinely cannot read it." — a student, front row, out loud

Asha moved past the hero section and tried to navigate to the gallery. She clicked Gallery in the nav. The images loaded, but the captions were all either generic filenames or entirely absent. When her student Priya — who uses a screen reader — tried to explore the page later that evening to prepare an analysis piece, she found the navigation impossible. The screen reader announced "image" twelve times in a row. No context. No description. No way to skip the lengthy navigation repeated at the top of every page.

Things deteriorated when Asha switched to her tablet. The navigation bar, which had looked neat enough on the projector, crammed seven uppercase labels into a single row on her tablet screen without collapsing to a menu. Two labels disappeared off the right edge. She could not find Contact anywhere. She was on the Community page — a gallery of user drawings — and the navigation bar did not include a way to reach the contact section at all. She tapped around for two minutes before giving up.

"I'm trying to find a way to write to this person and there is literally no link to contact them on this page. This is a digital communications portfolio." — Asha, to herself, on her tablet

She closed the browser, made a note in her planner — good cautionary example, do not recommend as model — and walked into her lecture.

The Problems, Named

The site had several concrete, fixable problems — each one creating a real barrier for a real person.

Issue 1 — Colour Contrast
The orange text failed accessibility standards. The accent colour used throughout (#e67e22) produced a contrast ratio of approximately 3.0:1 against white — well below the WCAG 2.1 AA minimum of 4.5:1 for normal text. For users with colour-vision deficiency or on low-quality displays, it was effectively invisible.
Issue 2 — Missing Alt Text
Gallery images had no meaningful descriptions. Without descriptive alt attributes, screen-reader users received no information about the images. Users who rely on assistive technology to explore visual content were entirely excluded.
Issue 3 — No Skip Navigation
Every page forced keyboard and screen-reader users through the full nav on every visit. Without a skip-to-content link, Priya's screen reader had to announce all navigation items on every single page before reaching the main content.
Issue 4 — Inconsistent Navigation
The Community page and Wireframe page had no Contact link. These pages replaced the Contact item with their own page name, meaning anyone arriving at those pages could not easily navigate to get in touch.
Issue 5 — Broken Tablet Layout
The navigation expanded on tablets, causing overflow. Seven uppercase nav items at full size exceeded the available width on medium screens. Labels were cut off. The nav did not collapse to a hamburger until the phone breakpoint — too late.
Issue 6 — Mobile Hamburger Stays Open
Tapping an anchor link in the mobile menu left the menu open. On a phone, selecting About or Contact from the hamburger menu would scroll the page but leave the menu covering the content — requiring an extra tap to dismiss it.

John Gets to Work

John found out the hard way. A brief, professional message arrived in his inbox from a college email address. The sender did not introduce herself at length — she simply listed what had not worked and on what device, with the matter-of-fact efficiency of someone who grades written communication for a living. He read it twice.

He had known, in a vague way, that accessibility was something to think about. He had not known, specifically, that the orange he liked so much rendered at 3.0:1 contrast on white — until he ran his own colours through WebAIM's contrast checker and saw the red fail icon appear next to the text he used everywhere. He stared at it for a moment. Then he started a list.

"I wanted the colour to feel warm and creative. I hadn't considered that for some people it was simply absent." — John, on the contrast issue

The first fix was the colour. He kept the orange for purely decorative elements — the section divider line, the card border accent — where it carried no text meaning. For anything a user needed to read, he switched to a darker amber: #b45309, which passes WCAG AA at 5.0:1 on white. The warmth was preserved; the information was now readable.

Next came the alt text. He went through each gallery image deliberately, writing descriptions that conveyed subject, composition, and context — not just labels, but actual sentences. A photograph of a painted performance space became: "Abstract stage set with bold geometric shapes in red and yellow, photographed under theatrical lighting during a live performance." He thought about what someone who could not see the image would actually need to know.

The skip link came next — a single line of HTML at the very top of every page, visually hidden until focused, that jumped directly to the main content. Small. Invisible to most users. Invaluable to those who needed it. He added it to all six pages and tested it with keyboard navigation until it worked cleanly.

The navigation inconsistency required him to look at every page side by side. He realised that the Community and Wireframe pages had been built at different times, and when the page-specific nav items were added, nobody had checked whether Contact was still present. It was not. He added it. He also decided that seven or eight items expanding into a single row on a tablet was fundamentally unreliable, and moved the hamburger collapse point from 768px (tablets) to 992px (desktop only), so that phones and tablets always got the clean, collapsible menu.

Finally, the mobile menu behaviour. A single JavaScript listener, nine lines of code, checked whether the Bootstrap collapse was open when a link was tapped and closed it immediately. The fix took less time to write than the problem had taken Asha to describe.

Fix 1 — Contrast
Accent text colour changed from #e67e22 (3.0:1) to #b45309 (5.0:1), meeting WCAG AA for all body text.
Fix 2 — Alt Text
Descriptive alt attributes written for all gallery images, conveying subject and context.
Fix 3 — Skip Link
A visually-hidden skip-to-content link added at the top of every page, keyboard-accessible on focus.
Fix 4 — Consistent Nav
Contact link added to Community and Wireframe pages. All pages now share an identical nav structure.
Fix 5 — Tablet Layout
Changed navbar-expand-md to navbar-expand-lg. Hamburger now appears below 992px — tablets always collapse cleanly.
Fix 6 — Mobile Menu
JavaScript closes the hamburger menu immediately when any nav link is tapped, so content is visible without an extra dismiss tap.

The Return Visit

Three weeks later, Asha was preparing a new lecture — this one on iterative improvement in digital practice. She wanted a real example. She typed the address from her planner.

The page loaded. The heading was there. Below it, the subtitle in a warm, readable amber that she could see clearly — not disappeared into the white, not orange-washed by the projector, but actually there and actually legible. She scrolled. The gallery loaded. She opened her screen reader, the one she always kept installed for teaching demos, and tabbed through the images. Descriptions. Context. Sentences.

She tapped the hamburger on her tablet. The menu opened cleanly. She selected Community. The menu closed. The page loaded. She looked at the navigation bar at the top of the Community page. Contact was there.

"This is what we mean by iterative development. Someone used this, found it wanting, said so clearly, and it was made better. That is the process." — Dr. Asha Mehta, to her 9am digital media class

She added it to her lecture notes. Not as a cautionary example. As a demonstration of something rarer and more useful: a practitioner who listened, understood what had actually gone wrong, and fixed it systematically — not just aesthetically, but structurally.

She did not message John again. She did not need to. The site spoke for itself.

What this story demonstrates

  • Accessibility is not optional decoration — it determines whether real people can use a site at all.
  • Feedback from users, however uncomfortable, is invaluable — Asha's plain-spoken email was more useful than any checklist.
  • Most problems have specific, nameable causes — contrast ratios, missing attributes, wrong breakpoints — and specific, testable fixes.
  • Iterative improvement is the norm, not the exception — the site did not need to be rebuilt; it needed to be listened to and corrected.
  • A safe environment online means everyone can navigate, read, and reach you — regardless of their device, vision, or motor ability.

Meet Margaret Thornton

Margaret Thornton

Retired community arts worker, Dudley, West Midlands — aged 74

  • Had a stroke three years ago, resulting in aphasia (word-finding difficulties), right hemiplegia, and dysarthria
  • Communicates using a combination of British Sign Language (BSL) signs, a speech-generating device (AAC app on her iPad), and limited functional speech
  • Uses her iPad left-handed and relies on touch — fine motor control in her right hand is significantly reduced
  • Has attended John's 'Safternoon variety shows for several years and knows him through the local arts community
  • Wants to view the gallery images and leave a response — but needs a feedback channel that does not depend on typed text

Margaret Finds the Gallery

Margaret heard about the gallery from a friend at the last 'Safternoon — someone at her table had pulled up the site on their phone and described a photograph of the Bumble Hole nature reserve. She knew that place. She had walked there before the stroke, with her late husband. She wanted to see the image for herself.

At home, she opened her iPad and navigated to the site with VoiceOver running. The gallery page loaded. Her AAC app was quiet in her lap — she did not need it for browsing, only for speaking. She touched the first image and VoiceOver read aloud: "Two horses — one black and white, one brown — standing near a fence at Bumble Hole nature reserve." She paused. That was the right place. Those were horses she had seen from the path.

"The description told her what she was looking at before her eyes had fully processed the image — and it told her something about the person who had chosen to photograph it there."

She moved through the gallery slowly, image by image. Each descriptive alt text gave her a sentence — a subject, a location, a quality of light. For someone whose word-finding is effortful, being given the words rather than having to produce them made the experience feel open rather than exhausting. She did not need to sign to herself to understand. The page was doing the describing for her.

She wanted to respond. In BSL, she would hold her hand to her chest and open it forward — a gesture of something received, something felt. On a screen, she needed a different way to say the same thing.

The Contact Form Was Not for Her

She navigated to the contact section. The form appeared: Full Name, Email, Phone, Message. Four fields. She looked at the Message box for a long moment.

Aphasia does not prevent understanding — Margaret understood everything she read and heard clearly. What it affected was production: finding words, assembling them into sentences, typing them out one by one. The blank message box asked her to do the hardest thing she was asked to do every day, in a context where she had no support, no AAC symbol set, no one to help her shape the words before she sent them.

"A text box that says 'Message' tells an AAC user that this space was designed for someone else."

She did not try to type. She had learned, in the three years since the stroke, to recognise the difference between a door that was locked and a door that was simply heavy. The contact form was locked. She looked for another way in.

Barrier — Text-Only Feedback
The contact form accepts only typed text. For a user with aphasia, right hemiplegia, or any communication difference that makes typing difficult, a text-input-only feedback channel is effectively closed. There is no alternative modality: no audio response, no symbol selection, no drawing or image upload.
Barrier — No Multimodal Response to Gallery Images
The gallery shows images but offers no way to react to them in place. There is no "I recognise this", no reaction, no way to annotate or mark an image as meaningful — only the option to navigate away to a contact form and type a message.

The Drawing Canvas as Unexpected AAC Channel

Her grandson visited that Sunday. She showed him the gallery on the iPad and signed to him what she wanted to do. He scrolled through the navigation bar and pointed: Draw.

She had not noticed the Draw page. She opened it. A toolbar appeared with four large colour buttons — Black, Orange, Sky Blue, Green — each one wide enough to tap accurately with a single finger. A clear canvas beneath. She selected Sky Blue with her left thumb. It pressed and confirmed: the button showed a pressed state. She put her finger to the canvas.

She drew slowly. Not a picture of anything representational — a broad arc, the kind of gesture she might make in BSL to indicate something sweeping and significant. A shape that, to someone watching her hands, would mean something like this mattered. The stroke tracked her finger across the screen. When she lifted it, the line was there.

"She was not drawing a picture. She was leaving a mark. In AAC terms, that is communication."

She tapped Submit to Gallery. A moment later, her grandson navigated to the Community Gallery page. Her drawing was there — her blue arc on a white background, sitting in the grid alongside others. Small. Unhurried. Hers.

She did not type a name. She did not write a caption. She had communicated in the only way the site currently made possible for her — and it had worked, because the tool did not require words.

What already works for Margaret
Descriptive alt text on all gallery images — VoiceOver announces subject, location, and context for every photograph, removing the need for Margaret to produce language to access the content. Large, clearly labelled, touch-friendly colour buttons on the Draw page. Touch-based canvas input requiring only one functional hand. The Community Gallery accepts any mark — there is no minimum quality or legibility requirement.
What would make a meaningful difference
A BSL video response channel. The ability to record and submit a short video from the camera — without typing — would allow Margaret to respond in her primary expressive language. Equally valuable: an audio response option, symbol-based reactions on gallery images (similar to a "this resonated" button), or a simple way to flag an image as meaningful without any text input. None of these require server-side infrastructure — a short recorded video could be encoded to base64 and stored in localStorage in the same way drawings currently are.

Communication Is Not Only Text

  • AAC users include a large, diverse group — people with stroke, cerebral palsy, motor neurone disease, autism, acquired brain injury, and many other conditions use a range of augmentative and alternative communication methods. They are not an edge case.
  • Feedback must match the user's expressive modality, not only the site's preferred input — a text box is a barrier for anyone who communicates primarily through sign, symbol, image, gesture, or speech generation.
  • The Draw a Message tool is an unintentional but genuine AAC-compatible feedback channel — it accepts any mark, requires only one-handed touch, does not demand text, and places the result in a public gallery. This is worth naming and designing for explicitly.
  • Descriptive alt text is not just for screen readers — for a user with word-finding difficulties, being given language rather than having to produce it changes the entire experience of a gallery.
  • Touch-first design and AAC design overlap significantly — large targets, clear labels, one-handed operation, no time limits, no typing requirements: these are the same affordances. Designing for one benefits the other.
  • The next step is explicit design, not accidental accommodation — Margaret found a way through because the drawing tool happened to suit her. The aim should be to design feedback channels that are intentionally multimodal from the start.