Common accessibility issues that you can fix today

Published 2022-04-12 category: thoughts

WebAIM have come out with their latest report on which accessibility issues they found in the top million websites that they tested automatically. What is some low hanging fruit you could fix today?

For context, WebAIM, a non profit based out of Utah in the US, have done their ‘WebAIM Million’ project since 2019. They post an extensive analysis every year, looking at trends and improvements/decline in web accessibility over time. I find these posts very insightful and use them to inform my own workshops and outreach. It’s definitely recommended reading!

There are some caveats to be added with surveys based on automated accessibility testing. One is that ‘ease of detectability’ does not correlate with ‘impact on end users’. There are issues that are easy to detect and issues that impact end users most, these are not necessarily the same. Automated tests also cover only a small part of all accessibility, as some things aren’t detectable by machines (yet, or ever). I’m not suggesting this makes the survey less useful or good, but wanted to call it out explicitly. The ACT-Rules Community Group at the W3C works on harmonising test rules for things that are testable.

Ok, let’s look at the top issues and how developers, browsers and CMSes can take away barriers today. Some of these include ideas about what users can do (important caveat: none of this should be user responsibility, website owners should not expect users to use or know about these tools).

Low text contrast

There are cases where text colour and the background colour have a ratio lower than the threshold in WCAG (see also MDN on contrast).

Designers can check contrast manually install plugins (using a tool like Contrast Ratio) or install a plugin like Stark for Figma or Sketch.

Developers can use an automated contrast checker to make sure you avoid low contrast text. Run a checker like the one in Firefox Dev Tools Accessibility Panel or axe in CI/CD, or paste two colours into a manual tool like Contrast Ratio.

Designers and developers alike can use Polypane’s contrast checker that suggests accessible alternatives, which makes it a lot easier to not just find the issue, but also fix it while you’re at it.

Users could use a plugin like Fix Contrast to not be affected: it tweaks colours on the fly so that you don’t have to suffer low contrast text.

There are some discussions on new colour contrast algorithms for WCAG, but this is still under discussion and not ready any time soon.

Missing alternative text

When you create content, describe your images. In your CMS, on Twitter and even in GitHub issues: use that alternative text feature, so that users who can’t see the image can access the content in them. On platforms that don’t support alternative text, like Slack or mobile LinkedIn (!), you can describe images in text. If you choose a CMS or content platform, ensure it can handle alternative text or set it up to do so.

In the resulting HTML, you’ll want something like:

<!-- image with text -->
<img src="website-logo.png" alt="hiddedevries.nl" />

<!-- image with redundant content -->
<img src="hidde.png" alt="" /> 
<p>Photo of Hidde</p>

You can make your decisions on alternative text using the Alt Decision Tree, but basically the gist is that if you were to replace your image with a square, what would you write in the square for it to still be useful? Leaving it empty is an option if that’s the most useful alternative for the image. Like in the example above, there is a photo with a paragraph underneath that describes it. In this case, writing “Hidde” or “Photo of Hidde” in the alt attribute is redundant, it would be best to use an empty alt (but do leave the attribute in there, or some browsers will use the image URL as an alternative).

Users can use Microsoft Edge, which fills in missing alternatives. AI aren’t very good at intentions or context, but pretty much perfect at recognising text. Next time a news website posts an image of new covid rules with no alternatives (as the main Dutch news website used to do throughout the pandemic), users of Edge can follow along.

Empty links and buttons

When links, buttons or other interactive elements don’t have names, assistive technologies like screenreaders or voice controls have no way to uniquely refer to them. If it is to be interacted with, it needs a name.

Imagine the difference between a screenreader saying “here's 4 buttons: button, button, button and button”, versus “here's 4 buttons: publish content, delete content, change to draft, upload image”. In the first instance, you'd need to press them before you know what they do, in the second, it is clear what you're in for, with no further context needed.

Names are derived from text content, like the actual text that’s inside a button, or can be added through an attribute. See Naming things to improve accessibility for more detail or the spec that defines how controls get their names.

Developers need to ensure all controls they build (links, buttons, form fields, etc) have names, ideally that make sense out of context:

<!-- names that make sense out of context -->
<button>Submit form</button>
<button>Publish content</button>
<button>Expand filters</button>
<a href="//wikipedia.org">Wikipedia</a>
<a href="//twitter.com">Hidde on Twitter</a>

<!-- names that are confusing -->
<a href="/">click here</a><!-- avoid -->
<a href="/">read more</a><!-- avoid -->

<!-- names that are missing; avoid or add a name -->
<a href="//twitter.com/"><svg/></a><!-- avoid -->
<a href="//linkedin.com"><img src="" alt="" /></a><!-- avoid -->
<button><img/><button><!-- avoid -->

Browsers can sometimes derive names from nearby text, some do this when there is no text to derive a name from. This is not ideal, can lead to wrong and confusing guesses and be bad end user experience. The developer of this control will know best what the thing does and therefore how it should be named.

Missing form labels

Form labels kind of fall under naming things, as they name form elements specifically.

Developers can fix this by ensuring form fields have a <label> element of which the for attribute points to the id of the input/select/textarea , this also makes that clicking label moves the cursor to the input:

<!-- “for” and “id” are same, this connects them -->
<label for="field">Address</label>
<input id="field" />

They can also add an aria-label attribute to the input to name it that way (but be careful, ARIA labels don’t get translated well).

Missing languages

Proper language indication can get you a Pass on two (!) WCAG Success Criteria (3.1.1 and 3.1.2), and you only need to know one attribute for it.

Developers should ensure the <html> element has a lang attribute with the right language:

<!-- marks this document as 'in English -->
<html lang="en">

Sometimes this is forgotten as the <html> element lives in some template you never touch, but it’s not hard to do, so always double check that this attribute exists and is set to the right language.

If there is content on part the page that is in another language, mark that too, again, with a lang attribute on the relevant DOM node. When you pick a plugin for internationalisation, ensure it sets the lang s or makes it easy for you to do so.

CMSes can make sure that lang attributes are set and set correctly. Browsers can guess languages, but they aren’t always good at this, specifically when it comes to distinguishing dialects: they often matter a lot to people, less so to machines.

Wrapping up

These are some tips based on the most common issues that WebAIM Million 2022 identified. Let’s all put in the work to make sure we, our colleagues, our clients and our users avoid these issues. Like, actually. We need WCAG auditors to focus on higher hanging fruit, by fixing the lower hanging stuff for good.

If this is all new to you, hi, thanks for reading! I hope this helps and feel free to get in touch with questions. If you already knew all of this, please keep spreading the word, so that in next year’s survey, we’ll see steady improvements for the web at large.

Want to learn more about fixing low hanging fruit accessibility issues? In response to the same survey, Christian Heilmann blogged about how to fix accessibility issues using your browser

Comments, likes & shares (89)

Nir Horesh, Matthias Andrasch, darkaesthetics, razh, John Turner, Tom 🇺🇦🌾, Prasanna Venkatesh, Niels van Midden, Marco Kühbauch, Laura Whitehead, Cos, knut, A11y Up, Swetha P, aga naplocha, Núria Peña, muan, jv, Zeeshan 🌌⠕, Sindre Gulseth, Kons Ti, Kẹ́hìndé Adélékè, John Allsopp, Henk Boelman 🥑 ✈ #DevSum, Saptak S, Claudia 🦁, Dietmar Gigler, Віталій Бобров 🇺🇦💗🛡️⚔️, Tom Forrer, Tanner Hodges, blank, This Miss Molly, Aaron Gustafson, Meagan Eller, Patrick Sanwikarja, ioana 👩‍💻🦊✨, Baba, Mauricio Palma, Manuel Matuzović and Della 🌱 liked this

Kẹ́hìndé Adélékè, Matthias Andrasch, Chee Aun 🫰, knut, Laura Whitehead, Henk Boelman 🥑 ✈ #DevSum, Stefan Judis, Michael Scharnagl, Swetha P, tanvi.css, Ritik, Nik, Joke Van Hamme, //.\, Calum Ryan - calumryan.com, Claudia 🦁, Tom Forrer, A11y Up, George Salib®, E.L. Guerrero, Patrick Sanwikarja, Aaron Gustafson, Blair and Mauricio Palma reposted this

Just read: "Common accessibility issues that you can fix today" hidde.blog/common-a11y-is…
📝 Common accessibility issues that you can fix today 🔗 hidde.blog/common-a11y-is… #html #css #javascript #webdev
Common accessibility issues that you can fix today | hidde.blog hidde.blog/common-a11y-is…
Common accessibility issues that you can fix today | hidde.blog hidde.blog/common-a11y-is…
Another good one! Common accessibility issues that you can fix today. #a11y hidde.blog/common-a11y-is…
Hmm, it's just a common a11y issue that you can fix it by NOW, yes NOW hidde.blog/common-a11y-is…
Common accessibility issues that you can fix today: hidde.blog/common-a11y-is… #accessibility #a11y
Common accessibility issues that you can fix today hidde.blog/common-a11y-is… #webdev #a11y
Common accessibility issues that you can fix today, by @hdv hidde.blog/common-a11y-is…
"Common accessibility issues that you can fix today" ... hidde.blog/common-a11y-is…
hidde.blog/common-a11y-is… t.me/scumdograscalh…
简单的方法就能轻易解决

WebAIM已发布最新报告。通过自动检测的方法检测网站,报告针对100万个网站上出现的可用性问题进行了分析。其中哪些问题是可轻而易举改正的呢?

扩展阅读

WebAIM,是一家总部位于美国犹他州的非营利组织。自2019年,启动WebAIM Million’项目。每年发布综合分析报告,观察互联网可用性的发展趋势和改善/下降。
报告内容很有见地。值得推荐阅读!

基于自动可用性检测而进行调查,需要加上以下警告:

一是“易于感知的问题”和“对用户造成影响的问题”,两者无关,是不一样的。自动化测试也只涵盖了所有互联网可用性中的一小部分,因为有些问题机器(现在或永远)无法检测。我并不是说这会降低调查的作用,而是想明确指出这一点。W3C的ACT-Rules 组织致力于指定合理的测试规则。

好的,让我们看看当今最热门的问题以及开发人员、浏览器和 CMS 是如何解决问题的。

低文本对比度

在某些情况下,文本颜色和背景颜色的对比度低于WCAG阈值(另请参见MDN on contrast)。

通过安装插件(如:Contrast Ratio 设计师可以检查对比度。

开发人员可以使用自动对比度检查器,来确保避免使用低对比度文本。运行一个检查器,如Firefox 开发工具辅助功能面板中的检查器或CI/CD 的ax,或者将两种颜色粘贴到一个手动工具中,如 Contrast Ratio。

设计人员和开发人员都可以使用 Polypane 的对比度检查器,它会给出替代方案建议,这不仅可以更轻松地找到问题,还可以同时修复问题。

用户可以使用像Fix Contrast这样的插件:它可以即时微调颜色,这样就不必忍受低对比度文本。

针对网页内容无障碍指南的新颜色对比度算法之一问题,人们进行诸多讨论,目前讨论仍在进行中。

缺少替代文字

当你创建内容,对图片进行描述。在使用Twitter的内容管理器,甚至在GitHub上发布帖子:使用替代文本功能,以便看不到图像的用户可以访问图片的替代文本。在不支持替代文本的平台上,例如 Slack 或移动 LinkedIn (!),可以用文本描述图像。如果您选择 CMS 或内容平台,确保它可以处理或设置使用替代文本。

生成的 HTML 如下:

<!-- image with text -->
<img src="website-logo.png" alt="hiddedevries.nl" />

<!-- image with redundant content -->
<img src="hidde.png" alt="" /> 
<p>Photo of Hidde</p>

你可根据Alt Decision Tree书写替代文本。文本内容的要点是,如果图像的位置显示出一个正方形,在正方形中写什么以使其不影响阅读?可以选择将其留空。就像上面的例子一样,有一张照片,下面有一段描述它的段落。在这种情况下,在alt属性中写“Hidde”或“Hidde 的照片”是多余的,最好使用一个空的alt(但不要将属性保留在那里,否则某些浏览器会使用图像 URL 作为替代)。

用户可以使用 Microsoft Edge,它可以填补缺失的替代文本。AI 不擅长理解意图或背景,但精通识别文本。下次新闻网站再发布新冠病毒防治新规则的图片,并不带有替代文本时(就像荷兰主要新闻网站在整个疫情期间所做的那样),Edge 的用户可以理解其内容。

空链接和按钮

当链接、按钮或其他交互元素没有名称时,屏幕阅读器或语音控制等辅助技术无法唯一识别它们。如果要与之交互,则需要给它们定义一个名称。

屏幕阅读器说“这里有 4 个按钮:按钮、按钮、按钮和按钮”与“这里有 4 个按钮:发布内容、删除内容、更改为草稿、上传图像”,想象一下两者之间的区别。在第一种情况下,需要按一下按钮才知道按钮的用处;在第二种情况下,不需要任何额外操作。

名称源自文本内容,例如按钮内的实际文本,或者可以通过属性添加。有关更多详细信息,请参阅命名以提高可访问性控件命名规范

开发人员需要确保他们构建的所有控件(链接、按钮、表单字段等)都有名称,最好是有独立意义:

<!-- names that make sense out of context -->
<button>Submit form</button>
<button>Publish content</button>
<button>Expand filters</button>
<a href="//wikipedia.org">Wikipedia</a>
<a href="//twitter.com">Hidde on Twitter</a>

<!-- names that are confusing -->
<a href="/">click here</a><!-- avoid -->
<a href="/">read more</a><!-- avoid -->

<!-- names that are missing; avoid or add a name -->
<a href="//twitter.com/"><svg/></a><!-- avoid -->
<a href="//linkedin.com"><img src="" alt="" /></a><!-- avoid -->
<button><img/><button><!-- avoid -->

浏览器有时可以从附近的文本中节选名称。这并不理想,可能会导致错误和令人困惑的猜测,导致用户体验糟糕。开发人员最清楚控件的作用并能命名它。

缺少表单标签

表单标签受命名影响,因为表单单独命名表单元素。

开发人员设置表单输入框的for属性并指向input/select/textareaid,可以解决此问题,这也使得单击标签将光标移动到输入狂

<!-- “for” and “id” are same, this connects them -->
<label for="field">Address</label>
<input id="field" />

他们还可以给输入框添加一个aria-label属性(注意,ARIA 标签解析得不好)。

缺少表格标签

开发人员应确保元素具有 lang 属性,并使用正确语言:

<!-- marks this document as 'in English -->
<html lang="en">

有时有忘记,因为<html> 元素存在于哪些从未修改过的模板中,但这并不难,因此请务必仔细检查此属性是否存在并设置为正确的语言。

如果页面的一部分内容是另一种语言的,在相应DOM节点元素上再次设置lang属性。当使用国际化的插件时,确保设置了 langs 。

CMS可以确保 lang 属性的正确设置。浏览器可以猜测语言,但也有可能出错,特别是在区分方言时:它们通常对人很重要,而对机器则不那么重要。

原文地址:https://hidde.blog/common-a11y-issues/

Common accessibility issues that you can fix today | hidde.blog hidde.blog/common-a11y-is…
Common accessibility issues that you can fix today hidde.blog/common-a11y-is… #NAGWGoodies
Appreciate this succinct #accessibility checklist from @hdv with links to plugins for designers. 👏 hidde.blog/common-a11y-is…
#Accessibility Common accessibility issues that you can fix today hidde.blog/common-a11y-is…
Interesting article on findings from a @webaim report on trends and improvements/decline in web accessibility over time. What common accessibility issues can you fix today? hidde.blog/common-a11y-is…
Does your #website follow #accessibility standards? Check out these common accessibility issues that can be fixed right now! @hdv #design hidde.blog/common-a11y-is…
"Common accessibility issues that you can fix today" ➡️ hidde.blog/common-a11y-is… #Accessibility #Frontend #WebDevelopment
"Common accessibility issues that you can fix today” (via @hdv) #a11y Part 1: hidde.blog/common-a11y-is… Part 2: hidde.blog/more-common-a1…
These are some great a11y tips, and great explanations/examples too!

https://hidde.blog/common-a11y-issues/
https://hidde.blog/more-common-a11y-issues/

See also: https://www.a11yproject.com/checklist/

@omgmog lol what a coincidence, I just finished reading both articles! One of the points in the focus paragraph made me realize I have to move my hidden rel="me" links: they are present when pressing Tab, but they don't have focus in the page and it's confusing...

@m2m You should be alright if you set aria-hidden=true on those elements: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden

aria-hidden - Accessibility | MDN
thanks Hidde for sharing!
hidde.blog/common-a11y-is… #accessibility #a11y