8.4: Неофіційні огляди

Last updated
Save as PDF

Page ID: 103498

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

Неформальний огляд - це швидке сканування веб-сайту для виявлення очевидних проблем доступності. Хоча ці огляди не являють собою вичерпних аудитів, вони корисні для різних цілей.

Мета рецензування

Неформальний огляд часто додається до цитати для офіційного аудиту доступності, надаючи клієнту деяку вступну інформацію, щоб дати їм краще уявлення про типи питань на своєму веб-сайті, перш ніж вони зобов'язуються до офіційного огляду. Неформальний огляд може бути корисним для обґрунтування офіційного огляду.

Процес рецензування

Неформальні огляди часто відбуваються як частина розмови, можливо, з членом організації, який відповідає за управління іміджем організації, або з розробником, який планує або переглядає проектні заходи. Ці огляди часто включають кілька швидких тестів, таких як тест навігації клавішею Tab, або проходження сторінки через автоматичну перевірку доступності, або швидке вивчення коду, де можуть бути підозрювані проблеми, або запуск сторінки через екранний зчитувач. Ці швидкі огляди часто виявляють ряд потенційних бар'єрів, які допомагають розпочати обговорення наступних кроків до того, щоб зробити веб-вміст доступним.

Звітність за результатами рецензування

Нижче наведено приклад типів питань, які можуть бути задокументовані в неформальному огляді. Характеристики неформального огляду можуть включати (у цьому прикладі):

Тип сайту: система реєстрації з інтегрованою eCommerce
Терміни розгляду: перед виходом в прямому ефірі
Тривалість рецензування: близько 30 хвилин
Аудиторія: розробник інтерфейсу користувача (UI), створеного над сторонньою системою електронної комерції
Стиль звіту:
1. Надається електронною поштою розробнику та керівній команді розробника
2. Короткий і лаконічний
3. Написано таким чином, що розробник зрозуміє, вже будучи знайомий з користувальницьким інтерфейсом, і вже знайомий з технічною мовою, що використовується
4. Кілька проблем, пов'язаних з недоступністю, визначені як люб'язність
5. Не надто деталізований, якщо огляд призначений для отримання офіційного рецензування

Зразок неформального огляду електронною поштою

Привіт Джон,

Ось короткий підсумок потенційних проблем, знайдених на вашому сайті реєстрації. Якщо вам подобається, ми можемо організувати час для розмови про ці питання, і можливість проведення офіційного огляду, який буде розглядати ці та інші потенційні питання більш детально, щоб гарантувати, що якомога більше людей змогли отримати доступ до вашого сайту і зареєструватися.

Я визначив деякі проблеми та запропонував пропозиції щодо можливих виправлень, де це можливо:

Пов'язуйте мітки з полями форми, зіставляючи атрибут for у label з атрибутом id у елементі input.
Додайте aria-required = «true» до необхідних полів введення.
Використовуйте aria-describedby= "[id]», щоб зв'язати опис у прихованих прольотах з відповідним полем введення.
Входи Так/Ні виглядають як прапорці, але функціонують як перемикачі. Можливо, не проблема, але суперечить тому, що більшість людей можуть очікувати.
Для номерів виносок поруч із пунктом «Ціна» та «Група» можна використовувати aria-describedby, щоб зв'язати виноску з номером, або цифри можуть бути пов'язані з якорем поруч із відповідною виноскою.
Оскільки в таблиці квитків є два рівні комірок заголовків таблиці, вони повинні використовувати заголовки/ідентифікатор для асоціації обох рівнів заголовка, хоча в цьому випадку це банальна проблема, враховуючи невеликий розмір таблиці.
Прапорець шукає кнопку поруч з кредитними картками прийняті рядки трохи заплутано. Він показує курсор руки, який передбачає, що він повинен бути клікабельним, але це не так.
Коли відображається повідомлення про помилку, включіть role="alert» в div, що містить повідомлення.
При виникненні помилки надішліть фокус на перше поле, яке має помилку.
Форму для оплати можна було подати без дійсності електронної пошти власника квитка.
Натискання кнопки «повернутися до форми» у спливаючому вікні кредитної картки зависає, мабуть, намагаючись отримати доступ до Google Analytics.
У спливаючому вікні кредитної картки фокус повинен бути захоплений у діалоговому вікні циклу, доки не буде натиснуто клавішу «Оплатити зараз», «Назад до форми» або клавішу Escape.
У спливаючому вікні кредитної картки початковий прапорець та інші поля форми повинні бути пов'язані з відповідними мітками за допомогою елемента Label (з відповідністю для/id).
Для повідомлення про помилку, яке з'являється у спливаючому вікні кредитної картки, додайте role="alert» до діапазону, що містить повідомлення.
Закрити X повинен мати текст заголовка, наприклад title="закрити дані кредитної картки».
Після відправки форми кредитної картки екран зависає, знову намагаючись отримати доступ до аналітики Google.
Не вдається побачити результат після подання кредитної картки, щоб визначити, чи є якісь проблеми на останньому кроці.
Не вдається побачити, як видаються квитки, можливо, електронною поштою. Не впевнений, чи є якісь проблеми там.