«Дехто навіть не здогадується, що є незрячі користувачі». QC Engineer — про проблеми доступності в IT та що варто знати всім розробникам
Олег Шпай працює Quality Control Engineer у SoftServe. Ще до роботи в IT хлопець радив компаніям, як поліпшити їхні сайти з погляду доступності, а також викладав комп’ютерну грамотність для людей з порушеннями зору. В інтерв’ю DOU Олег розповів про те, як працює їхня команда тестувальників доступності, які є основні проблеми у цій сфері та яким критеріям повинен відповідати продукт, щоб бути зручним для кожної людини.
Про освіту та вибір професії
Я сам зі Львова: тут народився і навчався. Зараз мені 24 роки. Я закінчив спеціалізовану школу для незрячих і слабозорих дітей. Незрячий я, власне кажучи, з народження.
Моїм улюбленим предметом завжди була математика. Коли я тільки-но йшов до школи, уже знав таблицю множення, ділення, мав розуміння, що таке дроби, міг ними оперувати. Коли мені було 10 років, удома з’явився стаціонарний комп’ютер. Але він не був моїм персональним, тому особливо мене не цікавив: коли незрячий і зрячі разом використовують один комп’ютер, це завжди своєрідний треш. Хтось комусь однаково заважає. Наприклад, рідним заважала моя програма екранного доступу, а мені — їхній бардак на робочому столі. Тому я полюбив комп’ютери у 14 років, коли мені подарували персональний.
Кілька слів про те, як незряча людина працює з комп’ютером. Насамперед їй потрібен скрінрідер — програма, яка дає змогу незрячим отримувати інформацію на комп’ютері. При цьому програма не зчитує її з екрана — інфо надходить на екран і скрінрідер одночасно. Наприклад, якщо у нас є HTML-сторінка, то інформація береться з коду HTML. Або якщо це програма, то з її коду.
Але сам скрінрідер вміє тільки цю інформацію отримувати. Щоб він її доносив до користувача, потрібно використовувати так звані синтезатори мовлення або брайлівські дисплеї. Синтезатор мовлення — програма, яка перетворює текст на аудіо. Брайлівський дисплей робить те саме, тільки оформлює текст брайлівським шрифтом — і користувач може сприймати інформацію на дотик, тобто все необхідне буде в нього під пальцями.
Отже, щоб створити середовище для незрячого користувача, його треба забезпечити скрінрідером, який вміє витягувати інформацію, і синтезатором мовлення або брайлівським дисплеєм, які передають її у потрібній формі.
Коли вперше мені потрапив у руки ноутбук, я не знав, що з ним робити, які завдання тут можна виконувати. Але щойно з допомогою інших навчився користуватися інтернетом, зрозумів, що є багато спільнот, де незрячі люди спілкуються, зокрема допомагають одне одному освоювати комп’ютер.
Хоча тут є й інша сторона медалі. Авжеж, коли раніше в тебе був мобільний телефон з кнопками, через який ти міг тільки дзвонити, а читати смс чи навігуватися в інтернеті — ні, то після такого комп’ютер з програмою екранного доступу — це «вау, круто». Та це поки в тебе мало досвіду. З часом ейфорія зникає. Заходиш на сайти, а вони — незручні. Починаєш розуміти, що перше враження про доступність оманливе.
Після школи я вступив до Львівського національного університету імені Франка на факультет іноземних мов. Чому туди? Насправді викладання ніколи мене не приваблювало: я завжди хотів працювати в IT-сфері. У школі ми вивчали німецьку, а я планував вивчити англійську, бо мені її завжди бракувало для роботи з комп’ютерами. На мене вплинула й моя вчителька німецької, з якою ми нині разом працюємо у SoftServe. Вона сказала: «Все, що потрібно буде з комп’ютерів і вищої математики, ти вивчиш сам. А ось англійську — ні, тому що це тобі дається важче і треба себе мотивувати. Універ — гарний спосіб вивчити іноземні мови, причому безкоштовно».
Загалом вона мала рацію. Бо якби я пішов, припустимо, на математичний факультет у той же університет Франка чи Львівську політехніку, то, підозрюю, це було б приблизно так: я б сидів на парі й абсолютно нічого не розумів, тому що там дуже багато візуалізації. Мені довелося б кожного дня після обіду звертатися по допомогу друзів чи батьків.
З іноземними мовами набагато простіше. Перед першим курсом я купив собі сканер, тому знав, що всі матеріали зможу просканувати та повноцінно з ними працювати. Водночас під час навчання домашні завдання не були проблемою. Вони займали лише 20% часу. Інші 80% — це просканувати текст, опрацювати, зробити його презентабельним, як того вимагали викладачі.
Взагалі, для незрячої людини суперкласних варіантів професій є не дуже багато. IT, викладання, психологія, юриспруденція, журналістика... Всі інші види діяльності фактично недоступні. Зряча людина може сказати: «Не хочу вчитися — піду прибиральником працювати». А у незрячої такого варіанту нема, хоч би вона й справді хотіла так зробити. Є суттєва проблема в тому, що багато речей просто недоступні.
І як би мені сумно не було таке говорити, але, за моїми спостереженнями, люди з порушеннями зору можуть знайти роботу тільки з вищою освітою. Крім IT, де її не вимагають — і слава богу. Авжеж, ще масаж. Є навіть такий стереотип: незрячий — значить масажистом працюєш. Так, вони справді непогано заробляють. Але для цього треба мати фізичну підготовку.
На робочому місці. Олег працює з брайлівським дисплеєм
Викладання
Ще у школі на думку спало таке: якщо мені треба було розбиратися, як працювати із щойно подарованим ноутбуком, то й іншим людям доведеться це робити, щоб мати змогу ним користуватись. Тому я вирішив організувати безкоштовні заняття, де показував новачкам, як працювати з комп’ютером або ж допомагав поглибити знання тим, хто цього потребував.
Тоді збагнув, що у мене непогано виходить навчати. Не буду себе розхвалювати, але, як стверджують інші, я вмію пояснювати складні речі просто. До того ж мені це приносить задоволення, бо в процесі я теж чогось навчаюся, розвиваюся. Коли вступив до університету, до комп’ютерних занять додалися приватні уроки з іноземних мов.
Люди, яких я навчаю, теж незрячі або з проблемами зору. Їм важко знайти репетитора з англійської, бо багато хто просто боїться, не знає, як працювати з незрячими. Є найважливіший момент (цього, напевно, не роблять ні в університетах, ні в школах) — навчити людину з порушенням зору працювати з електронними книгами. Якщо вона не володіє комп’ютером, не вміє працювати з електронними книгами, то це перетворюється на кошмар.
Якщо ці навички є, то можна адаптувати матеріал, правильно його подавати. Мені часто доводиться переформульовувати завдання, придумувати щось нове, тому що знов-таки доступність підручників не найліпша. Наприклад, класична вправа: поєднайте картинки та назви фруктів. Ну не може незряча дитина її виконати.
Маю наголосити, що викладання для мене завжди було більше як хобі, а не спосіб заробити гроші. Крім того, я займався тільки зі знайомими, через оголошення чи сайти учнів не шукав. Наприклад, бувало так, що у школі, де я навчався, батьки купували незрячий дитині комп’ютер, тож їм треба було знати, що з ним робити. І їм радили звернутися до мене.
Ще у мене є друзі, з якими ми постійно збираємося, і вони можуть попросити: «Розкажи про ось це». А іноді я сам щось нове дізнаюся і проводжу своєрідний тренінг. У мене багато різних пристроїв: я, напевно, трішки схиблений технічно (у хорошому сенсі цього слова). Маю два комп’ютери, три телефони та брайлівський дисплей — дорога річ, але мені пощастило її мати.
Взагалі, щодо необхідності цього пристрою точаться дискусії. Я вважаю, що є ті, кому брайлівський дисплей однозначно потрібен: програмісти, філологи іноземних мов і, звичайно, ті, хто не тільки не бачать, а й не чують, тому що для них це єдино можливий спосіб взаємодії з іншими людьми та комп’ютером. В університеті мені було легше з дисплеєм вчити нові слова. Ще я використовую пристрій, коли зрідка потрібно працювати з мовами програмування. Так набагато зручніше вичитувати та вводити дужечки, лапки тощо. Інакше доводиться вичитувати за символами через скрінрідер.
Щодо мов програмування, то якоїсь конкретної на професійному рівні я не знаю, маю досвід з Lua на Android, навички з HTML і скриптування для програми екранного доступу.
Також вирішив організувати собі мережу, щоб швидко передавати файли між пристроями без будь-якого під’єднання дротами, а також мати доступ до своїх мережевих дисків, коли я не вдома. Я це питання дослідив, розв’язав його завдяки технології VPN, використовуючи протоколи IPSec і WireGuard, а потім розказав друзям, як це зробити. І ми навіть об’єднали кілька мереж, щоб мати доступ до ресурсів один одного і передавати дані не прямо, а так, щоб вони були захищені VPN-тунелем.
Загалом мене дуже цікавить мережеве адміністрування. Навіть був період під час навчання в університеті, коли я працював позаштатним системним адміністратором на одній невеличкій фірмі. Я не сидів там постійно, а просто деколи приходив щось зробити.
Суто педагогічною діяльністю ніколи не планував займатися. Вважаю, що у нашій країні педагоги мають несправедливо маленьку зарплату, хоча виконують величезну роботу. Та й узагалі я завжди хотів працювати в IT-сфері. Рік тому шукав роботу, яка б була пов’язана з комп’ютерами, наприклад, з тим самим адмініструванням. Але склалося інакше.
Курси з Accessibility Testing
Минулого літа їздив на сплав Дністром. Зібралася міжнародна команда людей з проблемами зору — з Португалії, Молдови, інших країн. І ми цілий тиждень плавали на човнах, жили в наметах у лісі... Було дуже класно! Ми всі потоваришували. І якось під час розмов проскочило, що я цікавлюсь комп’ютерами. І за три місяці мені зателефонував один з організаторів того сплаву і розповів, що його знайома запостила інформацію про курси з Accessibility Testing (про них є окрема стаття на DOU), які організовувала компанія SoftServe.
Accessibility Testing — це тестування програмного забезпечення, яке використовують, щоб застосунок, сайт були зручними в користуванні для людей з порушеннями слуху чи зору, когнітивними проблемами, ураженням опорно-рухового апарату тощо. Напевно, я сам про курси не дізнався б, бо не дуже люблю Facebook і ним не користуюся, а пост був розміщений саме там.
Отже, я написав листа, мені зателефонували, розповіли про все більш докладно. Під час розмови сказав, що двоє моїх друзів теж хотіли б спробувати. І так ми втрьох вирішили податися. За місяць уже була перша співбесіда, на якій перевіряли знання скрінрідера та англійської. Усе це ми з друзями успішно склали. Хоча в нас була така ідея: якщо хтось один не пройде — ніхто не піде на курси :) А взагалі сумнівів, чи йти, не виникало. По-перше, це була можливість працювати в IT. По-друге, це реально корисна робота, яка допомагає зробити все трішки доступнішим.
Загалом на співбесіду прийшло близько 30 кандидатів, з яких обрали лише п’ятьох. Чого забракло іншим? Багато хто спіткнувся об англійську. Ще як приклад (і це не рідкість): була людина слабозора, яка дуже-дуже погано бачить, але чіпляється за свій зір, намагається щось розгледіти на екрані, хоча варто було б перейти на програму екранного доступу, щоб зберегти залишки того зору, які є. І от вона не хотіла жодних змін. Хоча однаково потім доведеться перейти на скрінрідер, але вже терміново, а така адаптація зазвичай не є легкою.
Після того як пройшли співбесіду, у нас було кілька місяців перерви. І за цей час я підготував для друзів курс, в якому ми повністю вивчили програми екранного доступу: від базових понять типу навігації в інтернеті до складніших, наприклад, як зробити речі доступними там, де це не передбачено із самого початку, просто використовуючи функціонал програми.
Ми серйозно поставилися до цього, збиралися по кілька разів на тиждень і зрештою досягли мети — чітко розібралися в скрінрідері, в усіх його функціях, а не тільки тих, що ми використовували щодня. Ніхто від нас цього не вимагав, але ми хотіли підтягнути свій рівень, освоїти складніші речі, щоб потім на це не витрачати час і почуватися впевненіше.
Курси з Accessibility Testing тривали два місяці. Пам’ятаю, спочатку у нас було ідеалізоване уявлення про доступність. Наприклад, нас спитали: «Як вважаєте, на скільки відсотків інтернет є доступним?». І я такий кажу: «Не знаю... Відсотків на
На курсах з Accessibility Testing
Про доступність
Раніше я думав, що доступність — це суто про користувацький досвід і функціонал скрінрідера. Про те, що багато чого залежить від розробників, до того часу я не дуже задумувався. Насправді ж доступність складається з трьох елементів. Перший — безпосередньо інструмент, у нашому випадку — програма екранного доступу, те, наскільки розробники забезпечили її функціональність, зручність роботи з нею.
Другий елемент — доступність самих ресурсів (вебсайтів чи застосунків), тобто те, наскільки вони зручні у користуванні для всіх категорій людей. Третє — досвід власне користувача. Тобто якщо ми говоримо про незрячу людину, то вона повинна розуміти, як працює програма екранного доступу. Бо інколи щось на перший погляд здається недоступним, хоча насправді просто бракує досвіду, нема знання, як користуватись певною функцією скрінрідера.
Я уже 10 років активно користуюся комп’ютером, тому можу сказати, що, звісно, за цей час багато чого змінилося. Самі скрінрідери з кожним роком стають кращими, що дає все більше доступу до вебсайтів, програм для комп’ютерів, мобільних застосунків тощо. Але особливо важливо те, що у світі нарешті почали говорити про доступність. Раніше це працювало так: розробники програми екранного доступу мали постійно пристосовуватися до сучасних тенденцій. А інші розробники робили, що хотіли, головне, щоб це було красиво та зручно більшості.
Останні роки багато хто почав усвідомлювати, що треба робити так, аби була доступність для різних категорій, що це потрібно закладати безпосередньо на етапі створення вебсайту або застосунку. Наприклад, у США та деяких країнах Європи це вже працює на рівні законів.
За 10 років повністю сформувався документ Web Content Accessibility Guidelines — ті стандарти доступності, яких необхідно дотримуватися під час розробки програмного забезпечення. Плюс великі платформи (Google, Microsoft тощо) у
Ще до курсів я інколи контактував з різними розробниками чи компаніями та пояснював їм, що можна поліпшити в їхніх продуктах у контексті доступності. Наприклад, є мобільний застосунок, він класний, і я готовий його купити, тому що він мені потрібен, я не шукатиму ламані версії в інтернеті. Але в програми є проблеми з доступністю. Інколи, коли продукт розробляла одна людина, мені йшли назустріч, щось змінювали. З великими компаніями ситуація набагато гірша. Наприклад, той же «Київстар». У них є застосунок «Мій Київстар», який складно назвати доступним. Колись я звернувся з цим питанням до них, мені сказали: «Дякуємо за інформацію, але, на жаль, найближчим часом доступність у нас не в пріоритеті». І це відповідає компанія, у якої майже 30 мільйонів користувачів!
Така сама проблема з державними застосунками на зразок «Дії», «Львівобленерго» чи «Водоканалу», мати повноцінний доступ до яких дуже важливо. Тобто щоб усіма функціями програми могли однаково скористатися як люди зрячі, так і незрячі чи з іншими особливими потребами. Наприклад, людина, яка не потребує accessibility, заходить у програму і може подати показники світла чи газу за одну хвилину. А я маю витратити 15 хвилин, щоб тільки розібратися, що куди вписувати, бо серед іншого не бачу повноцінно підписаних кнопок. Але що зробиш, коли у нас в Україні все так: хочу — роблю, не хочу — не роблю. Немає жодної відповідальності.
Робота QC
Раніше я був досвіченим користувачем комп’ютера, проте все-таки лише користувачем. На курсах з Accessibility Testing ми вчилися, як пояснити нюанси доступності розробникам, як відбувається співпраця в команді, як заводити дефекти в баг-трекінговій системі тощо. Якщо чесно, раніше я думав, що в IT все так легко: пишеш програмки, тестуєш, а виявилось, тут багато документації, яку треба знати, вести.
Під час курсів нам зразу сказали, що будуть певні вимоги, потрібно бути успішним, класно закінчити навчання — і тоді нас візьмуть на роботу. І зрештою все так і вийшло. Але день закінчення курсів збігся з початком карантину, а оформлювати нас збиралися з 1 квітня. Через це строки посунулись. Коли в травні карантин послабили, нам запропонували влаштовуватися з червня. Тоді ми вже з власної ініціативи попросили трішки відкласти оформлення, щоб відпочити улітку. І вийшли на роботу 15 липня як спеціалісти з Quality Control, або тестувальники доступності. Перші пів року йдуть як випробувальний термін.
До речі, всім, хто був на курсах, запропонували роботу. Тож наша команда складається з шістьох людей — п’ятьох тестувальників доступності та тімліда Вікторії, яка все це контролює та багато нас вчить. У нас чудова комунікація, бо ми втрьох з друзями разом прийшли від початку, з іншими двома членами команди теж були знайомі, а під час курсів ще більше здружилися.
Кожен мій робочий день починається з моніторингу електронної пошти та інших засобів комунікації. Це дуже важливо, бо там з’являється актуальна інформація про те, які дефекти були виправлені, до яких розробники написали коментарі, які зустрічі заплановані в онлайні, які документи потрібно підписати тощо. А потім у нас щоденна зустріч з командою в Zoom.
Ми обговорюємо поточні завдання, новини щодо Accessibility чи щодо компанії. У нас дружна команда, ми відверто спілкуємося на робочі теми, озвучуємо проблеми, які виникають. Можемо поговорити й про те, в кого який настрій, які справи. Якщо нам треба, ми ще раз зідзвонюємося, списуємося. Коли є активний проєкт, робочий день триває
Взагалі, думаю, це прогресивне рішення, коли на доступність тестують люди, для яких вона має велике значення, які можуть використовувати власний досвід, бо знають, що таке недоступність. Мені хочеться вірити, що за кілька років наше законодавство теж дійде до того, що правила доступності мають бути обов’язковими для всіх. Хоча якщо всім компаніям доведеться робити це в терміновому режимі та примусовому порядку, то якість доступності буде страждати.
Наше завдання — тестувати програми на готовність для кінцевої роботи користувача. Тобто це працює так: компанія отримує проєкт, замовник якого хоче серед іншого мати доступність. Розробники пишуть код, потім передають його на функціональне тестування, яке визначає, чи все працює так, як має працювати за документацією та вимогами. Коли вже продукт доходить до QA, під’єднуємося і ми, щоб перевірити, наскільки ним зручно користуватися.
Для операційної системи Windows ми застосовуємо дві програми екранного доступу, які наразі активно розвиваються, є найбільш популярними. Перша — Jaws for Windows, платний скрінрідер. Друга — NVDA, безкоштовне рішення, дуже функціональне та зручне, яке завойовує все більшу частку ринку. Для якої програми ми передусім тестуємо доступність, вирішують замовники. Вони також обирають конкретний браузер. Наприклад, може прийти замовлення на комбінацію Google Chrome і NVDA чи Mozilla Firefox і Jaws for Windows. А також Safari та VoiceOver для mac OS, але такого варіанту ще не було. Також ми можемо тестувати мобільні застосунки. Там є низка інших браузерів і скрінрідерів, якими можна користуватися.
Як ми проводимо тестування? Наприклад, є сайт, де можна замовити піцу. Щоб це зробити, її потрібно додати в кошик, а потім перейти в нього та оформити замовлення. Програму тестують функціонально, перевіряють, чи можна додати продукт у кошик, чи можна потім вибрати для оплати картку, чи не вискакує там помилок тощо. А якщо говорити про тестування доступності, ми маємо перевірити, чи нам зручно це робити. Ось є кнопка «Додати в кошик», ми дивимося, чи має вона відповідний текст, що ми додаємо в кошик, чи нам озвучується це як кнопка чи просто незрозумілий елемент на сторінці, коли її натискаємо, чи нам кажуть «Товар додано в кошик», чи доступна функція «Вибрати картку», чи попереджають нас про те, що дані, які ми вводимо, некоректні тощо.
Річ у тім, що людині з порушеннями зору потрібно більше часу на будь-яку дію, ніж зрячому. Ми мусимо прослухати кожен елемент окремо, коли сторінка оновилася, знайти нові елементи... Завдання доступності — зробити це настільки зручним, щоб ми в часі не сильно відставали від інших користувачів, не витрачали на це багато зусиль. Якщо буде навпаки, то і для компанії це невигідно. Якщо є сайт, де я не можу легко замовити піцу, я не буду з ним морочитися, а просто зайду на інший і замовлю там.
Web Content Accessibility Guidelines
У роботі ми, звісно, використовуємо свої знання, досвід, можемо навести приклад з практики, де ця річ реалізована краще. Але передусім керуємося документом під назвою Web Content Accessibility Guidelines (або скорочено — WCAG). Це набір критеріїв, де прописано, що таке доступність і якою вона має бути. Ми знаємо напам’ять ці критерії — їх близько 80. Вони розділені на три рівні (А, АА й ААА).
Рівень А — критерії, які мають бути виконані обов’язково для забезпечення базової доступності. АА — критерії, що складніші для виконання, бо вони вимагають більшої доступності, але мають бути однозначно виконані, якщо вебресурс або застосунок належить до урядових, державних. ААА — повна доступність, яка рідко трапляється на практиці.
Наприклад, WCAG починається з критерію 1.1.1, який належить до рівня А. Його суть в тому, що будь-який графічний контент повинен мати опис. Тобто якщо в нас на сторінці є картинка, то людина без зору, яка на неї натрапляє, може отримати інформацію, прослухавши загальний опис. Щоправда, є деякі винятки. Наприклад, якщо це логотип компанії, то його описувати не потрібно, достатньо сказати, що це таке.
Ще один приклад — критерій 4.1.2 під назвою Name, Role, Value (теж рівень А). Він зазначає, що кожен елемент на вебсторінці чи в застосунку має мати ці три складники. Припустімо, під час реєстрації є галочка «Запам’ятовувати мої персональні дані». Це її назва, Name. Те, що це є галочка — Role. А позначена вона чи ні — Value. Так, якщо всі вони є, то ми можемо використати пробіл, аби цю галочку відмітити. Але часто буває не так.
Є складніші критерії — АА й ААА. Існує такий пункт: якщо є відео, до нього має бути аудіо, текстовий опис чи коментар. На рівні А — достатньо невеликого опису самого відео. АА — повний текстовий коментар або аудіотранскрипція, а на рівні ААА — однозначно має бути все це, щоб люди мали вибір. Тобто критерії на складніших рівнях не передбачають винятків, все має бути побудовано з погляду доступності. А ось рівні А й АА — це базова доступність, з якою ми зазвичай і працюємо.
Web Content Accessibility Guidelines враховує потреби людей усіх категорій. Але насправді у нас вийшов такий парадокс, що з близько 30 людей, які прийшли на співбесіду на курси з Accessibility Testing, лишилось п’ятеро, які тотально незрячі. Я вважаю це невеличкою проблемою, бо у тому ж WCAG є такі критерії, які відповідають за контрастність сторінки, кольори чи збільшення. На жаль, нам не вдасться це протестувати. Звичайно, можемо заглибитися в HTML, подивитись, як воно там прописано, приміром, як поєднані кольори. Але все одно це ні про що. Тому такі речі тестує наш тімлід. Авжеж, практичніше, щоб усе-таки в групі тестувальників доступності були різні люди.
Варто враховувати й такий момент, що близько 70% Web Content Accessibility Guidelines написано під потреби саме незрячих. Чому так? Наприклад, якщо людина нечуюча, їй треба всього-на-всього, щоб усі матеріали, в яких є звук, супроводжувалися субтитрами або мовою жестів. Не на кожному вебсайті є аудіо чи відео, тому в такому випадку проблеми взагалі нема. До прикладу, люди з опорно-руховими проблемами — у них вже з’являється більше потреб, бо їм треба, щоб клавіатура була доступна. Щодо людей з когнітивними порушеннями — тут головне, щоб усе було чітко, зрозуміло, не виникало питань, що це за кнопка й таке інше.
Для тих, хто погано бачить, вже більше критеріїв, зокрема, щоб не був втрачений функціонал застосунку або вебсторінки. А повністю незрячі користуються спеціалізованою програмою — скрінрідером, тому тут потрібне окреме тестування.
Олег брав участь у велопробігу на тандемах «Бачу! Можу! Допоможу!». Марафон тривав три тижні — учасники проїхали від Івано-Франківська до Берліна
Співпраця з іншими командами
Якщо ми бачимо, що щось не працює відповідно до критеріїв, то заводимо дефект у баг-трекінговій системі за допомогою спеціальних інструментів. Описуємо, що саме не так, як це відтворити, як воно поводиться зараз і якої поведінки ми очікуємо відповідно до WCAG.
Іноді на цьому наша робота закінчується. Тобто бувають проєкти, що передбачають тільки тестування та звіт про дефекти, а виправлення залишається на розсуд клієнта, який уже вирішує залежно від своїх фінансових можливостей, часу і пріоритетів, продовжувати роботу у цьому напрямі чи ні. В інших випадках інформація про дефекти доходить до розробника, який повинен це виправити, після чого наше завдання — ще раз протестити, чи тепер воно працює, як очікувалось. Якщо так — закриваємо питання. Ні — знову передаємо інформацію розробникам.
Припустімо, підписано, що це кнопка, але сам надпис не дуже коректний. Також є така штука, як regression, коли виправлення одних дефектів тягне за собою негативні наслідки для тих частин, які раніше працювали добре. Тому ми перевіряємо, з якими компонентами пов’язаний виправлений, тестуємо, чи раптом одне виправлення не спричинило 10 інших проблем.
Деколи бувають зустрічі з розробниками, яким незрозумілі наші дефекти. Вони хочуть, щоб ми більш докладно пояснили, показали. Звісно, це пришвидшує комунікацію, бо спеціалісту не потрібно шукати конкретний критерій, вичитувати його, розбиратися. Крім того, є особливості скрінрідера, не всі ним користуються і можуть не врахувати його функціонал.
Нещодавно ми з колегою працювали над проєктом, де всі розробники й тестувальники були дуже класні, готові активно обговорювати кожен дефект, а потім швидко його виправити. Так буває не завжди. Це зрозуміло, бо для нас це на першому місці, іншим бракує часу на те, щоб розібратися з WCAG чи більше ознайомитися зі скрінрідером.
Хоча взагалі всі адекватні, з усіма можна домовитися, конфліктних ситуацій не виникає. Тут у мене не було жодного негативного досвіду, як, наприклад, в університеті, коли приходиш до викладача через реальні проблеми, щось не можеш зробити, а виходиш — ніби тебе облили брудом.
Сподіваюся, що так само комфортно буде й тоді, коли ми працюватимемо в офісі. Тоді всі до всіх звикають, з’являються спільні приколи. Зараз ми теж комунікуємо, але більше щодо справ, особливо з іншими командами.
Хоча сам варіант дистанційної роботи мені подобається, бо я дуже не люблю витрачати час на добирання, не люблю переповненого транспорту, заторів... Мені подобається жити швидко. Тому й суто з погляду зручності та особистого комфорту я хотів би працювати вдома, але при тому мати можливість приходити в офіс, щоб знайомитися з новими людьми, соціалізуватися... Усюди є свої плюси: вдома можна зробити гнучкіший графік, а офіс більше дисциплінує.
Недоступність в тестуванні доступності
Хоч ми працюємо над поліпшенням доступності, постійно стикаємося з недоступними речами. Наприклад, самі інструменти можуть бути не до кінця доступними. Так, для деяких проєктів заводимо дефекти у загальновідомій програмі Jira. Час від часу вона оновлюється, і буває так, що робота з цим інструментом перетворюється на тортури.
Наприклад, усього декілька тижнів тому було таке. Ми почали заводити дефекти на одному з проєктів і були дуже здивовані тим, що, по-перше, поле, в якому ми робимо опис, просто не ідентифікується як поле, де треба писати. А по-друге, коли ми суто інтуїтивно здогадалися, що саме сюди треба вписати текст, то не змогли навігуватися по ньому, редагувати його. Єдиний можливий варіант записати цей дефект — відкрити документ Microsoft Word, написати все там, скопіювати і вставити в потрібне поле.
Причому бажано написати зразу так, щоб потім там нічого не поправляти. Це жахливо, на такі прості речі витрачаєш дуже багато часу. Можливо, розробник тієї програми щось поліпшив, але з погляду доступності стало гірше. Потім, напевно, це виправлять. Ми обов’язково даємо фідбек у таких випадках, і наша тімлід Вікторія контактує з тими, кому цю інформацію можна донести.
Звичайно, у самій компанії люди теж багато чого вчаться. На початку роботи бувало так, що на електронну пошту надходили листи, в яких все було дуже гарно, графічно намальовано. Наприклад, повідомлення від SoftServe University про заклад, в якому можна проходити курси. Але ми не могли вичитати таке запрошення. Тому поскаржилися на схожі листи — і нам пішли назустріч. Авжеж, після навчання чи роботи в державній установі такий підхід приємно дивує. Бо проблеми є всюди, головне, що їх поступово розв’язують.
У Туреччині, 2019 рік
Що потрібно знати розробникам про доступність
Основна проблема, яку ми бачимо в програмах, що тестуємо та використовуємо, — це необізнаність розробників у тому, як функціонує скрінрідер і що передбачає доступність. Мені здається, потрібно проводити просвітницьку роботу. Ми частково займаємось цим у формі консультацій, але я вважаю, що це треба робити більш глобально. Наприклад, запустити спеціальні курси для розробників. Сьогодні ми дійшли до того етапу, коли збагнули, що загалом всім, хто проходить IT-академію, треба проходити тренінг із доступності. Коли ці спеціалісти писатимуть застосунки, то враховуватимуть вимоги щодо доступності, щоб нам не треба було виправляти їхню роботу знов і знов.
А взагалі багато хто не знає, що є така програма, як скрінрідер. Ба більше, дехто навіть не здогадується, що є незрячі користувачі, які можуть працювати з комп’ютером. Або що незрячі люди взагалі існують :)
Якщо говорити про конкретні помилки, часто буває неправильна структура вебсторінки. Так, на сторінці мають бути заголовки. Якщо їх нема, нам не дуже зручно навігуватися. Далі, напевно, маркером доступності є наявність зверху вебсторінки кнопки, яка називається Skip to main content. Вона потрібна, щоб людина не вичитувала довго всі верхні менюшки, а могла зразу отримати інформацію про основну ідею сторінки. Це такий індикатор, за яким можна визначати, працював тут хтось над доступністю чи ні. Це базова річ, яка мусить бути.
Ще деколи елементи неправильно кодуються, фейлять критерій 4.1.2 Name, Role, Value. Наприклад, у нас трапилася ситуація, коли роль була неправильно задана, тобто ми не знали, що треба вибирати з наявного, а думали, що там потрібно писати своє. Ще одна поширена помилка — відсутність описів до картинок.
Що б я порадив розробникам? Насамперед, коли вони пишуть код, не боятися вмикати скрінрідер і пробувати тестувати з ним. А також знати, що таке Web Content Accessibility Guidelines і як до нього доступитися. Не боятися комунікувати з цього питання. Взагалі це не тільки розробників стосується. Вважаю, завжди краще перепитати, уточнити, може, здатися десь некомпетентним, ніж потім триста разів переробляти.
Плани
Щодо моїх професійних планів, то наразі я хочу передусім розвиватись у напрямі Accessibility Testing. Реально бачу, що моя робота приносить користь. А далі... Якщо буде можливість паралельно освоїти щось інше з програмування, то чому б ні. Думаю, мені було б цікаво щось створити, написати. Можливо, вивчити Java. І взагалі мене цікавить більше програмування під Android, ніж під Windows. Також хотілося б заглибитися в тему адміністрування.
Є ідея створити курси з базового володіння комп’ютером для людей з порушеннями зору. Цікаво було б зробити курси і для розробників щодо роботи та функціоналу скрінрідера. Можливо, коли робота буде звичніша, графік — стабільнішим, продовжу викладати англійську. Бо зараз на це бракує часу.
Ще мене цікавить ехолокація. Торік я навіть брав участь у телевізійному шоу, де показував здібність до ехолокації та, власне, переміг. Цікаво було б підготувати заняття, які будуть справді корисні для незрячих людей. До того ж до мене звернулося уже багато охочих навчитися ехолокації.
Ехолокація — це процес отримання інформації про навколишнє середовище через звуки, зокрема штучно створені. Наприклад, якщо я поклацаю язиком чи пальцями, цей звук відіб’ється від стіни, і я зможу отримати загальне уявлення, що є стіна, на якій відстані вона приблизно розташована, а інколи навіть з якого матеріалу зроблена. Це уміння допомагає незрячим орієнтуватися в просторі.
Окрім професійного розвитку, є особистісний. Хотілося б мати більше свого простору в житті, власне помешкання. Ще рано чи пізно задумаюсь про створення сім’ї, тоді це буде особливо актуально.
Планів багато. Я люблю навчатися, розвиватися. І готовий використовувати будь-яку можливість для самовдосконалення.
