Для обучающихся с нарушениями зрения наличие компьютерной техники, используют систему Брайля (рельефно-точечного шрифта), электронных луп, видеоувеличителей, программ невизуального доступа к информации, программ — синтезаторов речи и других технических средств приема-передачи учебной информации в доступных формах.
Компьютерные тифлотехнологии базируются на комплексе аппаратных и программных средств, обеспечивающих преобразование компьютерной информации в доступные для незрячей и слабовидящей формы (звуковое воспроизведение, рельефно-точечный или укрупненный текст), и позволяют им самостоятельно работать на обычном персональном компьютере с программами общего назначения.
Для слабовидящих обучающихся в лекционных и учебных аудиториях предусмотрена возможность просмотра удаленных объектов (например, текста на доске или слайда на экране) при помощи видеоувеличителей для удаленного просмотра.
Оборудование для обучающихся с нарушениями опорно-двигательного аппарата:
· Выносная компьютерная кнопка
Программа для родительского контроля бесплатно
· Клавиатура для людей с ОВЗ
· Клавиатура с большими кнопками и накладкой
Для обучающихся с нарушениями опорно-двигательного аппарата используется компьютерная техника со специальным программным обеспечением, адаптированной для лиц с ограниченными возможностями здоровья, альтернативных устройств ввода информации и других технических средств приема-передачи учебной информации в доступных формах.
Для обучающихся с нарушениями опорно-двигательного аппарата использование альтернативных устройств ввода информации.
Используются специальные возможности операционных систем, таких как экранная клавиатура, с помощью которой можно вводить текст, настройка действий при вводе текста, изображения с помощью клавиатуры или мыши 5.4. Требования к организации практики обучающихся инвалидов и/ или обучающихся с ограниченными возможностями здоровья
Практика является обязательным разделом образовательной программы. Она представляет собой вид учебных занятий, непосредственно ориентированных на профессионально-практическую подготовку обучающихся, в том числе обеспечивающую подготовку и защиту выпускной квалификационной работы. При инклюзивном образовании реализуются все виды практик, предусмотренные в соответствующем ФГОС СПО.
Оборудование предприятий и технологическое оснащение рабочих мест производственной практики должно соответствовать содержанию деятельности и давать возможность обучающемуся овладеть профессиональными компетенциями по всем осваиваемым видам деятельности, предусмотренным программой с использованием современных технологий, материалов и оборудования.
Для инвалидов, лиц с ОВЗ форма проведения практики устанавливается колледжем с учетом особенностей психофизического развития, индивидуальных возможностей и состояния здоровья.
При определении мест прохождения учебной и производственной практики обучающимся, имеющим инвалидность, колледж учитывает рекомендации, данные по результатам медико-социальной экспертизы, содержащиеся в индивидуальной программе реабилитации инвалида, относительно рекомендованных условий и видов труда. При необходимости для прохождения практики создаются специальные рабочие места в соответствии с характером нарушений здоровья, а также с учетом профессии, характера труда, выполняемых инвалидом трудовых функций.
Что нового в программе экранного доступа JAWS 2021 | Тифлообзор 31
5.5. Характеристика социокультурной среды образовательной организации, обеспечивающей социальную адаптацию обучающихся инвалидов и обучающихся с ограниченными возможностями здоровья.
— основные виды сопровождения учебного процесса инвалидов и лиц с ограниченными возможностями здоровья (организационно-педагогического, психолого-педагогического, профилактически- оздоровительного, социального и др.);
— возможности участия обучающихся инвалидов и обучающихся с ограниченными возможностями здоровья в студенческом самоуправлении, в работе, общественных организаций, спортивных секциях и творческих клубах;
— возможности участия обучающихся инвалидов и обучающихся с ограниченными возможностям в олимпиадах и конкурсах профессионального мастерства.
[1]Приказ Министерства труда и социальной защиты Российской Федерации от 29 сентября 2014 г. № 667н «О реестре профессиональных стандартов (перечне видов профессиональной деятельности)» (зарегистрирован Министерством юстиции Российской Федерации 19 ноября 2014 г., регистрационный № 34779).
Источник: cyberpedia.su
ТОП мобильных приложений для слабовидящих и незрячих людей
Фото: с ferra.ru
13 ноября ежегодно отмечается Международный день слепых. По такому случаю мы решили сделать небольшую подборку мобильных приложений, которые облегчают жизнь слабовидящих и незрячих людей.
Помогает добраться до нужного пункта назначения
Nav by ViaOpta — помогает добраться до нужного пункта назначения с помощью голосовой пошаговой навигации. Приложение было разработано в сотрудничестве с пользователями с нарушениями зрения медицинской корпорацией Novartis.
Для повышения точности маршрута можно добавлять на карту промежуточные точки. В любое время можно уточнить местонахождение, оставшееся расстояние и получить описание пересекающих маршрут улиц. Nav by ViaOpta озвучивает необходимую информацию с помощью встроенной функции преобразования текста в речь.
Программа речевого доступа
ShinePlus — это программа речевого и брайлевского экранного доступа для Android.
Она также совмещает в себе функции чтения и увеличения экрана. Программа имеет гибкую систему жестового управления и расширенные возможности управления без необходимости постоянного контроля перемещения по меню.
Еще одной полезной функцией ShinePlus является наличие встроенного переводчика.
Набор возможностей
Набор «Специальные возможности» — сюда входит несколько приложений, которые помогают управлять мобильником, не глядя на экран или с помощью внешнего переключателя. Разработчиком является Google LLC.
Набор даёт возможность:
— использовать большое экранное меню, чтобы блокировать телефон, изменять яркость экрана и громкость, делать скриншоты и не только;
— выбирать объект на экране, после чего озвучивается его описание;
— управлять устройством с помощью клавиатуры или переключателей. Можно также использовать переключатели камеры, чтобы управлять устройством с помощью мимических жестов;
Также тут встроена функция TalkBack, которая озвучивает текст и элементы интерфейса. С ее помощью можно управлять устройством жестами и вводить текст с экранной клавиатуры Брайля.
Чтобы использовать набор «Специальные возможности», требуется Android 6 или более поздняя версия ОС. В большинстве современных мобильных устройств набор уже встроен производителями.
Аудиогид-путеводитель
izi.TRAVEL — аудиогид-путеводитель по России, Германии, Швейцарии, Италии и многим другим странам мира, доступным в приложении.
— автоматическое проигрывание историй тура благодаря GPS;
— возможность поделиться историями с друзьями, записав собственный аудиотур;
— проверка знаний с помощью развлекательных викторин;
— экономия на роуминге — аудиогиды можно скачать на телефон до поездки;
— быстрый доступ к местным историям с помощью QR-кодов и цифровой клавиатуры;
Фото с play.google.com
Аудиотуры доступны на 70 языках мира, в том числе русском.
Идентификация предметов
TapTapSee — позволяет произвести идентификацию предметов, с которыми человек сталкивается в обычной жизни. Нужно лишь дважды нажать на экран, чтобы сфотографировать предмет и услышать его описание.
Приложение является эффективным. Однако некоторые пользователи отмечают, что при плохом освещении фотографии получаются нечёткими, из-за чего программа может давать сбой.
Фото с play.google.com
В 2013 году TapTapSee стал лучшим приложением в Великобритании и обладателем премии от фонда для незрячих людей Америки.
Что-то уже используется в Таджикистане?
О том, какие программы уже используют таджикистанцы с проблемами зрения, мы узнали у сотрудников Филиала Общества слепых Душанбе. Так, по их словам, самыми распространенными являются программы NonVisual Desktop Access (NVDA) и Job Access With Speech (JAWS).
NVDA — это программа невизуального доступа к рабочему столу компьютера, работающая за счёт речевого оповещения пользователя об объектах на рабочем столе и окнах, действиях и процессах.
С ее помощью можно контролировать то, что читается, перемещая курсор к соответствующей области текста с помощью мыши или стрелок на клавиатуре.
NVDA также может конвертировать текст в шрифт Брайля, если пользователь компьютера имеет дисплей Брайля.
JAWS — программа для чтения с экрана компьютера, предназначенная для людей с ослабленным зрением. Разработана группой слепых и слабовидящих людей из США.
Чтение происходит путём предоставления пользователю информации, отображаемой на экране, через озвучивание текста на экране и с помощью шрифта Брайля, позволяющего без ограничений пользоваться клавиатурой.
Источник: asiaplustj.info
Технические аспекты обеспечения невизуальной доступности Android-приложений
Возможно, читателю, далекому от рассматриваемой проблематики, название покажется абсурдным, ведь дизайн интерфейса как самой системы Android, так и разрабатываемых для нее приложений, ориентирован прежде всего именно на визуальную наглядность и привлекательность, что усугубляется использованием сенсорного экрана в качестве главного органа взаимодействия пользователя с устройством. Однако существует категория пользователей, волею природы или случая лишенных возможности в полной мере насладиться всеми этими прелестями. Благодаря тому, что в Android предусмотрены альтернативные, — или, лучше сказать, дополнительные, — способы взаимодействия, интерфейс и основной функционал системы отнюдь не являются принципиально недоступными для данной категории пользователей. Именно обеспечению такой доступности посвящены пункт «Специальные возможности» в меню настроек системы и входящее в ее состав приложение TalkBack. Что же касается невизуальной доступности сторонних приложений, то она варьируется от случая к случаю и порой требует от разработчика не то чтобы каких-то специальных сверхусилий, но хотя бы минимального внимания к проблеме.
Список Android-приложений, протестированных на предмет невизуальной доступности, с соответствующими комментариями можно найти, например, здесь. Разумеется, это не единственный такой список в глобальной сети и наверное не самый представительный, но я ссылаюсь на него прежде всего как на источник примеров, наглядно иллюстрирующих то, о чем идет речь. Заметим, что невизуальная доступность интерфейса многих из этих приложений обусловлена не специальными стараниями их разработчиков, а является естественным результатом работы встроенных в систему механизмов. Разработчики же приложений просто этому не препятствуют, что, впрочем, я бы тоже вменил им в немалую заслугу.
Не станем углубляться в обсуждение целесообразности заботы о невизуальной доступности приложений в принципе. Об этом достаточно сказано в других местах. Отметим лишь, что разработчики Android уделяют этой заботе определенное внимание, о чем можно судить по истории развития средств специального доступа. Мы же сосредоточим свое внимание на чисто технических аспектах.
Рассмотрим ряд типичных проблем и укажем пути их решения. Иными словами, данное сочинение ориентировано главным образом на разработчиков Android-приложений, по тем или иным причинам решивших не игнорировать потребности пользователей, обремененных визуальными ограничениями, и целью своей имеет помочь им воплотить благородные помыслы в жизнь.
Так как дальнейшее изложение предполагает у читателя более или менее ясное представление о принципах невизуального доступа к интерфейсу, используемых в Android, с точки зрения как пользователя, так и программиста, то тем, кому эта тема внове, рекомендуется прежде всего ознакомиться с некоторыми источниками основополагающих сведений:
- Основы специальных возможностей в Android
- Модель сенсорного управления OS Android 4.1 Jelly Bean
- Доступность OS Android в вопросах и ответах
- ОС Android: Базовая часть для незрячих пользователей. Учебное пособие
- Рекомендации по разработке приложений для платформы Android OS с учётом доступности
- Android Design: Accessibility
- Android accessibility API guide
Приводимые ниже соображения и рекомендации будут иллюстрироваться и подкрепляться конкретными примерами, взятыми главным образом из проекта TeamTalk, мое участие в котором не в последнюю очередь было связано именно с решением проблем доступности Android-приложения.
Разумеется, как правило это будут не совсем буквальные выдержки из текста. Я буду максимально упрощать их и даже порою несколько видоизменять, дабы не утомлять читателя не относящимися к делу подробностями и сделать иллюстрируемые идеи наиболее выпуклыми. Ведь предметом нашего рассмотрения является не сам этот проект, а проблемы невизуальной доступности, достаточно типичные для Android-приложений вообще, и возможные пути их решения.
Те же, кто захочет ознакомиться с исходным кодом, скупые выдержки из коего будут сопровождать повествование, во всей его полноте, смогут легко удовлетворить свое законное любопытство на Github.
Концепция универсального дизайна и принцип здорового минимализма
Сразу скажу, что я далек от мысли проповедовать невизуальную доступность интерфейса в ущерб его визуальной наглядности или эстетике, не говоря уже о функциональности приложения. Я лишь ратую за то, чтобы о доступности тоже не забывали, особенно там, где это не требует от разработчика ни компромиссов, ни сколько-нибудь заметных специальных усилий.
Я сторонник концепции универсального дизайна, согласно которой, интерфейс приложения в идеале должен быть одинаково доступен всем категориям пользователей. И прежде всего не нужно мешать самой системе обеспечить такую доступность, что влечет за собой принцип здорового минимализма, заключающийся в том, что не следует плодить сущности без реальной необходимости.
То есть, когда возникает соблазн воспользоваться при разработке интерфейса какой-либо сторонней библиотекой или же создать свой собственный совершенно оригинальный элемент управления, недурно бы для начала задуматься: а так ли оно необходимо на самом деле? Android SDK предоставляет в распоряжение программиста весьма богатый набор средств такого рода, и без достаточно серьезных оснований за его пределы выходить не следует. Это, кстати, положительно отразится не только на доступности приложения, но и на его совместимости.
Об атрибуте contentDescription
Самое простое и очевидное, что разработчик приложения может (и должен, на мой взгляд) сделать для пользователей с визуальными ограничениями, не перетрудившись при этом и ничем не пожертвовав, — это аккуратно подписать все чисто графические элементы интерфейса через атрибут contentDescription . Однако, к сожалению, очень мало кто это делает. И должное уважение к данному атрибуту представляется скорее счастливым исключением, нежели общепринятой практикой.
Рекомендации использовать contentDescription для повышения доступности интерфейса приложений встречаются и в руководящих документах Google, и в других источниках, так что, честно говоря, даже неловко напоминать еще раз. Я бы и воздержался, кабы все эти рекомендации не игнорировались с постоянством, достойным явно лучшего применения.
Порою же в ответ на прямую просьбу подписать графические кнопки от разработчиков доводилось слышать, что, мол, на экране для этого мало места. Разумеется, подобный ответ свидетельствует прежде всего о профессиональной несостоятельности программиста, который, не удосужившись даже мало-мальски ознакомиться с документацией, образно говоря, не пишет программу, а ляпает как попало. Хочется верить, что среди разработчиков приложений настолько безграмотных найдется немного, но все же на всякий случай еще раз подчеркну, что атрибут contentDescription совершенно безобиден, он абсолютно никак не отражается на внешнем виде приложения и не требует места на экране.
Однако, как и ко всему на свете, к заполнению contentDescription надлежит подходить с пониманием и без фанатизма. Механически бездумный подход скорее всего приведет к совершенно нежелательным результатам.
Проиллюстрируем сказанное примером. Предположим, мы собираемся отображать на экране список пользователей и для элемента списка имеем следующую схему:
Как видим, чисто графический элемент ImageView в этой схеме не имеет атрибута contentDescription . И это совершенно осознанно. Элемент списка здесь рассматривается как единое целое, то есть, его части ( ImageView и TextView ) не имеют самостоятельной роли: у них не установлен атрибут clickable . Текстовая информация, необходимая службе специального доступа, целиком содержится в TextView , а ImageView в данном случае играет по большей части декоративную роль и с точки зрения невизуального доступа полезной информации не несет.
Совсем другое дело если бы элемент ImageView на самом деле использовался в качестве кнопки, нажатие на которую вызывало бы
какое-либо действие. В этом случае атрибут contentDescription был бы крайне полезен.
Теперь предположим, что пользователи в нашем списке могут находиться в различном состоянии, скажем, «online» и «offline», и для их индикации мы будем пользоваться разными цветами. Сделать эту дополнительную информацию также невизуально доступной нам опять-таки поможет атрибут contentDescription , который на сей раз мы будем задавать динамически вместе с цветом элемента в адаптере списка.
Вот как это может быть реализовано:
Предполагается, что в строковом ресурсе имеется определение:
%1$s online
Обратим внимание на то, что дополнительную информацию мы сообщаем службе специального доступа лишь тогда, когда пользователь пребывает в состоянии «online». Это помогает сократить объем речевых сообщений без ущерба для информативности, так как возможных состояний всего два, то есть никаких разночтений не возникает.
Речевые сообщения требуют времени на восприятие, поэтому их объем следует сокращать везде, где это возможно сделать, не жертвуя полезной информацией.
Кроме того, составляя комбинированный текст для contentDescription , мы размещаем имя пользователя перед обозначением его состояния, ибо из соображений эффективности восприятия наиболее востребованная информация должна располагаться в начале речевого сообщения.
Списки с «живыми» элементами
Продолжая рассматривать пример из предыдущего пункта, логично будет предположить, что состояние пользователей меняется по какой-либо внешней по отношению к приложению, или, точнее, его интерфейсу, причине. И нам необходимо регулярно обновлять информацию на экране, чтобы она соответствовала реальному положению вещей.
Для определенности предположим следующую реализацию:
То есть информация на экране будет обновляться примерно раз в секунду. Но при каждом таком обновлении элементы списка будут вырабатывать соответствующие события для службы специального доступа, и если при этом фокус доступности будет находиться на одном из элементов списка, то элемент этот будет непрестанно проговариваться, что приведет к практически полной невозможности нормального взаимодействия пользователя с приложением. Налицо тот случай, когда излишняя услужливость средств специального доступа оказывается не впрок и оголтелый фанатизм нуждается в разумном ограничении.
С этой целью введем в рассмотрение вспомогательный класс:
Теперь мы можем легко реализовать постоянное обновление информации на экране, не жертвуя невизуальной доступностью интерфейса:
В принципе, задачу можно было бы решить и переопределением метода notifyDataSetChanged() в адаптере списка:
public void notifyDataSetChanged()
Но этот вариант хуже, ибо блокируются события, возникающие при любом обновлении списка, даже если оно инициировано какими-либо действиями пользователя. Система же специального доступа ориентирована на то, чтобы пользователь имел адекватный отклик на свои действия, так что в общем случае такая блокировка нежелательна.
Сложные элементы списка и динамическая информация
Теперь рассмотрим ситуацию, когда каждый элемент списка имеет сопряженную с ним кнопку, то есть описывается, например, следующей схемой:
При взаимодействии с таким списком в режиме исследования касанием мы можем устанавливать фокус доступности как на сами элементы списка, так и на сопровождающие их кнопки.
Предположим далее, что помимо списка на экране отображается еще некая постоянно меняющаяся информация. Упрощенная схема выглядит примерно следующим образом:
И, по установившейся уже традиции, будем производить ежесекундные обновления:
В этой ситуации проблема возникает тогда, когда фокус доступности попадает на одну из кнопок внутри списка. Дело в том, что после обработки событий, возникающих при обновлении информации на экране, служба специального доступа восстанавливает его положение на элементе списка, а не на кнопке. В результате оказывается крайне трудно, а при более частых обновлениях и вовсе невозможно, нажать на кнопку в режиме невизуального доступа. И блокировка событий, рассмотренная в предыдущем пункте, здесь, увы, не помогает.
Для борьбы с этой неприятностью несколько расширим функциональность нашего вспомогательного класса:
И будем избегать обновления информации на экране при попадании фокуса доступности на встроенные в список кнопки, но, разумеется, лишь тогда, когда используется режим невизуального доступа:
Замечу, что это единственный из приведенных здесь рецептов, имеющий видимые последствия. То есть, при попадании фокуса доступности на некоторые элементы интерфейса обновления экрана будут замирать. Но происходить это будет лишь в режиме специального доступа. В обычном же режиме никаких побочных явлений не будет.
События на невидимых страницах
Рассмотрим еще один интересный случай, а именно, использование переключаемых вкладок (или страниц):
Дело в том, что ради гладкого переключения страниц, система держит в рабочем состоянии не только ту, которая отображается на экране, но и соседние с ней. И в случае обновления информации на этих соседних страницах, находящихся за пределами видимой области, вырабатываются соответствующие события для службы специального доступа. Происходит это порою и при переходе от одной страницы к другой, когда система готовит следующую и события инициируются уже с нее. В результате речевой отклик не соответствует тому, что отображается на экране.
Чтобы избавиться от этого нежелательного эффекта, вспомним о том, что решение об инициации события для службы специального доступа принимается на верхнем уровне иерархии, и разовьем наш вспомогательный класс следующим образом:
Теперь остается только вовремя сообщать о смене страниц:
А каждый фрагмент, отвечающий за страницу, должен ее зарегистрировать:
Параметр PAGE_NUMBER здесь на самом деле означает позиционный номер страницы. То же самое, что и параметр метода FragmentPagerAdapter.getItem().
Заключение
Может показаться, что изложенные здесь приемы в большинстве своем имеют целью не помочь, а как раз помешать системе специального доступа донести ту или иную информацию до сознания пользователя. В сущности, так оно и есть. Но избыток информации иногда вредит не меньше, чем ее недостаток. Особенно когда она явно лишняя и к делу не относится. Я не устаю повторять, что хороший речевой интерфейс должен говорить как можно меньше, но обязательно своевременно и всегда по-существу.
Встроенный в Android screenreader TalkBack, увы, от совершенства пока далек и, к сожалению, развивается куда менее динамично, нежели accessibility API в самой системе. Участие же сообщества в его развитии затруднено тем, что публикуемые исходники как правило неактуальны, а команда разработчиков попросту игнорирует обращения энтузиастов и конструктивные предложения.
Однако эта тема, заслуживающая отдельного рассмотрения, лежит за рамками данного сочинения. Я же хотел лишь обратить внимание разработчиков на проблему доступности приложений и, с одной стороны, развеять некоторые бытующие опасения, с другой же, показать как путем несложных телодвижений можно порой существенно улучшить ситуацию. Надеюсь, мне это хоть в какой-то мере удалось.
- Блог компании Адаптивные технологии ВОС
- Разработка под Android
Источник: habr.com