Broadly speaking, this is the principle that your website must be safelyable for all users tonavigate. This includes guidelines for accessing the entire website using only your keyboard. Additionally, the way your website responds to user input (via keyboard or other means) should be predictable, clear, and secure.
This last point mainly refers to ensuring that any features on the website that may cause seizures are disabled by default and users are warned before enabling them. The principle also provides guidelines for providing users with "enough time" to complete tasks, but we won't go into that here.
Being able to navigate and use your website using only your keyboard is one of the most important aspects of accessibility. Blind users rely almost entirely on the keyboard, while those with motor impairments may have difficulty controlling the mouse and therefore also rely on keyboard access. Some people may use their hands less or not at all, relying instead on a larger keyboard, mouth stick, head stick, single switch, or sip 'n' puff.
You can find instructions for these devices on the WebAIM website, but they essentially convert user input into keyboard strokes. If your website is not accessible from a keyboard, your website will be unavailable to all users who rely on these devices.
Fortunately, making your theme or plugin keyboard accessible is relatively simple. Here are some key points:
Many themes rely on hovering the mouse over a menu item to display any submenus. This is fine, but usually if the parent menu item gets focus (as opposed to hovering), the submenu will not appear. If you copy any relevant rules for :hover and apply them to :focus , this will get you half the battle: the submenu items will appear as user tabs within the entire menu. However, once the user switches down to the submenu, the parent menu loses focus and the submenu disappears. This can be corrected using JavaScript. The next article in this series will detail this and how to provide non-JavaScript fallbacks.
You don't need to do anything to make the "native" form input (select, enter, radio, etc.) keyboard accessible. However, if any aspect of the page (including a form field) gets focus, it must be moved away using just the keyboard, otherwise the user is effectively stuck. This is usually the default behavior, so you should avoid overriding it.
The guide has two types of suggestions: making it clear where the user is currently, and making it easier to get where they want to go.
Part of following the advice when doing this involves doing what many themes already do: having a consistent navigation menu across pages, highlighting the current page, and allowing users to quickly determine where they are on the site (e.g. using breadcrumbs) .
A key part of being able to browse the web using your keyboard is being able to see exactly what content is currently focused. The element currently receiving focus should be clearly distinct and distinguishable from the rest of the page. Therefore, you should avoid outline:none; unless you are providing an alternative style:
a:focus{
outline: none;
background: #ee7b00;
color: #fff;
}
Another important part of keyboard accessibility is that the Tab key behaves predictably and naturally. For example, if the focus is currently on a form field, I want the next tab to take me to the next field in that form. This can be frustrating and disorienting for users if pressing the Tab key causes focus to jump up and down erratically on the page.
Avoid using tabindex: The tabindex attribute allows you to change the order in which elements are accessed via the Tab key. However, if you follow the advice on DOM structure in article 2 of this series, the tab order should reflect the "natural" order of the page. While tabindex has its uses, they are few and far between, and its use to "fix" poor site structure may create more problems. The best approach is to avoid using tabindex and instead let your theme generate the logical DOM structure and use CSS to change the visual presentation.
Screen reader users will often jump between links, skipping the text in between, and at each link the screen reader will pronounce "link [link text]". So it’s very unhelpful for these users if they hear repeatedly “link to read more,” “link to click here,” or “link to continue reading.” In this case, adding context to the link simply provides the title of the post. So instead of “continue reading,” we have “continue reading [post title].”
To do this in a WordPress theme we simply connect the excerpt_more filter and append our "continue reading" link:
//Adds "continue reading X" link
function mytheme_continue_reading_link() {
return '<p class="read-more">'
. sprintf(
__( '<a href="%s">Continue reading %s</a>', 'mytheme' ),
esc_url( get_permalink() ),
esc_html( get_the_title() )
)
.'</p>';
}
//Replaces "[...]" (appended to automatically generated excerpts) with an ellipsis and mytheme_continue_reading_link().
function mytheme_auto_excerpt_more( $more ) {
return ' …' . mytheme_continue_reading_link();
}
add_filter( 'excerpt_more', 'mytheme_auto_excerpt_more' );
This provides the correct context for the "Read More" link. However, some improvements could be made.
首先，添加文章标题通常会破坏主题的美感，并且对于有视力的用户来说，这是多余的，因为“阅读更多”链接相对于文章标题和摘录的位置将使上下文显而易见。为了解决这些问题，我们可以“隐藏”文章标题，但屏幕阅读器仍然会阅读它们。
这意味着我们不能使用 display:none 或visibility:hidden; 作为屏幕-读者了解这些属性并会忽略内容。相反，我们可以将文本放置在屏幕外或使用 clip 属性：
.screen-reader {
position: absolute!important;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0,0,0,0);
border: 0;
}
“屏幕阅读器类”有很多不同的示例；这个特定的类取自 Bootstrap 3。接下来，将适当的类添加到文章标题中，具体将上面的第 5 行替换为：
__( '<a href="%s">Continue reading <span class="screen-reader">%s</span></a>', 'mytheme' ),
其次，虽然这将为用户提供链接指向何处的指示，但他们仍然必须在到达帖子标题之前收听“链接继续阅读...”。理想情况下，您应该将冗余信息放在链接文本的末尾，或者从锚标记中完全省略它，以减少识别链接所需的时间。
对于屏幕阅读器用户来说，不在链接文本前面添加冗余信息的另一个好处是屏幕阅读器通常会在页面上生成链接列表。如果您的许多链接都以相同的文本开头，这可能会使找到所需链接变得更加困难，特别是如果您的联系页面的链接位于“H”下方，因为它显示“如何联系我们”。
<title> 标签应使用 <title> 标签来识别用户的当前位置。该信息由屏幕阅读器读出，并显示在搜索结果以及屏幕窗口和浏览器选项卡中。为了让用户轻松识别他们所在的位置（或搜索到的内容），此标题标签应包含页面的标题和网站名称。理想情况下，网站名称应该放在最后，这样使用屏幕阅读器的人就不必在每次页面加载时先听您网站的名称，然后才能听到页面标题。
标题标签可以添加到主题中：
<title><?php wp_title(); ?></title>
要添加网站标题：
/** * Append site title to page title */
function mytheme_wp_title( $title, $sep, $seplocation ){
return $title . ' | ' . get_bloginfo('name');
}
add_filter( 'wp_title', 'mytheme_wp_title', 10, 3 );
通常，网站会有一个通用的标题和导航菜单，除了突出显示用户当前位置之外，它们将保持完全相同。必须通过选项卡浏览所有这些链接，或者在每次页面加载时听屏幕阅读器重复它们，是乏味且令人沮丧的。我们这些拥有良好（足够）视力和运动技能的人可以立即跳转到内容，并且我们可以让那些没有良好视力和运动技能的人也能轻松完成此操作。
如果您在 WordPress 管理员中，并在页面加载后按 Tab，您会注意到顶部会出现一个链接，其中显示跳到主要内容 -left（如果再次按 Tab，将出现跳到工具栏链接）。该链接位于页面的最顶部，因此它是选项卡切换时获得焦点的第一个链接，也是屏幕阅读器读出的网站的第一个链接。通过该链接，用户可以直接跳转到主要内容，跳过中间所有不必要的链接和网站徽标。
创建跳转到内容是让您的网站更易于导航的好方法，而且非常简单，只需要少量 HTML 和一些 CSS。
首先是 HTML。该链接应位于页面的最顶部，紧邻 <body> 标签下方。在大多数主题中，这将是 header.php 文件：
</head>
<body>
<a class="skip-link" href="#main">
<?php _e( 'Skip to main content', 'mytheme' ); ?>
</a>
//Rest of page content
这里唯一需要注意的是：
关于 (1)，您的循环将类似于：
<div id="main" class="hfeed" role="main">
<?php if ( have_posts() ) : ?>
//The Loop
<?php else: ?>
//No posts found... display search
<?php endif; ?>
</div>
您的页面模板可能类似于：
<div id="main" role="main">
<div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
<h1 class="entry-title"> <?php the_title(); ?> </h1>
<div class="entry-content">
<?php the_content(); ?>
</div>
</div>
</div>
现在剩下的就是向链接添加一些样式。
首先，我们希望链接隐藏，但不对屏幕阅读器隐藏，因此我们会将链接放置在屏幕外，而不是使用 display:none（在这种情况下，屏幕阅读器会忽略它）。
其次，当它获得焦点时，我们希望使链接变得明显，因此很明显以前隐藏的链接现在可见并具有焦点。
.skip-link {
position: absolute;
left:6px;
top:-100px; /* position offscreen so it's not visible, but can receive focus*/
z-index: 100000; /* Position above WordPress' toolbar */
font-size: 1em;
font-weight: bold;
display: block;
background: #ee7b00;
color: white; /*Style the link so that's clear*/
height: auto;
width: auto;
line-height: normal;
padding: 15px 25px;
text-decoration: none;
-webkit-transition: top 1s ease-out;
transition: top 1s ease-out;
}
.skip-link:focus {
top: 5px; /* Move onto screen */
-webkit-transition: right 0s;
transition: right 0s; /*Animate, to make its appearance obvious */
}
最后，请注意，有些人容易患光敏性癫痫发作。这可能是由闪烁或闪光效果引起的。去年 12 月，杰夫·钱德勒 (Jeff Chandler) 在一名访客警告杰夫·钱德勒 (Jeff Chandler) 取消了 WP Tavern 的“雪”效果可能引发癫痫发作后。
这不仅限于癫痫发作，它还可能引发某些人的偏头痛或惊恐发作。它也不限于雪花效果 - 视频、轮播或音频文件自动播放也可以触发这些效果。
While this is primarily an editorial decision, and as developers it's not our job to prevent autoplay, we can at least prevent it by disabling it by default. Jeff mentioned in his article that he couldn't find a plugin that provided a "snow" effect that visitors could play with themselves.
The above is the detailed content of Operability: Accessibility, Part 4. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
