DEV Community: Ilknur Eren

Getting started with iOS VoiceOver: a beginner's guide

Ilknur Eren — Sun, 13 Sep 2026 02:48:37 +0000

VoiceOver is the screen reader built into every iPhone and iPad. If you build, design, or test anything that runs on an iPhone, you should know how to use it. Testing your apps with VoiceOver will be the one of the best ways to find out whether the your app or website is accessible.

This guide walks you through the common gestures.

First, the set up

Before you turn VoiceOver on, give yourself a quick way to turn it off. How you interact with the phone will change. When you're new, it's easy to feel stuck once the gestures change.

Go to Settings > Accessibility > Accessibility Shortcut.
Choose VoiceOver.

Now you can turn VoiceOver on or off by triple-clicking the side button (or the Home button on older phones). If you get lost, three clicks and you're back to no VoiceOver mode.

Once VoiceOver is on your relationship with the screen changes.

Practice in a safe sandbox

Every beginner should spend a few minutes in VoiceOver Practice. Go to Settings > Accessibility > VoiceOver and tap VoiceOver Practice. (The button only appears while VoiceOver is on.)

It opens a blank screen where you can tap, flick, and swipe freely. The phone says which gesture it detected, without changing any settings. It's the perfect place to learn the Magic Tap, a two-finger double-tap that starts or stops music and answers or ends calls, before you try it in the real world.

Select first, then double-tap

In VoiceOver mode, your finger explores. A single tap doesn't open an app. Instead, it draws a thick black border around the item (the VoiceOver cursor) and the phone speaks its name aloud.

Once you hear the item you want, you activate it with a double-tap. But you don't have to hit the icon itself twice. Once the black border is on an item, you can double-tap anywhere on the screen to "click" it.

Think of it this way:

One tap looks at the button.
Double-tap presses the button.

Separating selection from activation is what keeps you in control, even when you can't see the screen.

Flick to move through the screen

To move from item to item, flick one finger to the right. The cursor jumps to the next item and reads it aloud, like turning the pages of a book. Flick left to go back.

Flicking is faster than dragging your finger around. It also shows you something important as a developer: the order VoiceOver reads things in. If the focus order jumps around or skips a control, your users will notice.

Scroll with three fingers

Since a one-finger swipe now moves between items, scrolling needs more fingers. To scroll a long list or a webpage, swipe up or down with three fingers. It feels a bit like pushing the page away.

When you reach the top or bottom of a list, the phone plays a low "thump" sound. That's how you know there's no more content.

Conclusion

Automated accessibility checks catch missing labels. They don't catch a button that reads as "button," a focus order that makes no sense, or a custom control that VoiceOver can't reach at all. Only a real screen reader shows you that.

So the next time you're about to mark a ticket done, turn VoiceOver on and try the flow yourself. Ten minutes of testing will teach you more than any checklist.

My CPACC journey

Ilknur Eren — Sat, 25 Jul 2026 14:42:26 +0000

The Certified Professional in Accessibility Core Competencies (CPACC) is a credential offered by the International Association of Accessibility Professionals (IAAP). It is designed for people who work in or around accessibility, engineers, designers, and others.
The exam covers three broad areas: disabilities, accessibility and universal design, and accessibility standards and laws.

Why I decided to take it

I have spent most of my career as an engineer with a focus on accessibility. I write code. I help teams build things that work for everyone. I write articles educating on accessibility standards. I knew the WCAG guidelines and semantic HTML. I knew how to test with a screen reader. I live and breathe accessibility.

Taking the CPACC felt like a chance to solidify the years of accessibility work.

What studying actually looked like

I spent several months preparing for the exam last year. I worked through the IAAP Body of Knowledge, read research, and took practice tests. I watched youtube tutorials and completed the CPACC prep course offered by Deque University.

The technical material felt familiar at first. Assistive technology, accessibility standards, barrier types, I had touched most of this on m. But the exam goes deeper than surface familiarity. I had to understand how different types of assistive technology work, not just that they exist.

The history and policy sections were where things really opened up for me. Studing for the CPACC exam, I realized how much context I had been missing.

The exam itself

The CPACC test covers a wide range of topics. Some questions put you in real-world scenarios and ask you to apply what you know. Others test precise definitions and legal details.

I felt prepared walking in, and the exam still challenged me. That is a good thing. A credential that is easy to get is not worth much.
After months of studying, I passed. I am now a CPACC certified engineer.

But more than the credential, I walked away with a broader view of accessibility. I understand more about the lived experiences of people with disabilities. I understand more about the assistive technologies they rely on, the legal and policy frameworks that shape what companies are required to do — and what they should do even when they are not required to.

That last part matters. Requirements set a floor. Good accessibility work aims higher.

Keeping the certification

The CPACC is not a one-time achievement. Like many professional credentials, it requires ongoing education to maintain. it requires attending accessibility conferences, taking courses. I need to earn continuing education credits to keep my certification active.

Honestly, I see that as a feature. Accessibility is a living field. Standards evolve. Technology changes. New research shapes best practices. Staying certified means staying current.

Should you take it?

If you work in accessibility, I think the CPACC is worth pursuing. Not just for the credential, but for what the process of studying teaches you.

Technical skills alone are not enough to do this work well. You need context. You need history. You need to understand the people your work is meant to serve.

The CPACC exam pushed me toward all of that. I truly feel like I am a better engineer because of it.

Accessible Form Labels

Ilknur Eren — Sat, 11 Jul 2026 00:00:15 +0000

Labels are a foundational part of any accessible form. Without properly implemented, users who rely on screen readers have no way to understand what a field is asking for. A label does two things: it tells the user what a field is for, and it connects that meaning to the input in the code so assistive technology can announce it. There are a number of basic form label accessibility rules all developers should follow to build accessible forms.

Use the `<label>` element

Every input needs a visible, programmatic label. The most reliable way to label an input is with the HTML element, linked to the input using matching for and id attributes. Example is below:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

In the example above, the first line is the label of the form field. With the proper for and id, we can programmatically link the tag to the tag. Additionally to linking the label, when the for and id values match, clicking or tapping the label text also moves focus to the input.

When a visible label isn't practical

Some designs use a search bar with a button, or a compact inline form, where a visible label would feel visually cluttered. In those cases, use aria-label or aria-labelledby to provide a label programmatically without showing it visually.

<!-- aria-label: attach a label string directly to the input -->
<input type="search" aria-label="Search the site">
<!-- aria-labelledby: point to an existing element on the page by its id -->
<h2 id="signup-heading">Create your account</h2>
<input type="email" aria-labelledby="signup-heading">

Use aria-labelledby when label text already exists on the page. It references that text by id, so screen readers announce it without duplication.

Placeholder text is not a label

This is one of the most common labeling mistakes. Placeholder text disappears the moment someone starts typing, screen readers don't reliably announce it as label text, and its low contrast often fails WCAG minimums. It can hint at expected format (like "MM/DD/YYYY"), but it must never stand in for a real label.

<!-- Wrong: no label, placeholder only -->
<input type="text" placeholder="Full name">
<!-- Right: visible label + placeholder as a format hint -->
<label for="dob">Date of birth</label>
<input type="text" id="dob" name="dob" placeholder="MM/DD/YYYY">

Marking required fields

If a field is required, mark it in two ways: in the code and in the visible label.
Add required (or aria-required="true") to the input so assistive technology announces it. Then add visible text — like "(required)" — next to the label so sighted users also see it.

<label for="name">Full name (required)</label>
<input type="text" id="name" name="name" required>

A red asterisk alone is not sufficient. Screen readers may not announce it, sighted users may not know what it means without a legend, and color alone never conveys meaning in an accessible way. If you do use an asterisk, include a visible legend near the top of the form — for example, "Fields marked with * are required" — and wrap the asterisk in so screen readers skip it and rely on the required attribute instead.

<p>Fields marked with <span aria-hidden="true">*</span> are required.</p>
<label for="phone">Phone number <span aria-hidden="true">*</span></label>
<input type="tel" id="phone" name="phone" required>

Keep labels close to their inputs

Sighted users scan forms by proximity. Labels should appear directly above or immediately to the left of their input, not below and not far away. This also helps users who zoom in on a page, since distant labels may scroll out of view.

Label groups of related inputs

For radio buttons, checkboxes, and other grouped inputs, use

<fieldset> and <legend> to label the group as a whole. Each individual option still needs its own <label>.
html
<fieldset>
  <legend>Preferred contact method</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">Email</label>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>

Without <fieldset> and <legend>, a screen reader user hears "Email, radio button" with no context about what they're choosing.

Conclusion

Accessible forms are not an edge case or a nice-to-have, they are a baseline requirement. The labeling practices covered in this article are some of the most impactful changes you can make, because labels are the foundation everything else builds on. A form without proper labels fails before a user even has a chance to fill it out.