如何让代码更易于维护

by Jaroslav Vaňkát

通过JaroslavVaňkát

如何轻松地使您的网站更易于访问 (How you can easily make your website more accessible)

As a designer, developer, or even product manager, you have thousands of responsibilities. Every project requires a lot of attention — desktop layout, mobile layout, iPhone X layout (thanks, Apple), IE support, Safari support…

作为设计师，开发人员甚至产品经理，您负有成千上万的责任。 每个项目都需要大量关注-桌面布局，移动布局，iPhone X布局(感谢Apple)，IE支持，Safari支持…

那么，为什么要关心可访问性呢？ (So why should you care about accessibility?)

Here are some hard facts:

以下是一些困难的事实：

• About 15% of the world’s population lives with some form of disability, of whom 2–4% experience significant difficulties in functioning. (World Health Organization)

  世界上约有15％的人口患有某种形式的残疾，其中2-4％的人在运作方面遇到重大困难。 ( 世界卫生组织 )

• Everybody is sometimes temporarily disabled — in a sense — whether you cut your finger or you try to read on your low contrast screen on a sunny day.有时，从某种意义上来说，每个人有时都暂时处于残疾状态，无论您是割断手指还是尝试在晴朗的一天在低对比度屏幕上阅读。
• In certain cases, accessibility might be required by law.在某些情况下，法律可能要求可访问性。

And most important of all:

最重要的是：

Everybody is a keyboard user when they are eating with their mouse hand.

每个人用鼠标吃饭时都是键盘用户。

— Adrian Roselli

—阿德里安·罗塞利(Adrian Roselli)

By improving the accessibility of your website, you don’t only support disabled people. You will simply make it more usable for everyone.

通过改善网站的可访问性，您不仅支持残疾人。 您将使它对每个人都更有用。

不要重新发明轮子 (Don’t reinvent the wheel)

We at Site Search 360 have developed a plugin that allows our customers to easily integrate our search solution into an existing website.

我们在Site Search 360中开发了一个插件，使我们的客户可以轻松地将我们的搜索解决方案集成到现有网站中。

As we’ve grown bigger, it was clear to us that we needed to make an accessibility audit. Yes, we should have considered accessibility from the start of the project, but it’s never too late.

随着我们变得越来越大，对我们来说很明显，我们需要进行可访问性审核。 是的，我们应该从项目开始就考虑可访问性，但是永远不会太晚。

You don’t simply “turn on” accessibility.

您不只是简单地“打开”辅助功能。

But don’t worry. Even if you have never thought about accessibility in your current project, it won’t take long to make some improvements. I can’t tell you the exact amount of time we spent making our plugin more accessible, but it wasn’t more than few work days (and about 30 commits).

但是不用担心。 即使您从未考虑过当前项目中的可访问性，也不会花多长时间进行一些改进。 我无法告诉您确切的时间，我们花了很多时间使我们的插件更易于访问，但这不超过几个工作日(大约30次提交)。

I will now illustrate the whole process (based on our JavaScript plugin, not a website), so you don’t have to start from the very beginning. But first:

现在，我将说明整个过程(基于我们JavaScript插件，而不是网站)，因此您不必从头开始。 但首先：

什么是辅助功能？ (What is accessibility?)

Before you get to work, you have to understand what accessibility is actually about. I’m not going to bother you with long definitions. This short sentence summarizes accessibility as I think of it:

在开始工作之前，您必须了解实际的可访问性。 我不会用冗长的定义来打扰您。 我认为这句话简短概括了可访问性：

Accessibility is the art of making your product usable by everyone.

可访问性是使您的产品可供所有人使用的艺术。

Who is everyone? What kinds of disabilities should you consider?

谁啊 您应该考虑哪种残疾？

• Blindness and colorblindness失明和色盲
• Cognitive disabilities认知障碍
• Physical disabilities身体残疾
• Hearing disabilities (yes, your video needs subtitles)听力障碍(是的，您的视频需要字幕)
• Age年龄

一些简单的步骤 (Some easy steps)

Now that you know for whom you are improving your website, we can start looking at the basic concepts of an accessible web.

既然您知道要为谁改进您的网站，我们就可以开始研究可访问网络的基本概念。

编写语义标记 (Write semantic markup)

This is probably the most important step. HTML5 has been among us for a few years now, so there is no reason (and no excuse) for not taking advantage of it. Section, article, header, nav, banner and many others — all those tags are there to be used.

这可能是最重要的步骤。 HTML5进入我们已有几年了，因此没有理由(也没有借口)不利用它。 栏目，文章，标题，导航，横幅等-所有这些标签都可以使用。

You’ve probably seen markup like this (I’ve omitted the classes and ids as they don’t have any semantic purpose):

您可能已经看到了这样的标记(我省略了类和id，因为它们没有任何语义目的)：

<div>  <div>Recipes<span>98</span></div>  <div>Menu Items<span>1</span></div>  <div>Grocery Products<span>1</span></div></div>

Believe it or not, this was our content group navigation (you could click one content group and the search result page would automatically scroll to the relevant search results). You wouldn’t guess that, would you?

信不信由你，这就是我们的内容组导航(您可以单击一个内容组，搜索结果页面将自动滚动到相关搜索结果)。 您不会猜到，对吗？

There are few problems with this markup. How can someone who depends on assistive technologies tell this is navigation? They can’t. Is an active element represented by div? Yes, it is.

这个标记几乎没有问题。 依赖辅助技术的人怎么能知道这是导航？ 他们不能。 div代表一个活动元素吗？ 是的。

Look now at the following piece of markup:

现在看下面的标记：

<nav role=”navigation”>  <ul role=”menubar”>    <li>      <button role=”menuitem”>Recipes<span>98</span></button>    </li>    <li>      <button role=”menuitem”>Menu Items<span>1</span></button>    </li>    <li>      <button role=”menuitem”>Grocery Products        <span>1</span>      </button>    </li>  </ul></nav>

Much better, isn’t it? Let’s review the most important concepts of semantic markup:

好多了，不是吗？ 让我们回顾一下语义标记的最重要概念：

• Use semantic elements使用语义元素

• Always use <main role=”main”> to mark main content

  始终使用<main role =“ mai n”>标记主要内容

• Add role attribute to support older browsers

  添加角色属性以支持较旧的浏览器

• Use sections instead of divs where appropriate在适当的地方使用部分而不是div

• Span is not a button — don’t repurpose the meaning of elements (unless absolutely necessary)

  跨度不是按钮 -请勿重新利用元素的含义(除非绝对必要)

• Use buttons for in-page interactions

  使用按钮进行页内互动

• Headings are one of the most important parts of every webpage. Always have a single h1 heading and don’t skip heading levels

  标题是每个网页中最重要的部分之一。 始终只有一个h1标题，不要跳过标题级别

I’m not going to list every change we’ve made (and there are a bunch of them), but you can always ask in the comments.

我不会列出我们所做的每项更改(有很多更改)，但是您始终可以在评论中提出。

What to do: Review your current markup, check the content and heading structure, make sure interactive elements are represented by a button or elements, and use HTML5 semantic tags.

怎么做：查看当前的标记，检查内容和标题结构，确保交互式元素由一个或多个按钮表示，并使用HTML5语义标记。

使用键盘提供所有功能 (Make all functionality available with a keyboard)

This is also an important one. Every single interaction should be possible with a keyboard.

这也是重要的。 每个单独的交互都应该可以通过键盘进行。

Let’s consider an example similar to the previous one. We did have a “Show more results” button that wasn’t actually a button. Can you guess? Yes, it was a styled div.

让我们考虑一个类似于上一个示例。 我们确实有一个“显示更多结果”按钮，但实际上并不是一个按钮。 猜一下？ 是的，这是一个样式化的div 。

Could we support keyboard controls for such an element? Yes, we could, by making it focusable and handling click and keyup events while testing whether the enter or space key was pressed.

我们可以为此类元素支持键盘控件吗？ 是的，我们可以将其变为可聚焦和处理点击 KEYUP事件，而检测是否进入或按下空格键。

Nonetheless, it is still more difficult than simply changing the markup from <div&gt; to <button> — in this case, you just have to bind a click event and don’t have to force the DOM element to be focusable (and as a bonus you don’t have to write that many styles).

尽管如此，这仍然比简单地将标记从<d iv＆g t;更改为更困难。 为<b utton> -在这种情况下，你只是甲肝E要绑定一个click事件，并没有强制的DOM元素要成为焦点(并作为奖金，你不必写很多款式)。

Major takeaways:

主要外卖：

• All functionality should be accessible by keyboard所有功能都可以通过键盘访问

• Do not remove outlines from focused elements (if you don’t like those outlines, you can always style them)

  不要从关注的元素中删除轮廓(如果您不喜欢这些轮廓，则可以随时对其进行样式设置 )

• In-page interactions should be represented by a button

  页内互动应以按钮表示

• Off-page interactions (links) should be represented by an anchor (<;a>)

  页外互动(链接)应以锚点( < ; a>)表示

• * Buttons are meant to be triggered by a click, enter, and space, anchors by click and enter press*按钮是由单击，输入和空格触发的，由单击和输入按下的锚定

What to do: Make sure all interactive elements are accessible (and controllable) by keyboard, focused elements are highlighted, and the tab order actually makes sense.

怎么做：确保所有交互元素都可以通过键盘访问(和控制)，突出显示突出显示的元素，并且按Tab键排序实际上是有意义的。

支持屏幕阅读器 (Support screen readers)

Take a look at the following image:

看一下下面的图片：

It should be easy to tell what the button in the top right corner does. It closes the layer. The next image simulates what a blind person would be able to “see” when using a screen reader software:

应该很容易分辨出右上角的按钮的作用。 它关闭层。 下一张图像模拟了使用屏幕阅读器软件时盲人能够“看到”的内容：

You’ve already seen the full image, so you know what action the same button is meant to perform. Would you be able to tell by looking at the second image? You wouldn’t — the cross is rendered using a background-image CSS property and the button has no inner content at all.

您已经看过完整图像，因此您知道同一按钮应执行的操作。 您能通过看第二张图像来分辨吗？ 您不会—十字架使用背景图像CSS属性进行渲染，并且按钮根本没有内部内容。

That’s what aria-* attributes are for. By enhancing the button’s markup with a simple aria-label attribute, you don’t have to try hard to make the button’s inner text be hidden in your presentation layer.

这就是aria- *属性的用途。 通过使用简单的aria-label属性增强按钮的标记，您不必费劲使按钮的内部文本隐藏在表示层中。

<!-- Wrong markup --><button></button>

<!-- Accessible markup --><button aria-label=”Close layer”></button>

<!-- Alternative accessible markup --><button style="text-indent:100%;overflow:hidden;padding:0;white-space:nowrap;">Close layer</button>

Did you notice that I also removed the images from the screen reader view? You can label them too using the same technique (where aria-labeledby might be more appropriate). I removed those images because in our case they do not have any semantic purpose and are tagged with role=”presentation”. Even if they did have a semantic purpose, we don’t usually know that. Most of these images will be illustrational, and labeling them would be redundant — the heading already carries the same meaning.

您是否注意到我也从屏幕阅读器视图中删除了图像？ 您也可以使用相同的技术对其进行标记(其中aria-labeledby可能更合适)。 我删除了这些图像，因为在我们的例子中，这些图像没有任何语义目的，并被标记为role =“ presentation” 。 即使它们确实具有语义目的，我们通常也不知道。 这些图像大多数都是说明性的，为它们加上标签将是多余的-标题已经具有相同的含义。

Attributes you should know:

您应该知道的属性：

• role — useful for marking the purpose of an element

  角色 -用于标记元素的用途

• aria-hidden — tells assistive technologies to ignore an element

  咏叹调隐藏 -告诉辅助技术忽略一个元素

• aria-label, aria-labeledby — label the element

  aria-label，aria-labeledby —标记元素

• aria-describedby — use this to describe non-standard user interface controls

  aria- describeby —使用此描述非标准的用户界面控件

• aria-owns — marks a relation between two elements

  aria-owns-标记两个元素之间的关系

What to do: This step might be the hardest to implement correctly and test properly. Make sure all images have an alt attribute, all sections and interactive elements are labeled, and test with screen reader software.

做什么：此步骤可能是最难正确实施和正确测试的步骤。 确保所有图像都具有alt属性，所有部分和交互式元素均已标记，然后使用屏幕阅读器软件进行测试。

How to test: Using a screen reader as a sighted person might not feel natural, so first take some time and familiarize yourself with the software of your choice (and you might want to test all of the most common ones — VoiceOver on Mac, NVDA, and Jaws on Windows and TalkBack on Android). After this try navigating your website only using the screen reader software (turn off your monitor). Even a short test will help you get an idea how well your website performs and will reveal the most significant problems.

测试方法：以屏幕阅读器为视力障碍者可能会感到不自然，因此，请花一些时间并熟悉所选的软件(您可能希望测试所有最常见的软件-Mac上的VoiceOver ， NVDA ，以及Windows上的Jaws和Android上的TalkBack )。 此后，请尝试仅使用屏幕阅读器软件浏览您的网站(关闭显示器)。 即使是简短测试，也可以帮助您了解您的网站的运行情况，并发现最严重的问题。

Bonus: Here is a short (and a bit simplified) example of how we’ve enhanced our autosuggestions. The highlighted parts (and the two <spans>) were added as part of our accessibility improvements.

奖励：这是一个简短(略微简化)的示例，说明了我们如何增强自动建议。 添加了突出显示的部分(和两个<spa ns>)作为我们可访问性改进的一部分。

<!-- Search Field --><input type="text" placeholder="search something"   autocomplete="off"   role="combobox"   aria-describedby="unibox-controls-description"   aria-owns="unibox-suggest-box"   aria-expanded="true"  aria-activedescendant="unibox-active">

<!-- Search Suggestions --><div id="unibox-suggest-box" role="listbox">;  <section aria-labelledby="unibox-suggest-cluster-heading-recipes">    <h3 id="unibox-suggest-cluster-heading-recipes"&gt;Recipes</h3>    <div aria-selected="false" role="option">      <img src=[...]         alt=""         aria-hidden="true"         role="presentation">      </div>      <;a href=[..]>Chicken Curry</a>    </div&gt;    <div aria-selected="true" role="option" id="unibox-active">      <img src=[...]         alt=""         aria-hidden="true"         role="presentation"&gt;      </div>      <a href=[..]>Curried Chicken</a>    </div>  </section>  </div>

<!-- Announce search suggestions have been changed --><span aria-live="polite" aria-atomic="true" role="status" class="ss360-sr-only">2 Search Suggestions Shown</span>

<!-- Suggest Box User Interface Controls --><span id="unibox-controls-description" class="ss360-sr-only">Use up and down arrows to select available result. Press enter to go to the selected search result.</span>

简化演示 (Simplify presentation)

Accessibility, UI Design, UX — all of those are sides of the same three-sided coin.

辅助功能，UI设计，用户体验-所有这些都是同一个三面硬币的一面。

Low contrast between background and foreground will make your text hard to read.

背景和前景之间的对比度低会使您的文本难以阅读。

Wild animations make your website hard for hungover people (you don’t care? Think about those with ADHD instead — they may find it difficult to focus). Did you know that there is a prefers-reduced-motion media query (even though it is not widely supported yet)? You can simply turn off all your animation if this media query is set. Here is how we do it:

狂野的动画使您的网站对宿醉的人来说很难(您不在乎？请考虑使用ADHD的人-他们可能会发现难以集中注意力)。 您是否知道存在“ 偏好减少运动”媒体查询(即使尚未得到广泛支持)？ 如果设置了此媒体查询，则只需关闭所有动画即可。 这是我们的方法：

if(window.matchMedia &&   window.matchMedia("(prefers-reduced-motion: reduce)").matches){    animationSpeed = 0;}

You don’t think a website should be some kind of crazy stroboscopic light show, do you?

您不认为网站应该是某种疯狂的频闪灯表演，是吗？

Conveying information only by color will make the information unavailable for colorblind people.

仅按颜色传达信息将使色盲人无法获得该信息。

Here is an example of how we’ve changed the default layout of our layover view — shorter blocks of text and higher contrast ratios.

这是一个示例，说明了如何更改叠加视图的默认布局-较短的文本块和较高的对比度。

One of our pain points has always been mobile autosuggestions. This might be less of an accessibility issue, but we’ve finally added an option to switch to full-screen autosuggestions. Here is a comparison:

我们一直以来的痛点之一就是移动自动提示。 这可能不是一个可访问性问题，但是我们终于添加了一个选项，可以切换到全屏自动建议。 比较一下：

What to do:

该怎么办：

• Check that blocks of text are not wider than 80 characters and use line-height that is about 1.5 times larger than the font-size (which should also be large enough — go for 16 px and larger)

  检查文本块的宽度不超过80个字符，并使用比字体大小大约大1.5倍的行高 (也应该足够大-请输入16 px或更大)

• Allow zooming (at least up to 200%)允许缩放(至少200％)

• Check your contrast ratios

  检查您的对比度

• Make sure your touch targets are large enough (44 x 44 pixels is the rule of thumb)确保您的触摸目标足够大(44 x 44像素是经验法则)
• Where color conveys information, make sure that there is also an alternative way to get the same information当颜色传达信息时，请确保还有另一种方式来获取相同的信息
• Go through your animations and consider whether you really need them. Also provide a mechanism to turn them off.浏览动画，然后考虑是否确实需要它们。 还提供了将其关闭的机制。
• Forget about captchas…忘记验证码…

评估，发展和集成您的工作流程 (Evaluate, evolve, and integrate your workflow)

This one is only here because “5 steps” sounds better than “4 steps.” Regardless, always focus on accessibility in your daily (or at least weekly) workflow.

仅在这里是因为“ 5步”听起来比“ 4步”好。 无论如何，在您每天(或至少每周一次)的工作流程中始终要专注于可访问性。

You won’t have to spend large amounts of your budget to do this the right way. So when planning a new feature, think of all the groups I’ve named in the “What is accessibility?” part of this article.

您无需花费大量预算即可正确执行此操作。 因此，在计划新功能时，请考虑一下我在“什么是可访问性？”中命名的所有组。 本文的一部分。

测试中 (Testing)

There are plenty of tools that will help you evaluate how accessible your website is. I would recommend Tenon.io, FAE, and Lighthouse for Google Chrome (open Dev Tools, go to Audits, and click ‘Perform an audit…’).

有很多工具可以帮助您评估网站的可访问性。 我会推荐Tenon.io ， FAE和Lighthouse用于Google Chrome(打开Dev Tools，转到Audits ，然后单击“ Perform a audit…”)。

However, some things are hard to evaluate with automated tools. Try operating your website using only a keyboard. Then try operating it using screen reader software.

但是，使用自动化工具很难评估某些事情。 尝试仅使用键盘操作您的网站。 然后尝试使用屏幕阅读器软件对其进行操作。

其他来源 (Additional Sources)

There is much more to accessibility than this post could cover. So here are few resources that might help you get a deeper understanding of the subject:

可访问性远远超出了此职位所能涵盖的范围。 因此，这里有一些资源可以帮助您更深入地了解该主题：

• How to Meet WCAG 2.0

  如何满足WCAG 2.0

• WAI Tutorials

  WAI教程

• Inclusive Design Checklist

  包容性设计清单

• A nice article by the Freecodecamp stuff

  Freecodecamp上的一篇不错的文章

TL; DR (TL;DR)

Use semantic markup, support screen readers, make all interactive elements accessible by keyboard, simplify your presentation, and read at least all the bullet points in “Some easy steps”.

使用语义标记，支持屏幕阅读器，使所有交互元素都可以通过键盘访问，简化您的演示文稿并至少阅读“一些简单步骤”中的所有要点。

Ok, that’s it. If you are interested in the exact changes we’ve made, just ask in the comments. And if you are looking for a site search solution that cares about accessibility (or simply for a Google Site Search alternative) Site Search 360 is there for you.

好的，就是这样。 如果您对我们所做的确切更改感兴趣，只需在评论中提出即可。 而且，如果您正在寻找一个关注可访问性的站点搜索解决方案(或仅用于Google Site Search替代方案)， Site Search 360就是您的理想之选 。

And don’t forget to clap.

并且不要忘记鼓掌。

翻译自: https://www.freecodecamp.org/news/how-you-can-easily-make-your-website-more-accessible-88dc7db90bd2/

如何让代码更易于维护