Summarize this content to 400 words in Persian Lang
1. همیشه به aria-label 😳
اگر شما مقصر این اشتباه هستید، من شما را سرزنش نمی کنم، زیرا من خودم در همان دام افتادم. مردم خیلی راحت استفاده می کنند aria-label هر زمان که بخواهند زمینه اضافی را فراهم کنند، اما میزان دقت خود را در این زمینه دست کم می گیرند.
اول از همه ممکن است اصلاً به آن نیاز نداشته باشید. این را در نظر بگیرید:
aria-label=”Quiz answers”>
Quiz answers
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
این مثال بسیار ساده است، اما نشان می‌دهد که ساختار HTML شما اغلب به اندازه کافی برای فراهم کردن زمینه مورد نیاز کاربران صفحه‌خوان (SR) است. آ همانطور که MDN و استاندارد HTML به ما می گویند، معمولاً با یک عنوان همراه است و SR ها بر آن متکی هستند. در عمل، حتی زمانی که یک کاربر SR یک صفحه وب را به‌جای سرفصل‌ها بر اساس مناطق پیمایش می‌کند (مناطق، مناطق خاصی در صفحه هستند مانند ، ، و غیره) همراه با خوانده می شود توسط SR حتی بدون aria-label.
اما جنبه بسیار شوم تری از چیزها وجود دارد از زدن بیهوده برچسب های بی فایده آریا در همه جا، آنها در واقع می توانند به شما خیانت کنند! 😕 این را ببینید:
aria-label=”Option 1 is the correct answer, and you did not vote for it”>
aria-hidden>Option 1
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
این کاملا معتبر به نظر می رسد درست است؟ ما زمینه اضافی را در ارائه می دهیم aria-label و پنهان کنید زیرا ما نمی خواهیم گزینه 1 دو بار خوانده شود. اما حدس بزنید، کل لیست در هر دو صفحه خوان NVDA و JAWS به طور کامل نادیده گرفته می شود! حالا چرا این جهنم است؟
موضوع دارای 2 جزء است:
به لطف این مورد فهرست، محتوای قابل مشاهده با SR ندارد aria-hidden. من حدس می زنم که پیش بینی می کردم، اما …
این aria-label، که قرار بود حول محتوای پنهان کار کند، در واقع نامعتبر است !
نه تنها نیست aria-label سازگار با عنصر آیتم لیست است، معمولاً نمی توان از آن در عناصر همه جا حاضر مانند استفاده کرد and یا شرط می بندم که شما آن را ندیده اید و من مطمئناً در گذشته ندیده بودم.
پس چه زمانی می توانید از آن استفاده کنید؟ MDN به وضوح می گوید (تاکید من است):
… اما در عمل فقط روی پشتیبانی می شود در ارتباط بودن عناصر، ویجت ها، نقاط دیدنی، تصاویر، و قاب ها.
به این معنی که اگر شما has eg. a role=”button”، برچسب aria کار می کند، اما اگر div ساده و قدیمی باشد، برچسب aria نادیده گرفته می شود. و همانطور که مثال من نشان می دهد، این می تواند فراتر از SR باشد که زمینه اضافی را فراهم نمی کند، در واقع می تواند منجر به پنهان شدن یک بخش کامل از محتوا از کاربر SR در هنگام برآورده شدن شرایط خاص شود.
2. غیرفعال کردن عناصر فرم
مطالب زیادی در مورد این موضوع نوشته شده است و من مقاله آدریان روزلی را برای جمع بندی توصیه می کنم. من اساساً 2 مشکل با غیرفعال کردن عناصر فرم دارم که imo برای کاربران SR و غیر SR مرتبط است.
دیدنشون سخته🙈
به دلایلی، دستورالعمل‌های دسترسی به محتوای وب (WCAG) به استاندارد کنتراست رنگی مشابه بقیه صفحه برای عناصر غیرفعال نیاز ندارد، که پس از آن چنین طرح‌هایی را مجاز می‌سازد:
اگر بینایی شما 20/20 باشد، با خواندن این دکمه مشکلی نخواهید داشت، اما بسیاری از افراد دیگر متن و حتی خود دکمه را با توجه به کنتراست کم آن با پس‌زمینه سفید، نمی‌بینند.
هیچ توضیحی نمی دهند
یک سوال صادقانه از خود بپرسید: هر چند وقت یکبار، وقتی عناصر فرم یا هر کنترلی را برای آن موضوع غیرفعال می کنید، توضیحی در مورد علت غیرفعال شدن آنها نیز ارائه می دهید؟ دقیقا.
این بسیار آزاردهنده و گیج کننده است که ندانیم چرا و نه فقط برای کاربران فناوری کمکی، هرچند که البته بیشترین ضربه را به آنها وارد می کند. ممکن است برای ما، برنامه نویسان، منطقی و کاملاً قابل درک باشد که به عنوان مثال. یک دکمه ارسال باید تا زمانی که همه فیلدهای فرم معتبر باشند غیرفعال می ماند، اما برای کاربران ما آنقدرها بریده و خشک نشده است.
3. دست کم گرفتن تفاوت های SR
تفاوت های زیادی بین SR ها در سطوح مختلف وجود دارد. یکی از بدیهیات نحوه خواندن صفحات وب توسط SRها است. به یاد بیاور aria-label گچا از شماره 1 بالا؟ در واقع در VoiceOver در مک و مک کار می کرد aria-labelمحتوای ed به خوبی خوانده شد اما در ویندوز SR – NVDA و JAWS کاملاً شکسته شد. مواقع دیگری که من اولین نسخه از یک ویژگی بسیار تعاملی را کدنویسی کردم و در درجه اول از NVDA برای توسعه آن استفاده کردم، در آنجا عالی کار می کرد اما اصلاً با VoiceOver کار نمی کرد.
از نظر توسعه، بهترین شرط شما پیروی از استاندارد WAI-ARIA و استفاده از راهنمای شیوه‌های تألیف است و در بیشتر موارد باید کاملاً واضح باشید.
اما این بدان معنا نیست که می توانید آزمایش را نادیده بگیرید و باید کاملاً روی چندین پلتفرم و SR آزمایش کنید:
ویندوز، به طور ایده آل NVDA و JAWS به دلیل سهم بازار بزرگشان، بر اساس بررسی WebAIM 2024
مک با VoiceOver
iOS با VoiceOver
اندروید مثلا با Talkback
من می‌توانم بگویم که این مجموعه حداقلی است، اما کاملاً درک می‌کنم که اگر یک توسعه‌دهنده انجام آن را هر روز انجام دهد، بسیار زیاد است، زیرا مطمئناً اینطور است. چیزی که به شما کمک می کند این است که با گذشت زمان یاد خواهید گرفت که چه چیزهایی نیاز به یک آزمایش کامل (دوباره) دارند و البته فرآیند آزمایش/حسابرسی 11 ساله شرکت شما باید پشتیبان شما باشد، اما این موضوع بزرگ خودش است که در اینجا توضیح نمی دهم.
4. عدم اطلاع از نحوه استفاده کاربران از SR 🤔
من آن را در مورد افرادی که به تازگی شروع به بازی با صفحه‌خوان‌ها کرده‌اند، خواه توسعه‌دهندگان یا طراحان، می‌بینم، و ایده‌ای مبهم از نحوه هدایت محتوای ارائه‌شده فراتر از فشار دادن کلید Tab دارند. این البته منجر به پیاده سازی کمتر از ایده آل می شود، مانند ساخت یک محصول و درک نکردن مخاطبان.
راه های زیادی برای پیمایش یک صفحه وب یا هر محتوای دیگری با صفحه خوان ها وجود دارد. بیشتر مردم از سرفصل ها برای درک محتوا استفاده می کنند. پرش به مناطق خاص، پیمایش توسط پیوندها، فرم ها یا ویژگی Find همگی ابزارهای مهمی برای کاربران SR هستند.
اما مسئله فقط این نیست که از چه محتوایی می توان از “لنگرها” استفاده کرد. اگر برای لحظه ای به تفاوت های SR برگردیم، تکنیک های بسیار متفاوتی از ناوبری را کشف خواهیم کرد. کاربران VoiceOver می‌توانند از یک روتور برای جابه‌جایی بین انواع مختلف «لنگرها» (منطقه‌ها، پیوندها، سرفصل‌ها، …) و حتی جستجو در میان آنها برای رسیدن به مقصد مورد نظر خود استفاده کنند. از سوی دیگر، NVDA با VO بسیار متفاوت عمل می کند، زیرا در یک حالت فراگیر عمل نمی کند، بلکه در حالت چندگانه و زمانی که کاربر به عنوان مثال کار می کند. می‌خواهد یک فرم را اجرا کند، باید از مرور به حالت تعاملی تبدیل شود.
SRها در تلفن همراه فصل خودشان هستند زیرا کاربران آنها را با دسکتاپ بسیار متفاوت عمل می کنند و بدون پرداختن به جزئیات، آنها واقعاً چیزها را در چشم انداز قرار می دهند (در مورد آن در شماره 5 بیشتر توضیح داده می شود).
درک همه اینها برای پیاده سازی برنامه های در دسترس کلیدی است و به شما کمک می کند تا بدانید هنگام رسیدگی به مشکلات a11y چه کاری و چرا انجام می دهید. خوشبختانه، منابع بسیار خوبی برای دریافت این نوع درک وجود دارد:
5. درک اشتباه از هدف کلید Tab
این به نوعی مورد علاقه من است زیرا من آن را بسیار می بینم و همچنین احساس می کنم درک آن زندگی همه ما را بسیار آسان تر می کند. پس بیایید دست به دست هم دهیم و همه را با هم بگوییم: کلید Tab برای پیمایش همه عناصر تعاملی نیست! 🤯
الان احساس خنده داری می کنی؟ هنگامی که سرگیجه از بین می رود، ممکن است فکر کنید “چه لعنتی گفتم؟” شاید برای شما بی معنی باشد. اما در واقعیت بسیار منطقی است. به مثال زیر توجه کنید؛ فقط کافیست روی Codepen کلیک کنید (من آن را از MDN دزدیدم) و Tab را تا انتها به صفحه تب فعلی (محتوای برگه فعلی) بزنید.
که کمی بیش از حد پرس Tab طول کشید، اینطور نیست؟ مطمئناً، همه برگه‌ها تعاملی هستند و باید قابل تمرکز باشند، اما آیا لازم بود همه آنها را مرور کنیم؟ و حالا تصور کنید که 10 تب وجود دارد، نه 5. یا حتی بهتر از آن، تصور کنید که سعی می کنید فهرستی از 1000 ایموجی را پشت سر بگذارید تا به محتوای زیر آن برسید. و تصور کنید که این کار را با موبایل انجام دهید! 🤯 این بیشتر از کمی خسته کننده خواهد بود، درست است؟
این مثال نشان می دهد که در واقع هدف کلید Tab این نیست که تمام عناصر تعاملی صفحه را مرور کند، بلکه به سرعت در محتوای صفحه مرور کنید. اگر کاربر تصمیم بگیرد که مانند جدول بالا با محتوا تعامل داشته باشد، می تواند این کار را با کلیدهای جهت دار انجام دهد.
مثل این است که در خیابانی قدم می زنیم، در خانه های کنار آن را می کوبیم و درجا تصمیم می گیریم که وارد خیابان بعدی شویم یا برویم. رفتن از خانه به خانه با فشار دادن کلید Tab و ورود به خانه کلیدهای پیکان است (زمانی که شما را به دلیل تجاوز دستگیر کردند، این را نقل قول نکنید).
بنابراین در عمل باید اینگونه به نظر برسد، اولین فشار کلید Tab فوکوس را به برگه فعال فعلی منتقل می کند، فشار دوم Tab به صفحه تب (محتوای برگه) می رود. مرتب!
مجدداً، یک منبع عالی در مورد چگونگی دستیابی به این نوع تعامل، دستورالعمل های تألیف W3C است و من نمی توانم آن را به اندازه کافی توصیه کنم.
خودشه!
خوب، بیایید بدانید کدام یک از تخلفات 11y شما را بیشتر آزار می دهد و چه چیزی را در لیست 5 برتر خود قرار می دهید!
در ادامه بخوانید
آپاچی اسپارک چیست؟ ویژگی ها و مزایای کلیدی
کدگذاری Tesseract – 26 جولای
100 روز کد هفته 4
جیکوب استرن – 23 ژوئیه
ارتقاء سطح به عنوان توسعه دهندگان
کروین – 21 ژوئیه
CrowdStrike در مقابل DevOps
اندرو تتزلی – 21 ژوئیه
1. همیشه به aria-label 😳
اگر شما مقصر این اشتباه هستید، من شما را سرزنش نمی کنم، زیرا من خودم در همان دام افتادم. مردم خیلی راحت استفاده می کنند aria-label هر زمان که بخواهند زمینه اضافی را فراهم کنند، اما میزان دقت خود را در این زمینه دست کم می گیرند.
اول از همه ممکن است اصلاً به آن نیاز نداشته باشید. این را در نظر بگیرید:
aria-label="Quiz answers">
Quiz answers
این مثال بسیار ساده است، اما نشان می‌دهد که ساختار HTML شما اغلب به اندازه کافی برای فراهم کردن زمینه مورد نیاز کاربران صفحه‌خوان (SR) است. آ
،
و غیره)
همراه با خوانده می شود
توسط SR حتی بدون aria-label.
اما جنبه بسیار شوم تری از چیزها وجود دارد از زدن بیهوده برچسب های بی فایده آریا در همه جا، آنها در واقع می توانند به شما خیانت کنند! 😕 این را ببینید:
aria-label="Option 1 is the correct answer, and you did not vote for it">
aria-hidden>Option 1
این کاملا معتبر به نظر می رسد درست است؟ ما زمینه اضافی را در ارائه می دهیم aria-label و پنهان کنید زیرا ما نمی خواهیم گزینه 1 دو بار خوانده شود. اما حدس بزنید، کل لیست در هر دو صفحه خوان NVDA و JAWS به طور کامل نادیده گرفته می شود! حالا چرا این جهنم است؟
موضوع دارای 2 جزء است:
- به لطف این مورد فهرست، محتوای قابل مشاهده با SR ندارد
aria-hidden. من حدس می زنم که پیش بینی می کردم، اما … - این
aria-label، که قرار بود حول محتوای پنهان کار کند، در واقع نامعتبر است
نه تنها نیست aria-label سازگار با عنصر آیتم لیست است، معمولاً نمی توان از آن در عناصر همه جا حاضر مانند استفاده کرد
پس چه زمانی می توانید از آن استفاده کنید؟ MDN به وضوح می گوید (تاکید من است):
... اما در عمل فقط روی پشتیبانی می شود در ارتباط بودن عناصر، ویجت ها، نقاط دیدنی، تصاویر، و قاب ها.
به این معنی که اگر شما
role="button"، برچسب aria کار می کند، اما اگر div ساده و قدیمی باشد، برچسب aria نادیده گرفته می شود. و همانطور که مثال من نشان می دهد، این می تواند فراتر از SR باشد که زمینه اضافی را فراهم نمی کند، در واقع می تواند منجر به پنهان شدن یک بخش کامل از محتوا از کاربر SR در هنگام برآورده شدن شرایط خاص شود.
2. غیرفعال کردن عناصر فرم
مطالب زیادی در مورد این موضوع نوشته شده است و من مقاله آدریان روزلی را برای جمع بندی توصیه می کنم. من اساساً 2 مشکل با غیرفعال کردن عناصر فرم دارم که imo برای کاربران SR و غیر SR مرتبط است.
دیدنشون سخته🙈
به دلایلی، دستورالعمل‌های دسترسی به محتوای وب (WCAG) به استاندارد کنتراست رنگی مشابه بقیه صفحه برای عناصر غیرفعال نیاز ندارد، که پس از آن چنین طرح‌هایی را مجاز می‌سازد:
اگر بینایی شما 20/20 باشد، با خواندن این دکمه مشکلی نخواهید داشت، اما بسیاری از افراد دیگر متن و حتی خود دکمه را با توجه به کنتراست کم آن با پس‌زمینه سفید، نمی‌بینند.
هیچ توضیحی نمی دهند
یک سوال صادقانه از خود بپرسید: هر چند وقت یکبار، وقتی عناصر فرم یا هر کنترلی را برای آن موضوع غیرفعال می کنید، توضیحی در مورد علت غیرفعال شدن آنها نیز ارائه می دهید؟ دقیقا.
این بسیار آزاردهنده و گیج کننده است که ندانیم چرا و نه فقط برای کاربران فناوری کمکی، هرچند که البته بیشترین ضربه را به آنها وارد می کند. ممکن است برای ما، برنامه نویسان، منطقی و کاملاً قابل درک باشد که به عنوان مثال. یک دکمه ارسال باید تا زمانی که همه فیلدهای فرم معتبر باشند غیرفعال می ماند، اما برای کاربران ما آنقدرها بریده و خشک نشده است.
3. دست کم گرفتن تفاوت های SR
تفاوت های زیادی بین SR ها در سطوح مختلف وجود دارد. یکی از بدیهیات نحوه خواندن صفحات وب توسط SRها است. به یاد بیاور aria-label گچا از شماره 1 بالا؟ در واقع در VoiceOver در مک و مک کار می کرد aria-labelمحتوای ed به خوبی خوانده شد اما در ویندوز SR - NVDA و JAWS کاملاً شکسته شد. مواقع دیگری که من اولین نسخه از یک ویژگی بسیار تعاملی را کدنویسی کردم و در درجه اول از NVDA برای توسعه آن استفاده کردم، در آنجا عالی کار می کرد اما اصلاً با VoiceOver کار نمی کرد.
از نظر توسعه، بهترین شرط شما پیروی از استاندارد WAI-ARIA و استفاده از راهنمای شیوه‌های تألیف است و در بیشتر موارد باید کاملاً واضح باشید.
اما این بدان معنا نیست که می توانید آزمایش را نادیده بگیرید و باید کاملاً روی چندین پلتفرم و SR آزمایش کنید:
- ویندوز، به طور ایده آل NVDA و JAWS به دلیل سهم بازار بزرگشان، بر اساس بررسی WebAIM 2024
- مک با VoiceOver
- iOS با VoiceOver
- اندروید مثلا با Talkback
من می‌توانم بگویم که این مجموعه حداقلی است، اما کاملاً درک می‌کنم که اگر یک توسعه‌دهنده انجام آن را هر روز انجام دهد، بسیار زیاد است، زیرا مطمئناً اینطور است. چیزی که به شما کمک می کند این است که با گذشت زمان یاد خواهید گرفت که چه چیزهایی نیاز به یک آزمایش کامل (دوباره) دارند و البته فرآیند آزمایش/حسابرسی 11 ساله شرکت شما باید پشتیبان شما باشد، اما این موضوع بزرگ خودش است که در اینجا توضیح نمی دهم.
4. عدم اطلاع از نحوه استفاده کاربران از SR 🤔
من آن را در مورد افرادی که به تازگی شروع به بازی با صفحه‌خوان‌ها کرده‌اند، خواه توسعه‌دهندگان یا طراحان، می‌بینم، و ایده‌ای مبهم از نحوه هدایت محتوای ارائه‌شده فراتر از فشار دادن کلید Tab دارند. این البته منجر به پیاده سازی کمتر از ایده آل می شود، مانند ساخت یک محصول و درک نکردن مخاطبان.
راه های زیادی برای پیمایش یک صفحه وب یا هر محتوای دیگری با صفحه خوان ها وجود دارد. بیشتر مردم از سرفصل ها برای درک محتوا استفاده می کنند. پرش به مناطق خاص، پیمایش توسط پیوندها، فرم ها یا ویژگی Find همگی ابزارهای مهمی برای کاربران SR هستند.
اما مسئله فقط این نیست که از چه محتوایی می توان از "لنگرها" استفاده کرد. اگر برای لحظه ای به تفاوت های SR برگردیم، تکنیک های بسیار متفاوتی از ناوبری را کشف خواهیم کرد. کاربران VoiceOver می‌توانند از یک روتور برای جابه‌جایی بین انواع مختلف «لنگرها» (منطقه‌ها، پیوندها، سرفصل‌ها، ...) و حتی جستجو در میان آنها برای رسیدن به مقصد مورد نظر خود استفاده کنند. از سوی دیگر، NVDA با VO بسیار متفاوت عمل می کند، زیرا در یک حالت فراگیر عمل نمی کند، بلکه در حالت چندگانه و زمانی که کاربر به عنوان مثال کار می کند. می‌خواهد یک فرم را اجرا کند، باید از مرور به حالت تعاملی تبدیل شود.
SRها در تلفن همراه فصل خودشان هستند زیرا کاربران آنها را با دسکتاپ بسیار متفاوت عمل می کنند و بدون پرداختن به جزئیات، آنها واقعاً چیزها را در چشم انداز قرار می دهند (در مورد آن در شماره 5 بیشتر توضیح داده می شود).
درک همه اینها برای پیاده سازی برنامه های در دسترس کلیدی است و به شما کمک می کند تا بدانید هنگام رسیدگی به مشکلات a11y چه کاری و چرا انجام می دهید. خوشبختانه، منابع بسیار خوبی برای دریافت این نوع درک وجود دارد:
5. درک اشتباه از هدف کلید Tab
این به نوعی مورد علاقه من است زیرا من آن را بسیار می بینم و همچنین احساس می کنم درک آن زندگی همه ما را بسیار آسان تر می کند. پس بیایید دست به دست هم دهیم و همه را با هم بگوییم: کلید Tab برای پیمایش همه عناصر تعاملی نیست! 🤯
الان احساس خنده داری می کنی؟ هنگامی که سرگیجه از بین می رود، ممکن است فکر کنید "چه لعنتی گفتم؟" شاید برای شما بی معنی باشد. اما در واقعیت بسیار منطقی است. به مثال زیر توجه کنید؛ فقط کافیست روی Codepen کلیک کنید (من آن را از MDN دزدیدم) و Tab را تا انتها به صفحه تب فعلی (محتوای برگه فعلی) بزنید.
که کمی بیش از حد پرس Tab طول کشید، اینطور نیست؟ مطمئناً، همه برگه‌ها تعاملی هستند و باید قابل تمرکز باشند، اما آیا لازم بود همه آنها را مرور کنیم؟ و حالا تصور کنید که 10 تب وجود دارد، نه 5. یا حتی بهتر از آن، تصور کنید که سعی می کنید فهرستی از 1000 ایموجی را پشت سر بگذارید تا به محتوای زیر آن برسید. و تصور کنید که این کار را با موبایل انجام دهید! 🤯 این بیشتر از کمی خسته کننده خواهد بود، درست است؟
این مثال نشان می دهد که در واقع هدف کلید Tab این نیست که تمام عناصر تعاملی صفحه را مرور کند، بلکه به سرعت در محتوای صفحه مرور کنید. اگر کاربر تصمیم بگیرد که مانند جدول بالا با محتوا تعامل داشته باشد، می تواند این کار را با کلیدهای جهت دار انجام دهد.
مثل این است که در خیابانی قدم می زنیم، در خانه های کنار آن را می کوبیم و درجا تصمیم می گیریم که وارد خیابان بعدی شویم یا برویم. رفتن از خانه به خانه با فشار دادن کلید Tab و ورود به خانه کلیدهای پیکان است (زمانی که شما را به دلیل تجاوز دستگیر کردند، این را نقل قول نکنید).
بنابراین در عمل باید اینگونه به نظر برسد، اولین فشار کلید Tab فوکوس را به برگه فعال فعلی منتقل می کند، فشار دوم Tab به صفحه تب (محتوای برگه) می رود. مرتب!
مجدداً، یک منبع عالی در مورد چگونگی دستیابی به این نوع تعامل، دستورالعمل های تألیف W3C است و من نمی توانم آن را به اندازه کافی توصیه کنم.
خودشه!
خوب، بیایید بدانید کدام یک از تخلفات 11y شما را بیشتر آزار می دهد و چه چیزی را در لیست 5 برتر خود قرار می دهید!
در ادامه بخوانید
آپاچی اسپارک چیست؟ ویژگی ها و مزایای کلیدی
کدگذاری Tesseract -
100 روز کد هفته 4
جیکوب استرن -
ارتقاء سطح به عنوان توسعه دهندگان
کروین -
CrowdStrike در مقابل DevOps
اندرو تتزلی -
