Связь с клиентом доступности

Чтобы быть доступным, приложение должно предоставить информацию клиенту доступности о ее пользовательском интерфейсе и возможностях. Существует три различных способа, которыми взаимодействуют приложения и клиенты доступности (см. рисунок 3-1).

• Информационные свойства. NSAccessibility протокол определяет много свойств, предоставляющих информацию о Вашем представлении или управлении. Если Вы работаете с подклассом стандартного представления AppKit или управления, можно или установить желаемое свойство или переопределить его методов get и методы set. По умолчанию переопределяющий только метод get говорит клиенту доступности, что это имеет доступ только для чтения к свойству. Переопределение метода set говорит клиенту доступности, что также имеет доступ для записи к свойству.

• Методы действия. NSAccessibility протокол также определяет много методов, моделирующих нажатия кнопки, щелчки мышью и выборы в Вашем представлении или управлении. Путем реализации этих методов Вы предоставляете клиентам доступности возможность управлять Вашим представлением или управлением.

• Уведомления. Ваше представление или управление, возможно, должны позволить клиенту доступности знать, что произошли изменения. Константы в Неофициальной Ссылке на протокол NSAccessibility определяют много уведомлений, что можно отправить использование NSAccessibilityPostNotification метод. Эти уведомления не включены в специфичные для роли протоколы; однако, стандартные средства управления AppKit уже отправляют надлежащие сообщения за своими стандартными образцами использования. Когда Вы используете стандартное управление нестандартным способом, обычно необходимо отправлять собственные уведомления только при создании пользовательского элемента управления или.

Несмотря на то, что включение доступа, которым представление или управление могли бы звучать Вам как большая работа, это фактически довольно просто. При использовании стандартных средств управления AppKit большая часть работы была выполнена для Вас. Как правило, включение доступа эти средства управления является вопросом подстройки значений по умолчанию, сохраненных в информационных свойствах. Для получения дополнительной информации об использовании стандартных средств управления AppKit посмотрите Улучшение Доступности Стандарта Средства управления AppKit.

При использовании пользовательских представлений или средств управления необходимо добавить надлежащие информационные свойства, методы действия и уведомления. К счастью, доступность, API включает широкий диапазон специфичных для роли протоколов, ведущих Вас через шаги, необходимые для доступа - включает Ваши представления и средства управления. Для получения дополнительной информации посмотрите Доступность Реализации для Пользовательских элементов управления.

Иерархия доступности

Модель доступности OS X представляет пользовательский интерфейс приложения как иерархию доступных элементов. По большей части иерархия определяется отношениями отцов и детей. Например, диалоговое окно приложения могло бы содержать несколько кнопок. Доступный элемент, представляющий диалоговое окно, содержит список дочерних доступных элементов, каждый представляющий кнопку в диалоговом окне. В свою очередь, каждая кнопка знает, что ее родитель является доступным элементом, представляющим диалоговое окно.

Конечно, доступные элементы, представляющие строку меню и окна в приложении, являются дочерними элементами прикладного уровня доступный элемент. Даже доступный элемент прикладного уровня имеет родителя, который является доступным элементом в масштабе всей системы. Приложение никогда не должно волноваться о его родителе в масштабе всей системы, потому что это вне объема приложения. Однако клиент доступности мог бы запросить доступный элемент в масштабе всей системы для обнаружения, какое запущенное приложение имеет клавиатурный фокус.

Рисунок 3-2 показывает иерархию доступных элементов в простом приложении.

Сила доступной иерархии элемента - то, что она может не учесть специфичные для реализации подробные данные, которые не важны клиенту доступности и, расширением, пользователю. Например, в Какао, кнопка в окне обычно реализуется как ячейка кнопки в кнопочном управлении, которое находится в довольном представление в окне. У пользователя нет интереса к этой подробной иерархии вместимости; она только должна знать, что существует кнопка в окне. Если иерархия доступности приложения содержит доступный элемент для каждого из этих промежуточных объектов, однако, у клиента доступности нет выбора, кроме как представить их пользователю. Это приводит к плохому пользовательскому опыту, потому что пользователь вынужден предпринять несколько шагов для получения от окна до кнопки. Рисунок 3-3 показывает, как могла бы посмотреть такая иерархия наследования.

Для исключения этой ненужной информации доступность, API позволяет Вам указать, что должен быть проигнорирован объект. Когда Вы устанавливаете доступный элемент accessibilityElement свойство к NO, клиенты доступности игнорируют его. NSView наборы это свойство к NO по умолчанию, потому что пользователи обычно не интересуются представлением, они только хотят знать о содержании представления.

Возможность скрыть элементы позволяет приложению представить только значительные части пользовательского интерфейса клиенту доступности. Рисунок 3-4 показывает, как та же иерархия, показанная на рисунке 3-3, могла бы быть представлена клиенту доступности.

Доступность клиенты также помогает пользователю выполнить задачи, говоря доступным элементам выполнить действия. По большей части действия соответствуют вещам, которые пользователь может сделать единственным щелчком мышью. Каждый доступный элемент реализует методы действия, соответствующие действиям, которые он поддерживает, если таковые имеются. Например, доступный элемент, представляющий кнопку, поддерживает действие нажатия. Когда пользователь хочет нажать кнопку, он передает это клиенту доступности. Клиент тогда определяет, реализует ли доступный элемент кнопки accessibilityPerformPress метод. Если это делает, клиент доступности вызывает этот метод.

Протокол NSAccessibility определяет только ряд действий, которые могут поддерживать доступные элементы. Сначала, это определение могло бы казаться строгим, потому что приложения могут выполнить огромные числа задач. Важно помнить, однако, что клиент доступности помогает пользователю управлять пользовательским интерфейсом их приложения, это не моделирует функции приложения. Поэтому у клиента доступности нет интереса в том, как Ваше приложение реагирует на нажатие кнопки, например. Его задание должно сказать пользователю, что кнопка существует и сказать приложение, когда пользователь нажимает кнопку. Это до Вашего приложения для надлежащего ответа на то нажатие кнопки, как это было бы, если пользователь щелкнул по кнопке с мышью.

Пример доступности

Этот пример описывает, как фиктивная программа экранного доступа с возможностью распознавания речи и синтеза речи могла бы связаться с Вашим приложением:

1. Пользователь говорит, “Открытое окно Preferences”.

2. Программа экранного доступа отправляет сообщение в доступный элемент приложения, прося ссылку на строку меню у доступного элемента. Это тогда запрашивает строку меню для списка ее дочерних элементов и запрашивает каждый дочерний элемент для ее заголовка. Как только это находит тот, заголовок которого соответствует имя приложения (т.е. меню приложения). Вторая итерация позволяет ему найти элемент Меню свойства в меню приложения. Наконец, программа экранного доступа говорит элементу Меню свойства выполнять действие нажатия.

3. Приложение открывает окно Preferences, и окно отправляет уведомление, широковещательно передающее, что новое окно теперь видимо и активно.

4. Программа экранного доступа запрашивает окно для своего списка дочерних элементов.

5. Для каждого дочернего элемента программа экранного доступа запрашивает метку дочернего элемента, роль, ролевое описание и дочерние элементы.

6. Среди ответов программа экранного доступа узнает, что область содержит несколько дочерних элементов (например, три кнопки).

7. Программа экранного доступа запрашивает каждую кнопку, прося следующее:

   • Метка (значения по умолчанию к заголовку кнопки)

   • Роль (button в этом случае)

   • Ролевое описание («кнопка»)

   • Значение (ни один в этом случае)

   • Дочерние элементы (ни один в этом случае)

8. После того, как программа экранного доступа определила, какие объекты доступны, она сообщает эту информацию пользователю, использующему синтез речи.

9. Пользователь мог бы тогда спросить для получения дополнительной информации об одной из кнопок.

10. Программа экранного доступа запрашивает указанную кнопку для своего текста справки. Это сообщает об этой строке пользователю, использующему синтез речи.

11. Пользователь тогда говорит программе экранного доступа активировать кнопку.

12. Программа экранного доступа отправляет сообщение нажатия в кнопку.

13. Широковещательные сообщения приложения любые уведомления, инициированные вследствие изменений, сделаны нажатием кнопки.