Отправляет email-рассылки с помощью сервиса Sendsay

[TC] Требования по невизуальной доступности прикладной программы.

Здравствуйте, все!

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

Сам понимаю в этом весьма слабо, вопрос может звучать дурацки, и все же:

если среди этих норм (требований, условий) те, которые являются
обязательными?

Насколько зависит (если зависит) их перечень от среды разработки?

Напр. есть ли что-то специфичное, для VBA?

За корявость простите, просветившим - большое спасибо.

С уважением: Станислав.

Ответить   Sun, 28 Jan 2018 11:18:31 +0200 (#3544399)

 

Ответы:

Привет Станислав!
ц
Подскажите, где можно прочитать-скачать набор требований к невизуальной
доступности программы, который включается в тех.задание для разработчика.
если подобное есть, то я о таком не слышал.
и очень сильно сомневаюсь что некий написанный свод правил что то даст на
выходе путное.
на винде:
если вспомнить о проектах в которых доступность была толково реализована, то
зачастую в команде разработчиков был незрячий программер,
который и занимался конкретной озвучкой органов управления или давал
рекомендации по интерфейсу.
(к примеру, audacity или консультант+)
естественно не берутся в расчёт простые программы, написаные на стандартных
контролах MFC.
там доступность реализована через MSAA и в целом всё хорошо.
сейчас же на дворе год 2018 и во всю по планете идёт UIA.
и как показывает практика, иногда что то озвучивается более менее,
, а зачастую опять таки незрячие программеры вооружаются скриптовым языком
или com технологией и начинают доозвучивать то что вроде как и так озвучено
по всем канонам микрософта.
собственно почему я оч сомневаюсь что правила есть, а если есть, то
сомневаюсь что они сработают как надо.
на маке озвучка в ещё большей степени зависит от разработчика программы.
могу ещё добавить что когда пишу проги даже на MFC, то переодически
приходится в некоторых контролах делать вывод строки с пояснениями или
прочей информацией прямо на скринридер.
т.е. можно порекомендовать программеру максимальное применение стандартных
контролов в которых уже реализованы accessiblity технологии такие как MSAA и
UIA
в частности фреймворков MFC и наверное новейшие QT,
хотя видел я проги написанные на QT 5.4 там проблем почти всегда
предостаточно.
и даже сам собирал из исходников:
гитарный проц стал озвучиваться в плане списков, кнопок и деревьев, но
большая часть интерфейса хоть и стала видна, но только в JAWS курсоре.
анаологично и с MFC:
пока применяешь набор из примерно полсотни контролов типа ListBox,
ListView, Button и т.д.
вроде неплохо, но как только включаешь расширненный набор классов, то
ситуация осложняется.
ещё стоит на различные действия назначать горячки, и присваивать контролам
уникальные ControlId, имена и классы.
и реализовывать переходы к органам управления по tab и shift Tab.
это очень сильно облегчит дальнейшую скриптовку.
а что то скринридер в этом случае подхватит автоматом.
кстати, список контролов, озвучивающихся неплохо можно посмотретть в JAWS по
Insert 7
т.е. при переназначении классов.
но даже такой стандартный контрол как
RadioButton
можно написать так что он курсорами переключается и фокус при табулировании
переходит к отмеченной кнопке,
а можно и не сделать.
ну и естественно всё очень сильно зависит от конкретного языка, среды
разработки и фреймворка.

Виктор Горелов

Ответить   Sun, 28 Jan 2018 13:40:14 +0300 (#3544406)