Products are better when they can be used by everyone.

People of all ages and from different backgrounds use Cornershop. Designing your products with accessibility in mind helps everybody use them, including people with vision, learning, or hearing disabilities.

Why Accessibility?

Designing with accessibility in mind is one of our Core Principles. Learn more about this on our User Interface section.

Getting Started

Familiarize yourself with the accessibility technologies of your development platform of choice. Take a couple of minutes to play with their accessibility settings enabled, and understand how accessibility information is conveyed to users.


On iOS, you can open the Settings app, scroll to bottom and tap Accessibility. In this screen, you’ll see settings for assistive technologies grouped by category: Vision, Hearing, Learning, and Physical & Motor.

Tap VoiceOver, and then tap the VoiceOver switch to turn it on. Using the device in VoiceOver mode is a bit different than you’re used to:

  • Tap once to select an item
  • Double-Tap to activate the selected item
  • Swipe with three fingers to scroll


For web, you should consider designing for both screen reader and keyboard users. Although they share similar considerations —therefore, can benefit from each other—, you should pay attention to different details when designing for each of them:

Keyboard Users

Keyboard users should be able to navigate through the content without a pointing device (like a mouse, trackpad, or finger). Chrome supports keyboard navigation out of the box. To enable it in Safari, go to Preferences → Advanced → Accessibility → Press Tab to highlight each item on a webpage.

Try navigating a website using your keyboard:

  • Use the Tab key to navigate to the next item
  • Use Tab + Shift to navigate to the previous item
  • Use the Enter key to trigger buttons, links, and similar actionables

There are a few actionables that can also be triggered by the space bar, or handled with arrow keys in some scenarios. Learn more

Screen Reader Users

Screen reader users should be able to understand and navigate through the content without seeing it, and without a pointing device (like a mouse, trackpad, or finger).

Your screen reader will depend on the platform you’re using to navigate the web with. Follow the steps above for iOS devices, or the ones below for other platforms.


Open Settings, Accessibility, VoiceOver, and check the Enable VoiceOver option.


Windows 10 and above includes a built-in screen reader called Narrator, but most screen reader users will probably use NVDA or JAWS. Find more information and download links for each of them in their websites:

Accessibility Attributes

When adapting your product to be accessible, you’ll need to pay attention to some properties that can be configured on your user interface elements:

  • Label: A concise way to identify the control or view. Some examples are “Back button” and “Product image”.
  • Traits: These describe the element’s state, behavior or usage. A button trait might be “is selected”.
  • Hint: Describes the action an element completes. For example: “Displays the order detail”.
  • Value: The value of an element. For example, with a progress bar or a slider, the current value might read: “3 out of 5”.

When using system-provided controls for your user interface, the system will provide these attributes for you. When creating custom controls, you’ll need to supply most of these attributes yourself.


If you provide a custom control on your user interface, or if you display a custom icon or image in a standard control, you need to provided a label that:

  • Very briefly describes the element. Ideally, the label consists of a single word, such as Add, Play, Delete, Search, Favorites, or Volume.
  • Does not include the type of the control or view. The type information is contained in the traits attribute of the element and should never be repeated in the label.
  • Begins with a capitalized word. This helps VoiceOver and other screen readers to read the label with the appropriate inflection.
  • Does not end with a period. The label is not a sentence and therefore should not end with a period.
  • Is localized. The screen reader speaks in the language that the user specifies in their settings, so labels must be localized accordingly.


Hints describe the results of performing an action on a control. You should provide a hint only when the results of an action are not obvious from the element’s label.

  • Very briefly describes the results. Even though few controls need hints, strive to make the hints you do need to provide as brief as possible. Doing so decreases the amount of time users must spend listening before they can use the element.
  • Begins with a verb and omits the subject. Be sure to use the third-person singular declarative form of a verb, such as “Plays,” and not the imperative, such as “Play.” You want to avoid using the imperative, because using it can make the hint sound like a command.
  • Begins with a capitalized word and ends with a period. Even though a hint is a phrase, not a sentence, ending the hint with a period helps VoiceOver and other screen readers speak it with the appropriate inflection.
  • Does not include the name of the action or gesture. A hint does not tell users how to perform the action, it tells users what will happen when that action occurs.
  • Does not include the name of the control. The user gets this information from the label attribute, so you should not repeat it in the hint.
  • Is localized. As with accessibility labels, hints should be available in the user’s preferred language.


Accessibility traits describe a set of traits that characterize how a control behaves or should be treated. This is specially critical if you are using custom controls, or have taken liberties with non-standard use of a standard control.

Examples include distinctions like: Button, Link, Search Field, Image, Not Enabled, Selected, None.


Accessibility value corresponds to the content of a user interface element. For a label, the value is its text. For a slider, it’s the current numeric value represented by the control.

Values aren’t limited to controls. For example, if you had a list that showed status updates, you might set the accessibility label to “Update from ${Person name}”, and the accessibility value to the content of that status update.

Design Criteria

This is a guide of different accessibility criteria for enabling an accessible user interface. Each criterion includes an implementation checklist that must be met for your user interface elements.


Some users, especially those with visual impairments, won’t be able to access information included in images. Consider this during development if your design contains images.

By default, images are not vocalized by screen readers. If the image contains text, text must be used as an accessibility label. Exceptions are images used for decorative purposes.


Example of adding an accessibility label to an image

This button contains a logo image that can’t be read automatically by the screen reader. Also, because no accessibility text was added to the button, two vocalizations will read “Image” and then “In 60 minutes”.

The issues are fixed by adding a custom accessibility label to the button that includes the store name, and the delivery time.


  • Images with information must convey this information through an accessibility label.
  • Decorative images have no alternative text.


Allow users who cannot distinguish colors or sensory information to access the same information by other means. All people, even those without visual impairments, can have momentary periods of difficulties reading (for example, when outdoors and on bright environments).

During the design phase of your product, ensure elements are easy to read by everybody. Always ensure controls have a correct amount of contrast, specially for text at the lowest font sizes. Also check that color isn’t the only way to distinguish elements—use other means, like shapes, so users can tell different elements.


Example of using legible colors

The title label doesn’t have enough contrast. It’s not legible for most users. Also, adding just a color to represent the order status isn’t enough—some users be colorblind or have problems perceiving colors.

Picking colors with more contrast and adding a status label fixes these issues.


  • Do not use colour as the only way of conveying information, indicating an action, requesting a response or distinguishing an element.
  • The contrast between the colour of the background and the text must be appropriate.
  • Since the introduction of Dark Mode as a system-feature on most platforms, special attention must be paid to the contrasts used in the different themes and configurations.


When using custom icons not provided by the system, your user interface won’t be read correctly by VoiceOver and other screen readers. Provide access to the icon’s meaning and information by adding an accessibility label and hint (if needed).


Example of adding an accessibility label to a button

This is a common example of an icon associated with a text (or badge) used to convey information. In this case, the “Cart” icon is associated with the “3” in the badge make users understand that we have “3 products in the Cart”.

In no accessibility text is added, two vocalizations will read “Unlabeled button” and “3”. This is terrible. The accessibility label for this element should be “Cart with 3 added products”.


  • Elements that require an accessibility label should have one.
  • The alternative text must be clear and understandable.

Titles and Headers

Allow users to identify the topic of a page and to get a clear idea of its contents without having to read it. The title is the first element vocalized or seen on a screen. It makes navigation easier for all users: Everyone should be able to tell where they are in your product.

Use standard or system-provided navigation patters or if you have taken liberties with non-standard elements, add the correct accessibility traits.


Example of adding accessibility traits to a header

When using a screen reader, users expect a vocalization of the screen title to understand where they are in the navigation.


  • Each screen must have its own title allowing users to know where they are in the product’s navigation.
  • Elements identified as headers must be declared with header accessibility traits for assistive technologies.

Element States

Allow screen readers like VoiceOver access element information, status, and nature so they can be used without difficulties. If an element fails to convey its status or state, these users will be unable to understand what’s happening on the screen.

A common mistake is not specifying that an element is unfolded or selected. Add the correct accessibility traits so elements can be vocalized correctly.


Example of adding accessibility traits to a view

Any item whose selection changes when interacting with it must vocalize its state through its accessibility traits. In this example, the cell will be read as “Plants section, Selected”.


  • Elements must be reflect their state by updating their accessibility traits and label.

Touch Targets

Improve the user experience by implementing comfortable touch targets for your user interface. Everybody will benefit from these improvements, but specially people with motor impairments or those who have difficulties to make selections on the screen.

When your design consists of elements of reduced size, consider enlarging the touch area beyond the bounds of the element. If a touch target of an element is too small, it can prevent users from interacting with it.


Example of improving a touch target

In the correct example the touch area extends beyond the bounds of the button. Without this change, the user interface may appear unresponsive when users fail to interact with the button.


  • Ensure a minimum touch target size of 44pt for all elements.
  • When displaying content in a table, consider making the whole cell selectable.

Ghost Elements

Even if the presented user interface of your product may appear visually correct, screen readers like VoiceOver may have issues detecting and vocalizing what’s currently visible on the screen.

During development, ensure that elements positioned outside of the visible area or hidden by other elements are not vocalized. The superposition of screen frequently generates problems if it’s not properly done (for instance, by implementing your own presentation code).

If possible, use system-provided elements and mechanisms to present content modally.


Example of improving a touch target

In the example, a custom alert was implemented. When the screen reader is activated, it vocalizes the content behind the current view instead of the alert.


  • When using a screen reader, no invisible element must be read or take focus when reading the user interface.

Changing Content

If the content changes dynamically after a user action, it is important to ensure the new content triggers a vocalization. Without any voice feedback, the user doesn’t know that the content has changed.

It’s also important to avoid noise pollution. This is critical when running a timer or any other refreshing mechanism. The user must be in control of their screen reader at all times, and having constant vocalizations may prevent them from performing actions.


Example of improving a touch target

Even as the screen updates visually, the screen reader may not trigger a vocalization of the updated content.


  • With a screen reader like VoiceOver, make sure that dynamic changes are vocalized.
  • The user must be in control at all times—be sure to not interrupt users with repeated vocalizations.

Horizontal Scroll

Provide affordances that indicate content can be scrolled when there is horizontal scrolling. It can be very difficult for users if there’s no visual cues to help them understand that there’s more content or pages.

Make it obvious by having content clipped in a controlled way, or by having a control that indicates pages (like a page control). When necessary also add “Next” and “Previous” buttons.


Example of adding affordances to a horizontal scrolling list

Without clipping the content in a controlled way, users may not tell there are several more items to scroll to.


  • Content that has horizontal scrolling is properly visually indicated.
  • It must be possible to scroll or switch pages when using a screen reader like VoiceOver.

Reading Order

Ensure there’s a logical order and coherent reading of elements for screen reader users. People with visual impairments won’t get the visual clues and hierarchy of elements from your design.

During development, the default reading order of voice synthesis must be tested. It’s possible that default order will need to be redefined.


Example of an incorrect reading ordering

In the example, the screen reader will follow a left-to-right ordering by default that’s not suited for the interface. It reads as:

Divide, 7, 8, 9, Multiply, 4, 5, 6, Minus, 1, 2, 3, Add, 0, Equals

A more consistent reading order would include all numbers and then all math operations.


  • The traversal order of elements must be logical and coherent.

Screen Orientations and Sizes

The screen orientation or the size of their screen shouldn’t impact on the ability of your product on displaying content. Users should be able to use the your product in any screen orientation or screen configuration.

When developing for iOS or Android, provide implementations for both the portrait and the landscape modes. Exceptions to this requirement must be justified on some functional constraint. Also consider testing application resizing behavior on iPad, if applicable.


Example of adapting to any screen orientation

Adapt your user interface so users won’t need to adjust their device’s orientation or settings when using your product.


  • Your design should consider adapting to different sizes and orientations.
  • Consider describing the way transitions are handled on your design when content may be not present when going from one orientation or size to another.

Honor accessibility options

Users can greatly improve their experience by enabling some accessibility options on their devices.

During development, it’s primordial to understand these options and their impact. It’s also appropriate to test each available option so that their purpose is reflected inside your product.

Some of the included options on iOS are:

  • Dynamic Type
  • Increase Contrast
  • Bold Text
  • Reduce Motion
  • Reduce Transparency
  • Shake to Undo
  • Speak Screen & Speak Selection
  • Switch Control
  • VoiceOver
  • Auto-Play Video Previews
  • Differentiate Without Color
  • On/Off Labels


Example of adapting to dynamic text sizing

The system provides additional flexibility by letting users choose their preferred text size. The layout is adjusted so bigger labels can fit on the screen.


  • Test every option state and make sure your user interface adjusts accordingly to provide the best possible user experience.
  • Be sure your user interface doesn’t need a relaunch or reloading for changes to take effect.