1

I'm building a detailed accessibility spec for an iOS input field component for a design system. I want to outline in the spec how voiceover should work.

The design system needs an input field that looks more like a traditional web or Material input, with a box around the input itself, which iOS doesn't seem to offer natively.

I know I want the voiceover to say, but I'm uncertain how to relate those to the correct accessibility attributes, like "accessibilityLabel".

ON FOCUS:

  • [Read label] (accessibilityLabel)
  • [Read entered value if any, or placeholder text, if any] (accessibilityValue, but what about placeholder?)
  • [Read hint text, or error text, if present] (?)
  • "Text field" (accessibilityRole)
  • "Double-tap to edit" (accessibilityHint)

ON EDIT:

  • [Read entered value, if any] (accessibilityValue)
  • "Character mode insertion point at [start/end]" (accessibilityHint?)
  • "Use rotor to access misspelled words" (accessibilityHint?)

How does placeholder text translate? Am I mapping these correctly? How specific do I need to be? Is this overkill? Am I missing something?

Improve this question

1 Answer 1

Reset to default
1

This is becoming an important aspect of design documentation as more and more projects are required to comply with accessibility guidelines.

Stephanie Walter has written about this in her blog in the article A Designer’s Guide to Documenting Accessibility & User Interactions, which gives a good overview and helps you decide what is suitable for your project.

There are also various templates available in Figma and elsewhere that will give you an idea of what accessibility specification can look like in practice.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.