残疾人软件开发

by Scott Vinkle

由Scott Vinkle

更高级别的可访问性：我使freeCodeCamp指南对残疾人更有用的5种方式 (Next Level Accessibility: 5 ways I made the freeCodeCamp Guide more usable for people with disabilities)

I spent the majority of Hacktoberfest 2017 working with some great folks over at freeCodeCamp. My focus was specifically on helping to bring the accessibility of their Guide site to the next-level.

我花了广大Hacktoberfest 2017年工作超过一些伟大的人freeCodeCamp 。 我的重点是专门帮助将其Guide网站的可访问性提升到一个新的水平。

The first time I saw the site I knew it would be a fantastic resource for lots of people out there, so I took on the challenge to help ensure its usability was top notch for everyone!

我第一次看到该网站时，我知道对于很多人来说，这将是一个绝佳的资源，因此我接受了挑战，以确保其可用性对每个人都是一流的！

Working on the site was also a lot of fun as it’s built with React, so this brought a few extra coding challenges along the way.

使用React构建的站点上的工作也很有趣，因此在此过程中带来了一些额外的编码挑战。

Let’s check out the 5 issues that I found and how I addressed them, together!

让我们一起检查发现的5个问题以及如何解决这些问题！

辅助功能改进1：跳过导航链接不可用 (Accessibility Improvement 1: Skip navigation link unavailable)

One of the first things I check for on a site is if there’s a skip navigation link available. Skip navigation links are a small but handy feature for any site to have for keyboard-only or screen reader users. Why?

我要在网站上检查的第一件事是是否存在跳过导航链接。 对于仅键盘用户或屏幕阅读器用户而言，跳过导航链接是任何站点的一个小巧方便的功能。 为什么？

问题 (The problem)

Without a skip navigation link, people using just the keyboard to navigate would need to Tab through each link in the sidebar every time the page reloads. Since there’s a lot links available, navigating through this section would be cumbersome.

如果没有跳过导航链接，则每次页面重新加载时，仅使用键盘进行导航的人就需要在侧栏中的每个链接之间进行Tab切换。 由于有很多可用的链接，因此浏览本节将很麻烦。

解决方案 (The Solution)

Implementing a skip navigation link is quite simple. It’s usually the first item in the DOM (Document Object Model) and on click, keyboard focus is sent to the page element which contains the primary content of the page.

实现跳过导航链接非常简单。 它通常是DOM(文档对象模型)中的第一项，并且在单击时，键盘焦点将发送到包含页面主要内容的页面元素。

The link I added was coded as:

我添加的链接被编码为：

<a className='skip-link sr-only sr-only-focusable' href='#main'>  Skip to main content</a>

The #main value in the href attribute sends the keyboard focus to the page element which features the id="main" attribute.

href属性中的#main值将键盘焦点发送到具有id="main"属性的page元素。

In order for this page element to receive keyboard focus, I needed to add a tabindex attribute to the container:

为了使该页面元素能够获得键盘焦点，我需要向容器添加一个tabindex属性：

<main className='main' id='main' tabIndex='-1'>  { props.children() }</main>

Adding the tabindex value of -1 allows a non-focusable element to programatically receive focus, but is left out of the natural tab order.

将tabindex值添加为-1可以使不可聚焦的元素以编程方式接收焦点，但不包含自然的Tab顺序。

结果 (The result)

With the skip navigation in place, people using a keyboard can skip repeated regions like the side navigation area to easily reach the main content section.

有了跳过导航，使用键盘的人就可以跳过重复的区域，例如侧面导航区域，以轻松到达主要内容部分。

Check out the full code change in the PR (Pull Request): Added skip link #4175.

在PR(拉动请求)中查看完整的代码更改： 添加了跳过链接＃4175 。

辅助功能改进2：搜索字段缺少标签 (Accessibility Improvement 2: Search field missing label)

I noticed the search input field was missing a label. Having an associated label for each form input is key to a successful user experience. Why?

我注意到搜索input字段缺少label 。 每个表单input都有关联的label是成功用户体验的关键。 为什么？

问题 (The problem)

When input fields are missing a label, screen readers are unable to accurately describe what the intended purpose of the field is for. Imagine for a moment a link with no text; what does this link do?

当input字段缺少label ，屏幕阅读器将无法准确描述该字段的预期目的。 想象一下没有文字的链接； 这个连结有什么用？

解决方案 (The solution)

This one was fairly straight-forward. Adding a label to an input is a matter of creating the label element with a for attribute, then associating it with an input with an id.

这是相当简单的。 向input添加label是创建带有for属性的label元素，然后将其与具有id的input关联的问题。

In order to not disrupt the current design of the site, I also added the srOnly prop to have the label be visually hidden.

为了不干扰网站的当前设计，我还添加了srOnly道具以使label在视觉上隐藏。

The label was coded as:

label编码为：

<ControlLabel htmlFor='searchInput' srOnly={ true }>  Search</ControlLabel>

Then for the existing input control, I simply added the id='searchInput' prop.

然后对于现有的input控件，我仅添加了id='searchInput' 。

结果 (The result)

Now when screen reader users navigate to the Search field, they’ll hear the label value of “search” and have more context of what is expected.

现在，当屏幕阅读器用户导航到“搜索”字段时，他们将听到“搜索”的label值，并且对预期内容有了更多的了解。

Check out the full code change in the PR: Search input a11y updates #4123.

在PR中查看完整的代码更改： 搜索输入a11y更新＃4123 。

辅助功能改进3：侧边栏角色调整 (Accessibility Improvement 3: Sidebar role adjustments)

When inspecting the HTML source, I noticed some of the sidebar elements incorrectly featured role="presentation" attributes. I also noticed some elements were marked up as divs instead of appropriate, semantic markup. This needed some adjustment. Why?

在检查HTML源代码时，我注意到某些侧边栏元素的role="presentation"属性具有错误的特征。 我还注意到有些元素被标记为div而不是适当的语义标记。 这需要一些调整。 为什么？

问题 (The problem)

Two issues existed with this section of the site:

该站点的此部分存在两个问题：

1. When you apply role="presentation" onto an element, this removes all semantic meaning. In other words, when a screen reader encounters the element, there is no meaningful announcement to notify the user what the element is for. Imagine a link on a page, but its text is the same color as the content text and with no underline. How would you know it was a link?

   当您将role="presentation"应用于元素时，这将删除所有语义。 换句话说，当屏幕阅读器遇到该元素时，没有有意义的通知来通知用户该元素的用途。 想象一下页面上的链接，但是其文本与内容文本的颜色相同，并且没有下划线。 您怎么知道这是一个链接？

2. The other issue here is when div elements are used to markup meaningful structure. As you may know, div elements have no semantic meaning and are typically reserved to create structure on a page. In cases where they’re used in place of natively semantic elements, you’d need to apply the appropriate role attribute to convey this meaning.

   这里的另一个问题是使用div元素标记有意义的结构时。 如您所知， div元素没有语义，通常保留用于在页面上创建结构。 如果使用它们代替本机语义元素，则需要应用适当的role属性来传达此含义。

解决方案 (The solution)

1. For each navigation list item and link, I simply removed the role prop in order to allow the semantic meaning to shine through for screen reader users.

   对于每个导航列表项和链接，我只是删除了role道具，以使语义含义对屏幕阅读器用户有所帮助。

2. For dynamic components which generated div elements, I applied appropriate role props, including role="list" for the PanelGroup component, and role="listitem" for any instances of the Panel component.

   对于生成div元素的动态组件，我应用了适当的role道具，包括PanelGroup组件的role="list"和Panel组件的任何实例的role="listitem" 。

结果 (The result)

With the role props adjusted, screen reader users will hear clear and precise announcements when encountering these elements, including:

通过调整role道具，屏幕阅读器用户在遇到这些元素时将听到清晰准确的通知，包括：

• Instances of the Link component will be announced as a “link” element — very important, and;

  Link组件的实例将作为“ link”元素宣布—非常重要，并且；

• The PanelGroup and Panel component items will be announced as a “list” element. As a result, the total number of items will also be announced, giving context of how many items are available on the journey ahead.

  PanelGroup和Panel组件项将作为“列表”元素宣布。 这样一来，所有物品的数量也将被宣布，并给出在前进过程中有多少物品可用的上下文。

Check out the full code change in the PR: Side nav a11y updates #4093.

在PR中查看完整的代码更改： 侧面导航更新＃4093 。

辅助功能改进4：未宣布搜索结果的可用性 (Accessibility Improvement 4: Search result availability not announced)

As a sighted user, I was aware when a search was successful on account of the main content area changing its content to present a listing of items. But what about a blind, screen reader user?

作为有识之士，我知道由于主要内容区域更改其内容以显示项目列表而导致搜索成功。 但是，盲人的屏幕阅读器用户呢？

问题 (The problem)

If a screen reader user entered search text and pressed Enter, nothing would be announced indicating a successful search or any results. How’s someone to know when items are available in order to move ahead and discover this new content?

如果屏幕阅读器用户输入了搜索文字并按Enter ，则不会宣布任何内容，表明搜索成功或任何结果。 有人怎么知道什么时候可用，以便继续前进并发现这一新内容？

解决方案 (The solution)

In order for the current result count to be announced, I created a new, visually hidden, aria-live region. This region gets populated with new content when new search results are present.

为了宣布当前结果计数，我创建了一个新的，视觉上隐藏的aria-live区域。 当出现新的搜索结果时，该区域将填充新内容。

The region is marked up using a div with a few extra attributes:

使用具有一些额外属性的div标记该区域：

• aria-live="polite" creates the “live” region and tells screen readers to wait until other processes are finished before announcing its content.

  aria-live="polite"创建“实时”区域，并告诉屏幕阅读器等到其他过程完成后再宣布其内容。

• aria-atomic="true" tells screen readers to announce all the text within the region, not just the changed text.

  aria-atomic="true"告诉屏幕阅读器宣布区域内的所有文本，而不仅仅是更改的文本。

• role="status" sets the expectation for screen readers to interpret the live content as “advisory” information. In other words, it’s pretty important, but not critical (as people could navigate forward and discover content on their own.)

  role="status"设置了屏幕阅读器将实时内容解释为“建议”信息的期望。 换句话说，这很重要，但并不重要 (因为人们可以向前导航并自己发现内容。)

Here’s what the final code snippet looks like:

最终的代码段如下所示：

<div aria-atomic='true' aria-live='polite' className='sr-only' role='status'>  {`${results.length} result${results.length === 1 ? '' : 's'} found`}</div>

Notice the use of the ES6 template literal to interpolate the content as well as execute a ternary conditional statement to adjust for a plural or singular state.

请注意，使用ES6模板文字来内插内容以及执行三元条件语句以调整为复数或单数状态。

结果 (The result)

Now with an active screen reader, after submitting a search term, the number of results will be announced by assistive technology: “20 results found!”

现在，使用活动的屏幕阅读器，在提交搜索词后，将通过辅助技术宣布结果数： “找到20个结果！”

Check out the full code change in the PR: Search results announcements #5137.

在PR： 搜索结果公告＃5137中查看完整的代码更改。

辅助功能改进5：管理侧边栏链接焦点 (Accessibility Improvement 5: Managing sidebar link focus)

I noticed when navigating with a keyboard, after clicking a link to load page content, the focus indicator would stay on the current item. This was an issue. Why?

我注意到在使用键盘导航时，单击链接以加载页面内容后，焦点指示器将停留在当前项目上。 这是一个问题。 为什么？

问题 (The problem)

Without proper focus management, keyboard-only or screen reader users would have to navigate through the whole sidebar navigation to get to the page content. Not only this, there’s also no audible announcement alerting the user something has taken place on the click() event.

如果没有适当的焦点管理，纯键盘或屏幕阅读器用户将不得不在整个侧边栏导航中导航才能获得页面内容。 不仅如此，也没有声音提示提醒用户click()事件发生了什么。

解决方案 (The solution)

The fix I ended up going with was a bit of a hack. Normally you would create a ref prop on the content container, then pass the ref object up and over to the component which generates the sidebar link elements, then set focus() on the container on click(). This was not a possible solution as a result of the site using something called Gatsby and there being an issue with passing objects to Link components? I’m not really sure of the issue, but it just didn’t cooperate.

我最终得到的解决方案有点破烂。 通常，您将在内容容器上创建一个ref prop，然后将ref对象向上传递到生成侧边栏链接元素的组件，然后在click()上在容器上设置focus() click() 。 由于该站点使用了一种名为Gatsby的东西，并且将对象传递给Link组件时出现了问题，因此这是不可能的解决方案 我不太确定这个问题，但没有合作。

To get around this limitation, my solution went like this:

为了解决这个限制，我的解决方案是这样的：

1. I added a data-navitem="true" attribute to each of the appropriate sidebar Link components.

   我向每个适当的侧栏Link组件添加了data-navitem="true"属性。

2. On the click() event, the Article component loads with the requested content, setting document.activeElement to the clicked link element.

   在click()事件上， Article组件将加载请求的内容，并将document.activeElement设置为clicked链接元素。

3. Within the Article component’s componentWillMount() method, I check if the currently focused element (the sidebar link via document.activeElement) has the data-navitem attribute.

   在Article组件的componentWillMount()方法中，我检查当前关注的元素(通过document.activeElement)的侧边栏链接document.activeElement)是否具有data-navitem属性。

4. If this condition is true, shift keyboard focus to the article element.

   如果此条件为true ，则将键盘焦点移至article元素。

结果 (The Result)

Now when someone using the keyboard activates one of the sub-navigation links from the sidebar, keyboard focus shifts to the article content container. And this also provides context to screen reader users, conveying that something has taken place on click().

现在，当有人使用键盘激活侧边栏中的子导航链接之一时，键盘焦点将转移到article内容容器。 这也为屏幕阅读器用户提供了上下文，传达了click()发生了某些事情。

Check out the full code change in the PR: NavItem focus #7818.

在PR： NavItem focus＃7818中查看完整的代码更改。

And there we have it! With these few adjustments, the accessibility and usability of the freeCodeCamp Guide site has increased quite a bit! People can more comfortably use the site with ease and success.

我们终于得到它了！ 通过这些少量的调整， freeCodeCamp指南站点的可访问性和可用性大大提高了！ 人们可以轻松，成功地舒适地使用该网站。

This is just a high-level outline of a few issue that I tackled, but I know there’s more to do. Everyone on the freeCodeCamp Guide repo was very friendly and eager to help answer my newbie-ish React questions, so don’t hesitate if you want to help out!

这只是我解决的一些问题的简要概述，但我知道还有更多工作要做。 freeCodeCamp指南库中的每个人都很友好，并渴望帮助回答我的新手式React问题，因此，如果您需要帮助，请不要犹豫！

Happy hacking! ???

骇客入侵！ ???

翻译自: https://www.freecodecamp.org/news/next-level-accessibility-freecodecamp-guide-7cbd6473eabd/

残疾人软件开发