دسترس‌پذیری، دسترس‌پذیری، دسترس‌پذیری، دسترس‌پذیری

فرمی که می سازید برای مردم است. مردم از دستگاه های مختلفی استفاده می کنند. برخی از ماوس، برخی از دستگاه لمسی، برخی از صفحه کلید، برخی از دستگاهی که با حرکات چشم کنترل می شود استفاده می کنند. برخی از صفحه خوان، برخی از صفحه نمایش کوچک و برخی از نرم افزار بزرگنمایی متن استفاده می کنند. همه می خواهند از فرم شما استفاده کنند. یاد بگیرید که چگونه فرم خود را برای همه قابل دسترس و قابل استفاده کنید.

اطمینان حاصل کنید که کاربران هدف یک فیلد فرم را درک می کنند

تعداد زیادی کنترل فرم وجود دارد که می توانید از بین آنها انتخاب کنید. همه آنها چه چیزی مشترک دارند؟ هر کنترل فرم باید یک عنصر <label> مرتبط داشته باشد. عنصر <label> هدف یک کنترل فرم را توصیف می کند. متن <label> به صورت بصری با کنترل فرم مرتبط است و توسط صفحه خوان ها خوانده می شود.

علاوه بر این، ضربه زدن یا کلیک کردن روی <label> کنترل فرم مرتبط را متمرکز می کند و آن را به یک هدف بزرگتر تبدیل می کند.

از HTML معنی دار برای دسترسی به ویژگی های داخلی مرورگر استفاده کنید

در تئوری، شما می توانید یک فرم را فقط با استفاده از عناصر <div> بسازید. حتی می‌توانید آن را شبیه یک <form> بومی کنید. مشکل استفاده از عناصر غیر معنایی چیست؟

عناصر فرم داخلی بسیاری از ویژگی های داخلی را ارائه می دهند. بیایید نگاهی به یک مثال بیندازیم.

از نظر بصری، <input> (اولین مورد در مثال) و <div> یکسان به نظر می رسند. شما حتی می توانید متن را برای هر دو درج کنید، زیرا <div> یک ویژگی contenteditable دارد. با این حال، تفاوت‌های زیادی بین استفاده از عنصر <input> مناسب و <div> که شبیه <input> است وجود دارد.

کاربر صفحه‌خوان <div> به عنوان عنصر ورودی تشخیص نمی‌دهد و نمی‌تواند فرم را تکمیل کند. تمام چیزی که کاربر صفحه‌خوان می‌شنود "Name" است، بدون هیچ نشانه‌ای مبنی بر اینکه عنصر کنترل فرم برای افزودن متن است.

با کلیک بر روی <div>Name</div> <div> همراه با آن متمرکز نمی شود، در حالی که <label> و <input> با استفاده از ویژگی های for و id به هم متصل می شوند.

پس از ارسال فرم، داده های وارد شده در <div> در درخواست گنجانده نمی شود. در حالی که پیوست کردن داده ها با جاوا اسکریپت امکان پذیر است، یک <input> به طور پیش فرض این کار را انجام می دهد.

عناصر فرم داخلی دارای ویژگی های دیگری هستند. برای مثال، با عناصر فرم مناسب و inputmode یا type صحیح، یک صفحه کلید روی صفحه کاراکترهای مناسب را نشان می دهد. استفاده از ویژگی inputmode در <div> نمی تواند این کار را انجام دهد.

اطمینان حاصل کنید که کاربران از قالب داده مورد انتظار آگاه هستند

شما می توانید قوانین اعتبارسنجی مختلفی را برای کنترل فرم تعریف کنید. به عنوان مثال، فرض کنید یک فیلد فرم همیشه باید حداقل هشت کاراکتر داشته باشد. شما از ویژگی minlength استفاده می‌کنید که قانون اعتبارسنجی را برای مرورگرها نشان می‌دهد. چگونه می توانید اطمینان حاصل کنید که کاربران نیز از قانون اعتبار سنجی اطلاع دارند؟ به آنها بگویید.

اطلاعات مربوط به قالب مورد انتظار را مستقیماً زیر کنترل فرم اضافه کنید. برای روشن کردن این موضوع برای دستگاه های کمکی، از ویژگی aria-describedby در کنترل فرم و یک id در پیام خطا با مقدار یکسان برای اتصال هر دو استفاده کنید.

به کاربران کمک کنید پیام خطا را برای کنترل فرم پیدا کنند

در یک ماژول قبلی درباره اعتبارسنجی ، یاد گرفتید که چگونه پیام های خطا را در صورت ورود نامعتبر داده نشان دهید.

<label for="name">Name</label>
<input type="text" name="name" id="name" required>

به عنوان مثال، اگر یک فیلد دارای ویژگی required باشد و داده های نامعتبر وارد شده باشد، مرورگر هنگام ارسال فرم، یک پیام خطا در کنار کنترل فرم نشان می دهد. صفحه خوان ها نیز پیام خطا را اعلام می کنند.

شما همچنین می توانید پیام خطای خود را تعریف کنید:

این مثال برای اتصال پیغام خطا به کنترل فرم نیاز به تغییرات بیشتری دارد.

یک روش ساده استفاده از ویژگی aria-describedby در کنترل فرم است که با id عنصر پیام خطا مطابقت دارد. سپس از aria-live="assertive" برای پیام خطا استفاده کنید. مناطق زنده ARIA یک خطا را به کاربران صفحه خوان در لحظه نشان دادن خطا اعلام می کنند.

مشکل این رویکرد برای فرم‌های دارای چندین فیلد این است که aria-live معمولاً اولین خطا را در صورت وجود خطاهای متعدد اعلام می‌کند. همانطور که در این مقاله درباره اعلان‌های چندگانه aria-live در یک عمل توضیح داده شد، می‌توانید یک پیام واحد را با الحاق همه خطاها ایجاد کنید. روش دیگر این است که اعلام کنید خطاهایی وجود دارد، سپس خطاهای فردی را هنگامی که میدان متمرکز است اعلام کنید.

اطمینان حاصل کنید که کاربران خطاها را تشخیص می دهند

گاهی اوقات طراحان با استفاده از شبه کلاس :invalid حالت نامعتبر را قرمز رنگ می کنند. با این حال، برای برقراری ارتباط با یک خطا یا موفقیت، هرگز نباید فقط به رنگ تکیه کنید. برای افراد مبتلا به کوررنگی قرمز-سبز، حاشیه سبز و قرمز تقریباً یکسان به نظر می رسند. غیرممکن است که ببینید آیا پیام مربوط به یک خطا است یا خیر.

علاوه بر رنگ، از یک نماد استفاده کنید یا پیام های خطا را با نوع خطا پیشوند کنید.

<span class="error">
  <strong>Error:</strong>Please use at least eight characters.
</span>

به کاربران کمک کنید تا فرم شما را پیمایش کنند

می توانید ترتیب بصری کنترل های فرم را با CSS تغییر دهید. قطع ارتباط بین ترتیب بصری و ناوبری صفحه کلید (ترتیب DOM) برای کاربران صفحه‌خوان و صفحه‌کلید مشکل‌ساز است.

در مورد نحوه اطمینان از نظم بصری در صفحه به ترتیب DOM بیشتر بیاموزید.

به کاربران کمک کنید تا کنترل فرم متمرکز فعلی را شناسایی کنند

از صفحه کلید خود برای پیمایش در این فرم استفاده کنید. آیا متوجه شدید که سبک کنترل‌های فرم پس از فعال شدن تغییر کرده است؟ این سبک فوکوس پیش فرض است. می توانید آن را با شبه کلاس :focus CSS لغو کنید. از هر سبکی که در داخل :focus استفاده می کنید، همیشه مطمئن شوید که تفاوت بصری بین حالت پیش فرض و حالت فوکوس قابل تشخیص است.

درباره طراحی نشانگرهای تمرکز بیشتر بیاموزید.

مطمئن شوید که فرم شما قابل استفاده است

با پر کردن فرم خود با دستگاه های مختلف می توانید بسیاری از مشکلات رایج را شناسایی کنید. فقط از صفحه کلید خود استفاده کنید، از یک صفحه خوان (مانند NVDA در ویندوز یا VoiceOver در Mac) استفاده کنید، یا صفحه را تا 200 درصد بزرگنمایی کنید. همیشه فرم های خود را بر روی پلتفرم های مختلف، به ویژه دستگاه ها یا تنظیماتی که هر روز از آنها استفاده نمی کنید، آزمایش کنید. آیا کسی را می شناسید که از صفحه خوان استفاده می کند یا شخصی که از نرم افزار بزرگنمایی متن استفاده می کند؟ از آنها بخواهید فرم شما را پر کنند. بررسی های دسترسی عالی هستند، آزمایش با کاربران واقعی حتی بهتر است.

درباره انجام بررسی دسترس‌پذیری و نحوه آزمایش با کاربران واقعی بیشتر بیاموزید.

منابع