Skip to main content
LibreTexts - Ukrayinska

8.7: Детальний аудит

  1. Last updated
  2. Save as PDF
  • Page ID
    103497

    • \( \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}}\)

    Третім типом аудиту доступності веб-сторінок є детальний аудит. Цей вид аудиту проводиться за певною особливістю веб-сайту або за певним процесом. Розглядаються всі аспекти доступності функції або процесу.

    Мета аудиту

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

    Процес аудиту

    Процедура проведення детального аудиту дуже схожа на процедуру шаблону або загального аудиту, з доданим переглядом процесу або перехідних елементів процесу, пов'язаного з функцією або додатком.

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

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

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

    Час, необхідний для проведення аудиту

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

    Міркування відповідності

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

    Ключовий момент: Заява про відповідність після детального аудиту застосовується лише до певної версії програмного забезпечення або до певної функції веб-сайту в певний момент часу.