Предоставьте дескриптивную информацию для всех элементов

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

Во-первых, определите, включает ли данный объект доступности уже атрибут заголовка. Объект, выводящий на экран текстовый заголовок как часть его визуального интерфейса, такого как кнопка OK, уже включает атрибут заголовка со значением отображаемого текста. Такому объекту не нужен атрибут описания, потому что его заголовок достаточен, чтобы передать его цель пользователю.

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

Некоторые элементы пользовательского интерфейса не выводят на экран заголовок, но сопровождаются частью статического текста, служащего заголовком. Примером этого является ряд доступных для редактирования текстовых полей, сопровождаемых строкой «Адрес»:. зрячему пользователю близость строки к текстовым полям подразумевает что «Адрес»: служит заголовком для всего набора текстовых полей. Вспомогательное приложение, однако, не может сделать это определение. При использовании статических текстовых объектов для элементов пользовательского интерфейса заголовка (или наборы элементов пользовательского интерфейса), необходимо сделать отношение между ними ясным вспомогательным приложениям.

Чтобы сделать это, Вы создаете объект доступности представлять статический текстовый объект. Затем в каждом объекте доступности представление одного из названных элементов пользовательского интерфейса (каждое из полей адреса, в этом примере), Вы добавляете NSAccessibilityTitleUIElementAttribute атрибут. Значение этого атрибута является объектом доступности представление заголовка статического текста. Наконец, в объекте доступности заголовка статического текста, добавьте NSAccessibilityServesAsTitleForUIElementsAttribute атрибут. Значение этого атрибута является массивом объектов доступности, для которых этот статический текстовый объект служит заголовком (в этом примере, массив включает набор доступных для редактирования текстовых полей).

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

Ссылка концептуально связанные элементы

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

Если Ваше приложение включает элементы, соединяющиеся концептуально, необходимо гарантировать, чтобы объекты доступности, представляющие те элементы, включали NSAccessibilityLinkedUIElementsAttribute атрибут. Значение этого атрибута является массивом объектов доступности, с которыми соединяется элемент. Вспомогательное приложение может использовать объекты доступности в массиве для обеспечения для пользователя ярлыка между связанными объектами. Без этого атрибута должен знать пользователь, какие представления концептуально соединяются и должны продвинуться через каждый прошедший объект переместиться между ними.

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

Сделайте подструктуру доступной

Иногда, Ваше приложение использует объект представления, содержащий подструктуру, которую необходимо сделать доступным. Однако некоторые объекты NSView реализованы как монолитные объекты; объекты, что, насколько Какао затронуто, не содержат подструктуры. NSScrollBar является примером такого объекта. Даже при том, что зрячий пользователь может управлять отдельно частями полосы прокрутки (скроллер, области страницы и страницы вниз в полосе прокрутки и стрелки прокрутки), Какао не представляет эти части как отдельные объекты. Поэтому вспомогательное приложение не может сделать ни одно из этих подпредставлений непосредственно доступным пользователю. Это также влияет на определение расположения мыши и клавиатурного фокуса. Полоса прокрутки может сказать вспомогательному приложению, что имеет клавиатурный фокус, например, но не точную часть себя, который имеет клавиатурный фокус.

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

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

В большинстве случаев это работает хорошо для создания этих объектов доступности, поскольку относительно них просят; не необходимо создать и сохранить их заранее. Если пользователь не включил доступ вспомогательными приложениями в Универсальных Установках системы Доступа, это вызвано тем, что эти объекты доступности никогда не будут просить относительно (и поэтому никогда не создавать).

Ваш служебный класс должен создать пример, приведенный родительский объект доступности подпредставления и его роли. Это позволяет Вам легко обеспечивать некоторые требуемые атрибуты для нового объекта доступности. В примере NSScrollBar родительский объект является объектом доступности, который представление NSScrollBar в целом и роли NSAccessibilityScrollBarRole.

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

При реализации пользовательских классов или пользовательских подклассов классов Какао в приложении Вы, возможно, должны создать объекты доступности представлять их. Любой пользовательский подкласс NSObject, например, не наследовал поддержки доступности и должен реализовать методы, чтобы предоставить поддерживаемые атрибуты и действия и возвратить информация о тесте фокуса и тест хита.

Несмотря на то, что NSObject не принимает протокол NSAccessibility, следующие общие базовые классы делают:

• NSApplication

• NSWindow

• NSView

• NSControl

• NSCell

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

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