שימו לב: תוספי נגישות לא יעזרו לאתר שלכם להיות נגיש

הדגמה על איך תוסף נגישות אינו תורם לנגישות על פי התקן בארץ ובעולם.

זה פוסט טכני עם הסברים והוכחות לכך שתוספי נגישות, גם פופולריים מאד, לא רלוונטיים לתקני הנגישות. בתחתית המאמר יש גם רפרנסים נוספים. אבל כאן יש הסבר בעברית קלה עם הסברים טכניים.

ראשית – אני ממליץ מאד להכנס לפוסט הזה על נגישות שעוסק בנגישות טכנית וגם מכיל פרק בפודקאסט ״עושים תוכנה״ שבו יש מידע נוסף והסברים על מהי נגישות ועל כלי בדיקות ו-CI לבדיקות נגישות אוטומטיות ולבדיקות רגרסיה. אני חושב שאי אפשר להבין את הפוסט הזה בלי רקע בנגישות.

נגישות – הבנת ה-principles, guidelines וה-sc

אנו עובדים מול תקן הנגישות WCAG המאד מקובל והפופולרי בעולם שגם מדינת ישראל עובדת איתו. בתקן 5568 שהוא התקן הישראלי המחייב מצוין שהוא תואם ל-2.0 אבל רוב החברות עובדות כבר עם 2.1 ו-2.2 נכנס ממש עכשיו וגם מדינות אחרות צמודות אליו. בארצות הברית הוא כמעט זהה לתקנה 508 ומהווה את התקן העולמי דה פקטו לנגישות.

ב-WCAG 2.0\2.1\2.2 (מעכשיו אני אתייחס אליו כ WCAG בלבד) יש לנו שלושה חלקים עיקריים – Principles או עקרונות ראשיים שכל אחד מהם מכיל Guidelines שנגזרים מהעקרונות המשניים ולכל Guideline יש Sucess Criteria או בקיצור SC.

כך למשל, ארבעת העקרונות הראשיים הם Preceivable – ״נתפס״ בתרגומו המוזר לעברית – שעוסק בתפיסה – איך אנשים שונים תופסים פלט ו-Operable או ״ניתן להפעלה״ העוסק איך אנשים שונים יוצרים קלט, Understandable או ״ניתן להבנה״ שעוסק איך אנשים שונים מבינים את האתר וזרימת המידע בו ו-Robust העוסק יותר בתקנים טכניים.

העקרונות הראשיים הם לא מעשיים ויש לפרוט אותם לפרוטות מעשיות כדי להבין מה עושים, בגלל זה יש לנו את ה-Guidelines ואפילו בהם יש תתי סעיפים שהם ה-SC.

בואו ונדגים עם SC אחד שבחרתי באקראי מהתקן של WCAG 2.2. שמו הוא 1.4.3 Contrast (Minimum)

המספר הראשון הוא שם העקרון ואני כבר רואה לפי המספר שהוא עוסק בפלט כיוון שהוא 1: Precievable – כלומר כל מה שהאתר מראה. הוא קשור ל-Guideline 4 והמיקום שלו הוא 3 ברשימת ה-SC. בדרך כלל הסעיפים נעים מ-A ל-AAA. אז יש סיכוי שהוא AA או אפילו AAA. במקרה הזה הוא באמת AA ומסביר על ניגודיות. בגדול מה שמעניין אותי זה תמיד המספר הראשון 1,2,3 או 4 שמראים לאיזה עקרון ה-SC הזה שייך.

ועכשיו לת׳כלס: האם תוסף נגישות תואם לתקן?

אחרי שהבנו פחות או יותר מה זה המספרים המוזרים האלו ליד ה-SC ולמה הם חשובים לפחות להפניה ראשונית, כדאי שנגיע לנושא שלכבודו התכנסנו כאן היום – האם תוספי הנגישות הם רלוונטיים? כדי להמנע מבלגנים משפטיים, אני אצטרך להדגים עם דוגמאות פשוטות ולא עם אתרים קיימים שיש בהם תוספי נגישות.

הנה דוגמה לדף די פשוט וקל. יש בו קצת מידע טקסטואלי ויש בו גם טופס ששולח מייל. כדי לפשט את העניין אין לו עיצוב בכלל.

<!DOCTYPE html>
<html>
<head>
    <title>Demo page</title>
</head>
<body>
    <h2>Hello, world!</h2>
    <h4>Heading 2</h4>
    <p>This is a paragraph.</p>
    <p>This is another paragraph.</p>
    <h2>Heading 3</h2>
    <p>This is a paragraph.</p>
    <form action="https://example.com/api/form">
        <span>Email:</span>
        <input type="text" id="email" name="email">
        <button type="button" onclick="validateEmail()">Submit</button>
    </form>
    <script>
        async function validateEmail() {
            var emailInput = document.getElementById("email");
            var email = emailInput.value;
            var regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
            if (!regex.test(email)) {
                return false;
            } else {
                await fetch('/', {
                    method: 'POST',
                    headers: {
                        'Content-Type': 'application/json'
                    },
                    body: JSON.stringify({ email: email })
                })
                alert('Email submitted');
            }
        }
    </script>
</body>
</html>

ככה הוא נראה כשמריצים אותו:

הצגה של דף אינטרנט שרונדר מהקוד שלעיל - יש כמה כותרות וטופס של email עם submit. באמת ברמת ה-hello world ולמטרת המחשה.

יש בדף הזה כמה בעיות נגישות. אני אעבור על חלק מהן:

SC 1.3.1 Info and Relationships

הכותרות בדף לא מסודרות לפי סדר לוגי: h1->h2->h3->h4 – הפתרון הוא להקפיד על הסדר ולשנות את הקוד.

SC 3.3.2 Labels or Instructions

אין label לטופס. אין את התגית הזו המסייעת לאנשים עם קוראי מסך או סתם לאנשים כמוני שאוהבים ללחוץ על ה-label ולהגיע ישר לשדה הרלוונטי. צריך לשנות את ה-span ל-label ולהקפיד שיהיה שם for ו-name תואמים.

SC 3.3.3 Error Suggestion

אין הסבר ברור על שגיאות אפשריות או אינדיקציה אליהן. אם אני ממלא אימייל לא תקין, אין אינדיקציה של שגיאה. גם אם היא היתה, צריכה להיות אינדיקציה משמעותית. פה אפשר לעשות את זה אם נשנה את ה-type ל-email ונקבל את זה בחינם מהדפדפן. אם זה סוג מידע אחר, נצטרך להשקיע יותר.

בואו נעצור כאן. בחרתי בכוונה דברים פשוטים יחסית שאפילו מתגלים בכלים אוטומטיים.

עכשיו נכניס תוסף מסוים. בחרתי בתוסף נגיש.לי. למה בחרתי בו? כי הוא חינמי, נפוץ והאמת גם מצהיר בכנות שהוא לא פותר בעיות נגישות אלא מסייע בממשק. הוא גם עובד בדומה לתוספי נגישות אחרים. ההטמעה שלו פשוטה. אני פשוט מוריד את הקובץ ומשתמש בו. הוא עובד היטב (עם גרסת jQuery 2, זו עם 3 לא עובדת כרגע) והוא עושה מגוון דברים הקשורים לתצוגה – למשל משהה אנימציות, מגדיל טקסט (בדומה לאפשרות בדפדפן), משנה את הצבעים לשחור לבן.

הנה הקוד שלו שאתם יכולים להריץ אחרי שהורדתם את התוסף.

<!DOCTYPE html>
<html>
<head>
    <title>Demo page</title>
    <script
    src="https://code.jquery.com/jquery-2.2.4.min.js"
    integrity="sha256-BbhdlvQf/xTY9gja0Dq3HiwQF8LaCRTXxZKRutelT44="
    crossorigin="anonymous"></script>
    <script src="/nagishli.js?v=2.3" charset="utf-8" defer></script>
</head>
<body>
    <h2>Hello, world!</h2>
    <h4>Heading 2</h4>
    <p>This is a paragraph.</p>
    <p>This is another paragraph.</p>
    <h2>Heading 3</h2>
    <p>This is a paragraph.</p>
    <form action="https://example.com/api/form">
        <span>Email:</span>
        <input type="text" id="email" name="email">
        <button type="button" onclick="validateEmail()">Submit</button>
    </form>
    <script>
        async function validateEmail() {
            var emailInput = document.getElementById("email");
            var email = emailInput.value;
            var regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
            if (!regex.test(email)) {
                return false;
            } else {
                await fetch('/', {
                    method: 'POST',
                    headers: {
                        'Content-Type': 'application/json'
                    },
                    body: JSON.stringify({ email: email })
                })
                alert('Email submitted');
            }
        }
    </script>
</body>
</html>

אם תריצו את התוסף, תראו שהוא עובד באופן מוצלח ויש אייקון קטן ונאה שלחיצה עליו פותחת תפריט שבו אפשר לעשות שלל פעולות.

א-ב-ל – כל הדברים האלו לא רלוונטיים בכלל להפרות הנגישות שיש לעיל. התוסף הזה ואחרים לא יתקנו את זה. האמת היא שללא שינוי קוד משמעותי בצד הלקוח אי אפשר לתקן אותן. אפילו אם היה שינוי כזה, עדיין יש לנו מקומות שחייבים התערבות אנושית. שום תוסף, טוב ככל שיהיה – לא יכול לתקן את SC 3.3.3 שדורש הודעת שגיאה שבאמת מסבירה משהו. תוספים לא יכולים לתקן סדר כותרות או להחליט על label של טופס.

כל ה-SC האלו שבחרתי משפרים את חווית השימוש באתר לכולם. כולנו היו רוצים לראות הודעות שגיאה נורמליות, כותרות במבנה מסודר או לייבלים מתאימים. זה הופך את האתר נעים יותר לשימוש וקל מאד להבחין בהן והן לא מסובכות. כמובן שבדרישות יותר מורכבות יש גם כשלונות של התוספים. כי כרגע הטכנולוגיה לא שם.

אתם כמובן מוזמנים לקחת את הקוד שלעיל ולבדוק אותו עם כל תוסף נגישות שיש. גם כאלו שמתהדרים ב-AI משוכלל ובשינויים ב-DOM. הם עדיין לא פותרים את כל הבעיות. הקוד הזה מאד פשוט, עם הפרות מאד ברורות שאינן נתונות לפרשנות.

יש כמה נקודות חשובות בתוסף נגישות – בזמנו שוחחתי על זה עם יובל וגנר מעמותת נגישות ישראל שעוסק בכך והוא ציין שיש חשיבות לתוסף כי לעתים הוא מקל פרקטית את השימוש באתר. גם הצבה שלו, יחד עם הצהרת נגישות, מראה על כך שבאמת אכפת לכם מאנשים עם מוגבלויות (למרות שהנגשה לא רלוונטית רק לאנשים עם מוגבלות אלא הופכת את האתר לנעים יותר בשימוש). ואני באמת רואה מגמה של תוספי נגישות להצהיר באופן גלוי שהם לא תומכים בתקן אלא משפרים את השימושיות באתר. שזה מעולה. אבל מבחינה חוקית – אין שום משמעות להצבת התוסף ומי שצריך הוכחה – ההוכחה נמצאת לעיל.

אז מה עושים?

אם אתם חייבים בנגישות, אין מנוס מלהשקיע בנגישות אמיתית – זה לא מאד קשה ויש לא מעט עזרים, תוכנות ובדיקות שיכולות להיות משולבות ב-CI ובתהליך הפיתוח ולהקל על מציאה וגם על ריגרסיה. אם אין לכם תהליך CI, יש לכם בעיות קשות מנגישות במערכות שלכם 😁