Как вы, возможно, знаете, режим iOS VoiceOver предоставляет два способа навигации по элементам на экране. Один прикасается непосредственно к рамке элемента интерфейса, а другой перемещается по элементам один за другим в порядке появления, проводя пальцем влево или вправо в любом месте экрана.
Теперь в нашем приложении есть значок UITableView
с кнопкой в каждой ячейке, которая используется редко, но функционально важна.
Чтобы быстрее просматривать таблицу, наши пользователи просят нас настроить режим VoiceOver в нашем приложении таким образом, чтобы он пропускал чтение названия этой кнопки Только при навигации с помощью свайпов. Здесь нельзя использовать accessibilityElementsHidden
, так как кнопка все еще должна быть обнаружена пользователем, касающимся ее непосредственно, когда она действительно нужна. Но при навигации свайпами это должно игнорироваться программой чтения с экрана. (accessibilityElementsHidden
отключает ее для обоих режимов навигации, делая кнопку полностью недоступной для пользователей VoiceOver)
Мы просеяли UIAccessibilityTraits
но безрезультатно. Знаете ли вы способ добиться такого поведения?
@slugolicious Ага, именно это мы и решили реализовать. Этот подход должен лучше сочетаться с другими аспектами функций специальных возможностей. Спасибо за ваш вклад!
Я не думаю, что видел такое поведение — пропуск фокусируемых элементов — ни в одном приложении. Вместо этого ячейки табличного представления, в которых есть кнопки, обычно обеспечивают функциональность кнопок как "нестандартное действие". Когда VoiceOver фокусируется на ячейке, он информирует пользователя о доступных настраиваемых действиях, и пользователь может провести пальцем вверх или вниз, чтобы изменить действие, вызываемое при активации элемента/ячейки (двойным касанием).
Таким образом, одним движением будет перемещен фокус с одной ячейки на другую, а функциональность кнопок останется доступной.
Не придираться, но
"VoiceOver mode provides two ways to navigate through elements"
не совсем точно. Есть гораздо больше способов навигации, чем два, которые вы упомянули. Ротор предоставляет еще несколько — навигацию по вертикали, навигацию по кнопкам, навигацию по строкам таблицы и т. д. Сколько из них ваш пользователь хочет игнорировать? Я думаю, что это плохая идея — предполагать, что каждый пользователь VO перемещается одинаково, и вам не следует пытаться скрыть элементы, основанные на навигации по жестам. Идея @ david - лучшая альтернатива.