From 310fd066e91f454b990372ffa30e803cc8120975 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:56:40 +0100 Subject: unslug zh-cn: move --- .../introduction/index.html | 393 +++++++++++++ .../\344\273\213\347\273\215/index.html" | 393 ------------- .../cross_browser_testing/accessibility/index.html | 624 +++++++++++++++++++++ .../testing_strategies/index.html | 367 ++++++++++++ .../index.html" | 624 --------------------- .../index.html" | 367 ------------ 6 files changed, 1384 insertions(+), 1384 deletions(-) create mode 100644 files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/introduction/index.html delete mode 100644 "files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/\344\273\213\347\273\215/index.html" create mode 100644 files/zh-cn/learn/tools_and_testing/cross_browser_testing/accessibility/index.html create mode 100644 files/zh-cn/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html delete mode 100644 "files/zh-cn/learn/tools_and_testing/cross_browser_testing/\345\217\257\350\256\277\351\227\256\346\200\247/index.html" delete mode 100644 "files/zh-cn/learn/tools_and_testing/cross_browser_testing/\346\265\213\350\257\225\347\255\226\347\225\245/index.html" (limited to 'files/zh-cn/learn/tools_and_testing') diff --git a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/introduction/index.html b/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/introduction/index.html new file mode 100644 index 0000000000..3975354417 --- /dev/null +++ b/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/introduction/index.html @@ -0,0 +1,393 @@ +--- +title: 客户端框架介绍 +slug: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/介绍 +tags: + - JavaScript + - 初学者 + - 学习 + - 客户端 + - 框架 +translation_of: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Introduction +--- +
{{LearnSidebar}}
+ +
{{NextMenu("Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Main_features", "Learn/Tools_and_testing/Client-side_JavaScript_frameworks")}}
+ +

在本章节我们开始大致了解框架, 简要回顾JavaScript和框架的历史,为什么框架会存在以及它们提供了什么, 如何开始考虑选择一个框架并学习, 以及对于客户端框架还有什么替代方案.

+ + + + + + + + + + + + +
先决条件：熟悉 HTML, CSS, 以及 JavaScript 语言的核心.
目标:了解客户端JavaScript框架是如何存在的，它们能解决什么问题，还有哪些替代方案，以及如何选择一个框架.
+ +

简史

+ +

当JavaScript在1996被发布后, 它给网络增加了少许的交互性和乐趣, 直到那时, 网页仍由静态文档组成. 网络应该不仅仅是阅读,更是创造的地方. 随着JavaScript的流行. 使用JavaScript的开发者们创造工具来解决他们遇到的问题, 并且将其打包成称为库的可复用组件, 这样就能和他人共享解决方案. 这种共享库的体系帮助塑造了网络的增长.

+ +

现在, JavaScript是网络的基本部分, used on 95% of all websites, 而且网络又是现代生活的基本部分. 用户在网络上写文章, 管理预算, 听音乐, 看电影,  以及和相隔万里的人通过文字, 音频, 视频聊天来瞬时交流. 网络让我们能够做到那些过去只能在电脑上安装本地应用程序才能做到的事. 这些现代的, 复杂的, 具有交互性的网站通常被称为 网络应用程序.

+ +

现代JavaScript框架的到来加快了打造高度动态化和交互性强的应用程序的速度.  框架 就是提供该如何构建应用程序的意见的库。这些意见能使应用具有可预测性和同质性。可预测性让软件能在扩展到很大规模的同时仍保持可维护性。可预测性和可维护性对于一个软件的长久健康运行是十分重要的。

+ +

在现代网络中，JavaScript框架为众多令人印象深刻的软件提供支持——包括许多你可能每天都使用的网站。你正在阅读的这个MDN Web 文档页面, 就是使用React / ReactDOM框架为其前端提供动力。

+ +

有哪些框架?

+ +

有很多框架可供你选择，但以下主要介绍目前公认的“四大框架”。

+ +

Ember

+ +

Ember于2011年12月发布，最初作为SproutCore项目的延续而开始。比其新式的替代品（例如React和Vue），作为老框架它的用户人数要少得多。但因其稳定性、社区支持以及一些明智的编程原则，它仍然享有很高的知名度。

+ +

Angular

+ +

Angular 是一个开源 Web 应用程序框架，正式发布于2016年9月14日。它由构建 AngularJS 的团队完全重写，并由 Google 的 Angular 团队以及个人和公司社区共同领导。

+ +

Angular 是一种基于组件的框架，使用声明式的HTML模板。在应用构建时，框架的编译器将 HTML 模板转换为优化好的 JavaScript 指令，这一过程对开发者是透明的。Angular 使用 TypeScript，它是 JavaScript 的超集，我们将在下一章中对其进行更多介绍。

+ +

Vue

+ +

Evan You first released Vue in 2014, after working on and learning from the original AngularJS project. Vue is the youngest of the big four, but has enjoyed a recent uptick in popularity.

+ +

Vue, like AngularJS, extends HTML with some of its own code. Apart from that, it mainly relies on modern, standard JavaScript.

+ +

React

+ +

Facebook 在 2013 发布了 React。 在当时 React 已经被Facebook内部用来解决许多问题。 严格来说 React 本身并不是框架，而是一个用来渲染UI 组件的库。 React is used in combination with other libraries to make applications — React and React Native enable developers to make mobile applications; React and ReactDOM enables them to make web applications, etc.

+ +

Because React and ReactDOM are so often used together, React is colloquially understood as a JavaScript framework. As you read through this module, we will be working with that colloquial understanding.

+ +

React extends JavaScript with HTML-like syntax, known as JSX.

+ +

框架为何会存在?

+ +

我们已经讨论了因为什么契机而创造了框架，但我们仍不知道为什么开发者认为有必要创造它。要知道这个问题的答案，我们首先需要检查软件开发中的各种挑战。

+ +

设想一个很常见的软件：一个To-Do清单创建器，在接下来的章节中我们会使用各种框架来实现它。这个应用应让用户可以完成诸如呈现任务列表、添加和删除任务等操作，且在完成这些操作的同时能可靠地跟踪和更新应用程序的底层数据。在软件开发中，这种底层数据被称为状态。

+ +

上述每个目标理论上都很简单。我们可以遍历数据来列出清单，添加一个对象来创建新任务，使用标识符来查找、编辑和删除任务。需要注意的是，用户都是在浏览器中使用应用的这些功能，然而这就引出了一些问题： 每当我们修改应用的数据时，我们都需要更新用户界面以使其匹配。 

+ +

我们可以通过To-Do应用的一个功能来检验这个问题的难点：呈现任务清单。

+ +

冗长的DOM操作

+ +

Building HTML elements and rendering them in the browser at the appropriate time takes a surprising amount of code. Let's say that our state is an array of objects structured like this:

+ +
const state = [
+  {
+    id: 'todo-0',
+    name: 'Learn some frameworks!'
+  }
+]
+ +

How do we show one of those tasks to our user? We want to represent each task as a list item – an HTML <li> element inside of an unordered list element (a <ul>). How do we make it? That could look something like this:

+ +
function buildTodoItemEl(id, name) {
+  const item = document.createElement('li');
+  const span = document.createElement('span');
+  const textContent = document.createTextNode(name);
+
+  span.appendChild(textContent)
+
+  item.id = id;
+  item.appendChild(span);
+  item.appendChild(buildDeleteButtonEl(id));
+
+  return item;
+}
+ +

Here, we use the document.createElement() method to make our <li>, and several more lines of code to create the properties and children it needs.

+ +

The tenth line of this snippet references another build function: buildDeleteButtonEl(). It follows a similar pattern to the one we used to build a list item element:

+ +
function buildDeleteButtonEl(id) {
+  const button = document.createElement('button');
+  const textContent = document.createTextNode('Delete');
+
+  button.setAttribute('type', 'button');
+  button.appendChild(textContent);
+
+  return button;
+}
+ +

This button doesn't do anything yet, but it will later once we decide to implement our delete feature. The code that will render our items on the page might read something like this:

+ +
function renderTodoList() {
+  const frag = document.createDocumentFragment();
+  state.tasks.forEach(task => {
+    const item = buildTodoItemEl(task.id, task.name);
+    frag.appendChild(item);
+  });
+
+  while (todoListEl.firstChild) {
+    todoListEl.removeChild(todoListEl.firstChild);
+  }
+  todoListEl.appendChild(frag);
+}
+ +

We've now got well over thirty lines of code dedicated just to the UI – just to the step of rendering something in the DOM – and at no point do we add classes that we could use later to style our list-items!

+ +

Working directly with the DOM, as in this example, requires understanding many things about how the DOM works: how to make elements; how to change their properties; how to put elements inside of each other; how to get them on the page. None of this code actually handles user interactions, or addresses adding or deleting a task. If we add those features, we have to remember to update our UI in the right time and in the right way.

+ +

JavaScript frameworks were created to make this kind of work a little easier — they exist to provide a better developer experience. They don't bring brand-new powers to JavaScript; they give you easier access to JavaScript's powers so you can build for today's web.

+ +

If you want to see code samples from this section in action, you can check out a working version of the app on CodePen, which also allows users to add and delete new tasks.

+ +

Read more about the JavaScript used in this section:

+ + + +

另一种打造UIs的方式

+ +

Every JavaScript framework offers a way to write user interfaces more declaratively. That is, they allow you to write code that describes how your UI should look, and the framework makes it happen in the DOM behind the scenes.

+ +

The vanilla JavaScript approach to building out new DOM elements in repetition was difficult to understand at a glance.  By contrast, the following block of code illustrates the way you might use Vue to describe our list of tasks:

+ +
<ul>
+  <li v-for="task in tasks" v-bind:key="task.id">
+    <span>\{{task.name\}}</span>
+    <button type="button">Delete</button>
+  </li>
+</ul>
+ +

That's it. This snippet reduces approximately thirty-two lines of code down to six lines. If the curly braces and v- attributes here are unfamiliar to you, that's okay; you’ll learn about Vue-specific syntax later on in the module. The thing to take away here is that this code looks like the UI it represents, whereas the vanilla JavaScript code does not.

+ +

Thanks to Vue, we didn't have to write our own functions for building the UI; the framework will handle that for us in an optimized, efficient way. Our only role here was to describe to Vue what each item should look like. Developers who are familiar with Vue can join our project and quickly work out what is going on. Vue is not alone in this: using a framework improves team as well as individual efficiency.

+ +

It's possible to do things similar to this in vanilla JavaScript. Template literal strings make it easy to write strings of HTML that represent what the final element would look like. That might be a useful idea for something as simple as our to-do list application, but it's not maintainable for large applications that manage thousands of records of data, and could render just as many unique elements in a user interface.

+ +

框架提供给我们的其他功能

+ +

Let's look at some of the other advantages conferred upon us by frameworks. As we've alluded to before, the advantages of frameworks are achievable in vanilla JavaScript, but using a framework takes away all of the cognitive load of having to solve these problems yourself.

+ +

Tooling

+ +

Because each of the frameworks in this module have a large, active community, each framework's ecosystem provides tooling that Improves the developer experience. These tools make it easy to add things like testing (to ensure that your application behaves as it should) or linting (to ensure that your code is error-free and stylistically consistent).

+ +
+

Note: If you want to find out more details about web tooling concepts, have a read of our Client-side tooling overview.

+
+ +

Compartmentalization

+ +

Most major frameworks encourage developers to abstract the different parts of their user interfaces into components — maintainable, reusable chunks of code that can communicate with one another. All the code related to a given component can live in one file (or a couple of specific files), so that you as a developer know exactly where to go to make changes to that component. In a vanilla JavaScript app, you'd have to create your own set of conventions to achieve this in an efficient, scalable way. Many JavaScript developers, if left to their own devices, could end up with all the code related to one part of the UI being spread out all over a file — or in another file altogether.

+ +

Routing

+ +

The most essential feature of the web is that it allows users to navigate from one page to another – it is, after all, a network of interlinked documents. When you follow a link on this very website, your browser communicates with a server and fetches new content to display for you. As it does so, the URL in your address bar changes. You can save this new URL and come back to the page later on, or share it with others so they can easily find the same page. Your browser remembers your navigation history and allows you to navigate back and forth, too. This is called server-side routing.

+ +

Modern web applications typically do not fetch and render new HTML files — they load a single HTML shell, and continually update the DOM inside it (referred to as single page apps, or SPAs) without navigating users to new addresses on the web. Each new pseudo-webpage is usually called a view, and by default, no routing is done.

+ +

When an SPA is complex enough, and renders enough unique views, it's important to bring routing functionality into your application. People are used to being able to link to specific pages in an application, travel forward and backward in their navigation history, etc., and their experience suffers when these standard web features are broken. When routing is handled by a client application in this fashion, it is aptly called client-side routing.

+ +

It's possible to make a router using the native capabilities of JavaScript and the browser, but popular, actively developed frameworks have companion libraries that make routing a more intuitive part of the development process.

+ +

使用框架的注意事项

+ +

Being an effective web developer means using the most appropriate tools for the job. JavaScript frameworks make front-end application development easy, but they are not a silver bullet that will solve all problems. This section talks about some of the things you should consider when using frameworks. Bear in mind that you might not need a framework at all — beware that you don't end up using a framework just for the sake of it.

+ +

Familiarity with the tool

+ +

Just like vanilla JavaScript, frameworks take time to learn and have their quirks. Before you decide to use a framework for a project, be sure you have time to learn enough of its features for it to be useful to you rather than it working against you, and be sure that your teammates are comfortable with it as well.

+ +

Overengineering

+ +

If your web development project is a personal portfolio with a few pages, and those pages have little or no interactive capability, a framework (and all of its JavaScript) may not be necessary at all. That said, frameworks are not a monolith, and some of them are better-suited to small projects than others. In an article for Smashing Magazine, Sarah Drasner writes about how Vue can replace jQuery as a tool for making small portions of a webpage interactive.

+ +

Larger code base and abstraction

+ +

Frameworks allow you to write more declarative code – and sometimes less code overall – by dealing with the DOM interactions for you, behind the scenes. This abstraction is great for your experience as a developer, but it isn't free. In order to translate what you write into DOM changes, frameworks have to run their own code, which in turn makes your final piece of software larger and more computationally expensive to operate.

+ +

Some extra code is inevitable, and a framework that supports tree-shaking (removal of any code that isn't actually used in the app during the build process) will allow you to keep your applications small, but this is still a factor you need to keep in mind when considering your app's performance, especially on more network/storage-constrained devices, like mobile phones.

+ +

The abstraction of frameworks affects not only your JavaScript, but your relationship with the very nature of the web. No matter how you build for the web, the end result, the layer that your users ultimately interact with, is HTML. Writing your whole application in JavaScript can make you lose sight of HTML and the purpose of its various tags, and lead you to produce an HTML document that is un-semantic and inaccessible. In fact, it's possible to write a fragile application that depends entirely on JavaScript and will not function without it.

+ +

Frameworks are not the source of our problems. With the wrong priorities, it's possible for any application to be fragile, bloated, and inaccessible. Frameworks do, however, amplify our priorities as developers. If your priority is to make a complex web app, it's easy to do that. However, if your priorities don't carefully guard performance and accessibility, frameworks will amplify your fragility, your bloat, and your inaccessibility. Modern developer priorities, amplified by frameworks, have inverted the structure of the web in many places. Instead of a robust, content-first network of documents, the web now often puts JavaScript first and user experience last.

+ +

框架驱动页面的可访问性

+ +

Let's build on what we said in the previous section, and talk a bit more about accessibility. Making user interfaces accessible always requires some thought and effort, and frameworks can complicate that process. You often have to employ advanced framework APIs to access native browser features like ARIA live regions or focus management.

+ +

In some cases, framework applications create accessibility barriers that do not exist for traditional websites. The biggest example of this is in client-side routing, as mentioned earlier.

+ +

With traditional (server-side) routing, navigating the web has predictable results. The browser knows to set focus to the top of the page and assistive technologies will announce the title of the page. These things happen every time you navigate to a new page.

+ +

With client-side routing, your browser is not loading new web pages, so it doesn't know that it should automatically adjust focus or announce a new page title. Framework authors have devoted immense time and labor to writing JavaScript that recreates these features, and even then, no framework has done so perfectly.

+ +

The upshot is that you should consider accessibility from the very start of every web project, but bear in mind that abstracted codebases that use frameworks are more likely to suffer from major accessibility issues if you don't.

+ +

如何选择一个框架

+ +

Each of the frameworks discussed in this module take different approaches to web application development. Each is regularly improving or changing, and each has its pros and cons. Choosing the right framework is a team- and project-dependent process, and you should do your own research to uncover what suits your needs. That said, we've identified a few questions you can ask in order to research your options more effectively:

+ +
    +
  1. What browsers does the framework support?
    2. +
  2. What domain-specific languages does the framework utilize?
    3. +
  3. Does the framework have a strong community and good docs (and other support) available?
    4. +
+ +

The table in this section provides a glanceable summary of the current browser support offered by each framework, as well as the domain-specific languages with which it can be used.

+ +

Broadly, domain-specific languages (DSLs) are programming languages relevant in specific areas of software development. In the context of frameworks, DSLs are variations on JavaScript or HTML that make it easier to develop with that framework. Crucially, none of the frameworks require a developer to use a specific DSL, but they have almost all been designed with a specific DSL in mind. Choosing not to employ a framework’s preferred DSL will mean you miss out on features that would otherwise improve your developer experience.

+ +

You should seriously consider the support matrix and DSLs of a framework when making a choice for any new project. Mismatched browser support can be a barrier to your users; mismatched DSL support can be a barrier to you and your teammates.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FrameworkBrowser supportPreferred DSLSupported DSLs
AngularIE9+TypeScriptHTML-based; TypeScript
ReactModern (IE9+ with Polyfills)JSXJSX; TypeScript
VueIE9+HTML-basedHTML-based, JSX, Pug
EmberModern (IE9+ in Ember version 2.18)HandlebarsHandlebars, TypeScript
+ +
+

Note: DSLs we've described as "HTML-based" do not have official names. They are not really true DSLs, but they are non-standard HTML, so we believe they are worth highlighting.

+
+ +

Citations for this table:

+ + + +

Does the framework have a strong community?

+ +

This is perhaps the hardest metric to measure, because community size does not correlate directly to easy-to-access numbers. You can check a project's number of GitHub stars or weekly npm downloads to get an idea of its popularity, but sometimes the best thing to do is search a few forums or talk to other developers. It is not just about the community's size, but also how welcoming and inclusive it is, and how good available documentation is.

+ +

Opinions on the web

+ +

Don't just take our word on this matter — there are discussions all over the web. The Wikimedia Foundation recently chose to use Vue for its front-end, and posted a request for comments (RFC) on framework adoption. Eric Gardner, the author of the RFC, took time to outline the needs of the Wikimedia project and why certain frameworks were good choices for the team. This RFC serves as a great example of the kind of research you should do for yourself when planning to use a front-end framework.

+ +

The State of JavaScript survey is a helpful collection of feedback from JavaScript developers. It covers many topics related to JavaScript, including data about both the use of frameworks and developer sentiment toward them. Currently, there are several years of data available, allowing you to get a sense of a framework's popularity.

+ +

The Vue team has exhaustively compared Vue to other popular frameworks. There may be some bias in this comparison (which they note), but it's a valuable resource nonetheless.

+ +

客户端框架的替代方案

+ +

If you’re looking for tools to expedite the web development process, and you know your project isn’t going to require intensive client-side JavaScript, you could reach for one of a handful of other solutions for building the web:

+ + + +

Content management systems

+ +

Content-management systems (CMSes) are any tools that allow a user to create content for the web without directly writing code themselves. They're a good solution for large projects, especially projects that require input from content writers who have limited coding ability, or for programmers who want to save time. They do, however, require a significant amount of time to set up, and utilizing a CMS means that you surrender at least some measure of control over the final output of your website. For example: if your chosen CMS doesn't author accessible content by default, it's often difficult to improve this.

+ +

Popular examples include Wordpress, Joomla, and Drupal.

+ +

Server-side rendering

+ +

Server-side rendering (SSR) is an application architecture in which it is the server's job to render a single-page application. This is the opposite of client-side rendering, which is the most common and most straightforward way to build a JavaScript application. Server-side rendering is easier on the client's device, because you're only sending a rendered HTML file to them, but it can be difficult to set up compared to a client-side-rendered application.

+ +

All of the frameworks covered in this module support server-side rendering as well as client-side rendering. Check out Next.js for React, Nuxt.js for Vue (yes it is confusing, and no, these projects are not related!), FastBoot for Ember, and Angular Universal for Angular.

+ +
+

Note: Some SSR solutions are written and maintained by the community, whereas some are "official" solutions provided by the framework's maintainer.

+
+ +

Static site generators

+ +

Static site generators are programs that dynamically generate all the webpages of a multi-page website — including any relevant CSS or JavaScript — so that they can be published in any number of places. The publishing host could be a GitHub pages branch, a Netlify instance, or any private server of your choosing, for example. There are a number of advantages of this approach, mostly around performance (your user's device isn’t building the page with JavaScript; it's already complete) and security (static pages have fewer attack vectors). These sites can still utilize JavaScript where they need to, but they are not dependent upon it. Static site generators take time to learn, just like any other tool, which can be a barrier to your development process.

+ +

Static sites can have as few or as many unique pages as you want. Just as frameworks empower you to quickly write client-side JavaScript applications, static site generators allow you a way to quickly create HTML files you would otherwise have written individually. Like frameworks, static site generators allow developers to write components that define common pieces of your web pages, and to compose those components together to create a final page. In the context of static site generators, these components are called templates. Web pages built by static site generators can even be home to framework applications: if you want one specific page of your statically-generated website to boot up a React application when your user visits it for example, you can do that.

+ +

Static site generators have been around for quite a long time, but they have seen a bit of a revival in the recent history of the web. A handful of powerful options are now available, such as Hugo, Jekyll, Eleventy, and Gatsby.

+ +

If you'd like to learn more about static site generators on the whole, check out Tatiana Mac's Beginner's guide to Eleventy. In the first article of the series, she explains what a static site generator is, and how it relates to other means of publishing web content.

+ +

总结

+ +

And that brings us to the end of our introduction to frameworks — we’ve not taught you any code yet, but hopefully we've given you a useful background on why you'd use frameworks in the first place and how to go about choosing one, and made you excited to learn more and get stuck in!

+ +

Our next article goes down to a lower level, looking at the specific kinds of features frameworks tend to offer, and why they work like they do.

+ +

{{NextMenu("Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Main_features", "Learn/Tools_and_testing/Client-side_JavaScript_frameworks")}}

+ +

In this module

+ + diff --git "a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/\344\273\213\347\273\215/index.html" "b/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/\344\273\213\347\273\215/index.html" deleted file mode 100644 index 3975354417..0000000000 --- "a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/\344\273\213\347\273\215/index.html" +++ /dev/null @@ -1,393 +0,0 @@ ---- -title: 客户端框架介绍 -slug: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/介绍 -tags: - - JavaScript - - 初学者 - - 学习 - - 客户端 - - 框架 -translation_of: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Introduction ---- -
{{LearnSidebar}}
- -
{{NextMenu("Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Main_features", "Learn/Tools_and_testing/Client-side_JavaScript_frameworks")}}
- -

在本章节我们开始大致了解框架, 简要回顾JavaScript和框架的历史,为什么框架会存在以及它们提供了什么, 如何开始考虑选择一个框架并学习, 以及对于客户端框架还有什么替代方案.

- - - - - - - - - - - - -
先决条件：熟悉 HTML, CSS, 以及 JavaScript 语言的核心.
目标:了解客户端JavaScript框架是如何存在的，它们能解决什么问题，还有哪些替代方案，以及如何选择一个框架.
- -

简史

- -

当JavaScript在1996被发布后, 它给网络增加了少许的交互性和乐趣, 直到那时, 网页仍由静态文档组成. 网络应该不仅仅是阅读,更是创造的地方. 随着JavaScript的流行. 使用JavaScript的开发者们创造工具来解决他们遇到的问题, 并且将其打包成称为库的可复用组件, 这样就能和他人共享解决方案. 这种共享库的体系帮助塑造了网络的增长.

- -

现在, JavaScript是网络的基本部分, used on 95% of all websites, 而且网络又是现代生活的基本部分. 用户在网络上写文章, 管理预算, 听音乐, 看电影,  以及和相隔万里的人通过文字, 音频, 视频聊天来瞬时交流. 网络让我们能够做到那些过去只能在电脑上安装本地应用程序才能做到的事. 这些现代的, 复杂的, 具有交互性的网站通常被称为 网络应用程序.

- -

现代JavaScript框架的到来加快了打造高度动态化和交互性强的应用程序的速度.  框架 就是提供该如何构建应用程序的意见的库。这些意见能使应用具有可预测性和同质性。可预测性让软件能在扩展到很大规模的同时仍保持可维护性。可预测性和可维护性对于一个软件的长久健康运行是十分重要的。

- -

在现代网络中，JavaScript框架为众多令人印象深刻的软件提供支持——包括许多你可能每天都使用的网站。你正在阅读的这个MDN Web 文档页面, 就是使用React / ReactDOM框架为其前端提供动力。

- -

有哪些框架?

- -

有很多框架可供你选择，但以下主要介绍目前公认的“四大框架”。

- -

Ember

- -

Ember于2011年12月发布，最初作为SproutCore项目的延续而开始。比其新式的替代品（例如React和Vue），作为老框架它的用户人数要少得多。但因其稳定性、社区支持以及一些明智的编程原则，它仍然享有很高的知名度。

- -

Angular

- -

Angular 是一个开源 Web 应用程序框架，正式发布于2016年9月14日。它由构建 AngularJS 的团队完全重写，并由 Google 的 Angular 团队以及个人和公司社区共同领导。

- -

Angular 是一种基于组件的框架，使用声明式的HTML模板。在应用构建时，框架的编译器将 HTML 模板转换为优化好的 JavaScript 指令，这一过程对开发者是透明的。Angular 使用 TypeScript，它是 JavaScript 的超集，我们将在下一章中对其进行更多介绍。

- -

Vue

- -

Evan You first released Vue in 2014, after working on and learning from the original AngularJS project. Vue is the youngest of the big four, but has enjoyed a recent uptick in popularity.

- -

Vue, like AngularJS, extends HTML with some of its own code. Apart from that, it mainly relies on modern, standard JavaScript.

- -

React

- -

Facebook 在 2013 发布了 React。 在当时 React 已经被Facebook内部用来解决许多问题。 严格来说 React 本身并不是框架，而是一个用来渲染UI 组件的库。 React is used in combination with other libraries to make applications — React and React Native enable developers to make mobile applications; React and ReactDOM enables them to make web applications, etc.

- -

Because React and ReactDOM are so often used together, React is colloquially understood as a JavaScript framework. As you read through this module, we will be working with that colloquial understanding.

- -

React extends JavaScript with HTML-like syntax, known as JSX.

- -

框架为何会存在?

- -

我们已经讨论了因为什么契机而创造了框架，但我们仍不知道为什么开发者认为有必要创造它。要知道这个问题的答案，我们首先需要检查软件开发中的各种挑战。

- -

设想一个很常见的软件：一个To-Do清单创建器，在接下来的章节中我们会使用各种框架来实现它。这个应用应让用户可以完成诸如呈现任务列表、添加和删除任务等操作，且在完成这些操作的同时能可靠地跟踪和更新应用程序的底层数据。在软件开发中，这种底层数据被称为状态。

- -

上述每个目标理论上都很简单。我们可以遍历数据来列出清单，添加一个对象来创建新任务，使用标识符来查找、编辑和删除任务。需要注意的是，用户都是在浏览器中使用应用的这些功能，然而这就引出了一些问题： 每当我们修改应用的数据时，我们都需要更新用户界面以使其匹配。 

- -

我们可以通过To-Do应用的一个功能来检验这个问题的难点：呈现任务清单。

- -

冗长的DOM操作

- -

Building HTML elements and rendering them in the browser at the appropriate time takes a surprising amount of code. Let's say that our state is an array of objects structured like this:

- -
const state = [
-  {
-    id: 'todo-0',
-    name: 'Learn some frameworks!'
-  }
-]
- -

How do we show one of those tasks to our user? We want to represent each task as a list item – an HTML <li> element inside of an unordered list element (a <ul>). How do we make it? That could look something like this:

- -
function buildTodoItemEl(id, name) {
-  const item = document.createElement('li');
-  const span = document.createElement('span');
-  const textContent = document.createTextNode(name);
-
-  span.appendChild(textContent)
-
-  item.id = id;
-  item.appendChild(span);
-  item.appendChild(buildDeleteButtonEl(id));
-
-  return item;
-}
- -

Here, we use the document.createElement() method to make our <li>, and several more lines of code to create the properties and children it needs.

- -

The tenth line of this snippet references another build function: buildDeleteButtonEl(). It follows a similar pattern to the one we used to build a list item element:

- -
function buildDeleteButtonEl(id) {
-  const button = document.createElement('button');
-  const textContent = document.createTextNode('Delete');
-
-  button.setAttribute('type', 'button');
-  button.appendChild(textContent);
-
-  return button;
-}
- -

This button doesn't do anything yet, but it will later once we decide to implement our delete feature. The code that will render our items on the page might read something like this:

- -
function renderTodoList() {
-  const frag = document.createDocumentFragment();
-  state.tasks.forEach(task => {
-    const item = buildTodoItemEl(task.id, task.name);
-    frag.appendChild(item);
-  });
-
-  while (todoListEl.firstChild) {
-    todoListEl.removeChild(todoListEl.firstChild);
-  }
-  todoListEl.appendChild(frag);
-}
- -

We've now got well over thirty lines of code dedicated just to the UI – just to the step of rendering something in the DOM – and at no point do we add classes that we could use later to style our list-items!

- -

Working directly with the DOM, as in this example, requires understanding many things about how the DOM works: how to make elements; how to change their properties; how to put elements inside of each other; how to get them on the page. None of this code actually handles user interactions, or addresses adding or deleting a task. If we add those features, we have to remember to update our UI in the right time and in the right way.

- -

JavaScript frameworks were created to make this kind of work a little easier — they exist to provide a better developer experience. They don't bring brand-new powers to JavaScript; they give you easier access to JavaScript's powers so you can build for today's web.

- -

If you want to see code samples from this section in action, you can check out a working version of the app on CodePen, which also allows users to add and delete new tasks.

- -

Read more about the JavaScript used in this section:

- - - -

另一种打造UIs的方式

- -

Every JavaScript framework offers a way to write user interfaces more declaratively. That is, they allow you to write code that describes how your UI should look, and the framework makes it happen in the DOM behind the scenes.

- -

The vanilla JavaScript approach to building out new DOM elements in repetition was difficult to understand at a glance.  By contrast, the following block of code illustrates the way you might use Vue to describe our list of tasks:

- -
<ul>
-  <li v-for="task in tasks" v-bind:key="task.id">
-    <span>\{{task.name\}}</span>
-    <button type="button">Delete</button>
-  </li>
-</ul>
- -

That's it. This snippet reduces approximately thirty-two lines of code down to six lines. If the curly braces and v- attributes here are unfamiliar to you, that's okay; you’ll learn about Vue-specific syntax later on in the module. The thing to take away here is that this code looks like the UI it represents, whereas the vanilla JavaScript code does not.

- -

Thanks to Vue, we didn't have to write our own functions for building the UI; the framework will handle that for us in an optimized, efficient way. Our only role here was to describe to Vue what each item should look like. Developers who are familiar with Vue can join our project and quickly work out what is going on. Vue is not alone in this: using a framework improves team as well as individual efficiency.

- -

It's possible to do things similar to this in vanilla JavaScript. Template literal strings make it easy to write strings of HTML that represent what the final element would look like. That might be a useful idea for something as simple as our to-do list application, but it's not maintainable for large applications that manage thousands of records of data, and could render just as many unique elements in a user interface.

- -

框架提供给我们的其他功能

- -

Let's look at some of the other advantages conferred upon us by frameworks. As we've alluded to before, the advantages of frameworks are achievable in vanilla JavaScript, but using a framework takes away all of the cognitive load of having to solve these problems yourself.

- -

Tooling

- -

Because each of the frameworks in this module have a large, active community, each framework's ecosystem provides tooling that Improves the developer experience. These tools make it easy to add things like testing (to ensure that your application behaves as it should) or linting (to ensure that your code is error-free and stylistically consistent).

- -
-

Note: If you want to find out more details about web tooling concepts, have a read of our Client-side tooling overview.

-
- -

Compartmentalization

- -

Most major frameworks encourage developers to abstract the different parts of their user interfaces into components — maintainable, reusable chunks of code that can communicate with one another. All the code related to a given component can live in one file (or a couple of specific files), so that you as a developer know exactly where to go to make changes to that component. In a vanilla JavaScript app, you'd have to create your own set of conventions to achieve this in an efficient, scalable way. Many JavaScript developers, if left to their own devices, could end up with all the code related to one part of the UI being spread out all over a file — or in another file altogether.

- -

Routing

- -

The most essential feature of the web is that it allows users to navigate from one page to another – it is, after all, a network of interlinked documents. When you follow a link on this very website, your browser communicates with a server and fetches new content to display for you. As it does so, the URL in your address bar changes. You can save this new URL and come back to the page later on, or share it with others so they can easily find the same page. Your browser remembers your navigation history and allows you to navigate back and forth, too. This is called server-side routing.

- -

Modern web applications typically do not fetch and render new HTML files — they load a single HTML shell, and continually update the DOM inside it (referred to as single page apps, or SPAs) without navigating users to new addresses on the web. Each new pseudo-webpage is usually called a view, and by default, no routing is done.

- -

When an SPA is complex enough, and renders enough unique views, it's important to bring routing functionality into your application. People are used to being able to link to specific pages in an application, travel forward and backward in their navigation history, etc., and their experience suffers when these standard web features are broken. When routing is handled by a client application in this fashion, it is aptly called client-side routing.

- -

It's possible to make a router using the native capabilities of JavaScript and the browser, but popular, actively developed frameworks have companion libraries that make routing a more intuitive part of the development process.

- -

使用框架的注意事项

- -

Being an effective web developer means using the most appropriate tools for the job. JavaScript frameworks make front-end application development easy, but they are not a silver bullet that will solve all problems. This section talks about some of the things you should consider when using frameworks. Bear in mind that you might not need a framework at all — beware that you don't end up using a framework just for the sake of it.

- -

Familiarity with the tool

- -

Just like vanilla JavaScript, frameworks take time to learn and have their quirks. Before you decide to use a framework for a project, be sure you have time to learn enough of its features for it to be useful to you rather than it working against you, and be sure that your teammates are comfortable with it as well.

- -

Overengineering

- -

If your web development project is a personal portfolio with a few pages, and those pages have little or no interactive capability, a framework (and all of its JavaScript) may not be necessary at all. That said, frameworks are not a monolith, and some of them are better-suited to small projects than others. In an article for Smashing Magazine, Sarah Drasner writes about how Vue can replace jQuery as a tool for making small portions of a webpage interactive.

- -

Larger code base and abstraction

- -

Frameworks allow you to write more declarative code – and sometimes less code overall – by dealing with the DOM interactions for you, behind the scenes. This abstraction is great for your experience as a developer, but it isn't free. In order to translate what you write into DOM changes, frameworks have to run their own code, which in turn makes your final piece of software larger and more computationally expensive to operate.

- -

Some extra code is inevitable, and a framework that supports tree-shaking (removal of any code that isn't actually used in the app during the build process) will allow you to keep your applications small, but this is still a factor you need to keep in mind when considering your app's performance, especially on more network/storage-constrained devices, like mobile phones.

- -

The abstraction of frameworks affects not only your JavaScript, but your relationship with the very nature of the web. No matter how you build for the web, the end result, the layer that your users ultimately interact with, is HTML. Writing your whole application in JavaScript can make you lose sight of HTML and the purpose of its various tags, and lead you to produce an HTML document that is un-semantic and inaccessible. In fact, it's possible to write a fragile application that depends entirely on JavaScript and will not function without it.

- -

Frameworks are not the source of our problems. With the wrong priorities, it's possible for any application to be fragile, bloated, and inaccessible. Frameworks do, however, amplify our priorities as developers. If your priority is to make a complex web app, it's easy to do that. However, if your priorities don't carefully guard performance and accessibility, frameworks will amplify your fragility, your bloat, and your inaccessibility. Modern developer priorities, amplified by frameworks, have inverted the structure of the web in many places. Instead of a robust, content-first network of documents, the web now often puts JavaScript first and user experience last.

- -

框架驱动页面的可访问性

- -

Let's build on what we said in the previous section, and talk a bit more about accessibility. Making user interfaces accessible always requires some thought and effort, and frameworks can complicate that process. You often have to employ advanced framework APIs to access native browser features like ARIA live regions or focus management.

- -

In some cases, framework applications create accessibility barriers that do not exist for traditional websites. The biggest example of this is in client-side routing, as mentioned earlier.

- -

With traditional (server-side) routing, navigating the web has predictable results. The browser knows to set focus to the top of the page and assistive technologies will announce the title of the page. These things happen every time you navigate to a new page.

- -

With client-side routing, your browser is not loading new web pages, so it doesn't know that it should automatically adjust focus or announce a new page title. Framework authors have devoted immense time and labor to writing JavaScript that recreates these features, and even then, no framework has done so perfectly.

- -

The upshot is that you should consider accessibility from the very start of every web project, but bear in mind that abstracted codebases that use frameworks are more likely to suffer from major accessibility issues if you don't.

- -

如何选择一个框架

- -

Each of the frameworks discussed in this module take different approaches to web application development. Each is regularly improving or changing, and each has its pros and cons. Choosing the right framework is a team- and project-dependent process, and you should do your own research to uncover what suits your needs. That said, we've identified a few questions you can ask in order to research your options more effectively:

- -
    -
  1. What browsers does the framework support?
    2. -
  2. What domain-specific languages does the framework utilize?
    3. -
  3. Does the framework have a strong community and good docs (and other support) available?
    4. -
- -

The table in this section provides a glanceable summary of the current browser support offered by each framework, as well as the domain-specific languages with which it can be used.

- -

Broadly, domain-specific languages (DSLs) are programming languages relevant in specific areas of software development. In the context of frameworks, DSLs are variations on JavaScript or HTML that make it easier to develop with that framework. Crucially, none of the frameworks require a developer to use a specific DSL, but they have almost all been designed with a specific DSL in mind. Choosing not to employ a framework’s preferred DSL will mean you miss out on features that would otherwise improve your developer experience.

- -

You should seriously consider the support matrix and DSLs of a framework when making a choice for any new project. Mismatched browser support can be a barrier to your users; mismatched DSL support can be a barrier to you and your teammates.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FrameworkBrowser supportPreferred DSLSupported DSLs
AngularIE9+TypeScriptHTML-based; TypeScript
ReactModern (IE9+ with Polyfills)JSXJSX; TypeScript
VueIE9+HTML-basedHTML-based, JSX, Pug
EmberModern (IE9+ in Ember version 2.18)HandlebarsHandlebars, TypeScript
- -
-

Note: DSLs we've described as "HTML-based" do not have official names. They are not really true DSLs, but they are non-standard HTML, so we believe they are worth highlighting.

-
- -

Citations for this table:

- - - -

Does the framework have a strong community?

- -

This is perhaps the hardest metric to measure, because community size does not correlate directly to easy-to-access numbers. You can check a project's number of GitHub stars or weekly npm downloads to get an idea of its popularity, but sometimes the best thing to do is search a few forums or talk to other developers. It is not just about the community's size, but also how welcoming and inclusive it is, and how good available documentation is.

- -

Opinions on the web

- -

Don't just take our word on this matter — there are discussions all over the web. The Wikimedia Foundation recently chose to use Vue for its front-end, and posted a request for comments (RFC) on framework adoption. Eric Gardner, the author of the RFC, took time to outline the needs of the Wikimedia project and why certain frameworks were good choices for the team. This RFC serves as a great example of the kind of research you should do for yourself when planning to use a front-end framework.

- -

The State of JavaScript survey is a helpful collection of feedback from JavaScript developers. It covers many topics related to JavaScript, including data about both the use of frameworks and developer sentiment toward them. Currently, there are several years of data available, allowing you to get a sense of a framework's popularity.

- -

The Vue team has exhaustively compared Vue to other popular frameworks. There may be some bias in this comparison (which they note), but it's a valuable resource nonetheless.

- -

客户端框架的替代方案

- -

If you’re looking for tools to expedite the web development process, and you know your project isn’t going to require intensive client-side JavaScript, you could reach for one of a handful of other solutions for building the web:

- - - -

Content management systems

- -

Content-management systems (CMSes) are any tools that allow a user to create content for the web without directly writing code themselves. They're a good solution for large projects, especially projects that require input from content writers who have limited coding ability, or for programmers who want to save time. They do, however, require a significant amount of time to set up, and utilizing a CMS means that you surrender at least some measure of control over the final output of your website. For example: if your chosen CMS doesn't author accessible content by default, it's often difficult to improve this.

- -

Popular examples include Wordpress, Joomla, and Drupal.

- -

Server-side rendering

- -

Server-side rendering (SSR) is an application architecture in which it is the server's job to render a single-page application. This is the opposite of client-side rendering, which is the most common and most straightforward way to build a JavaScript application. Server-side rendering is easier on the client's device, because you're only sending a rendered HTML file to them, but it can be difficult to set up compared to a client-side-rendered application.

- -

All of the frameworks covered in this module support server-side rendering as well as client-side rendering. Check out Next.js for React, Nuxt.js for Vue (yes it is confusing, and no, these projects are not related!), FastBoot for Ember, and Angular Universal for Angular.

- -
-

Note: Some SSR solutions are written and maintained by the community, whereas some are "official" solutions provided by the framework's maintainer.

-
- -

Static site generators

- -

Static site generators are programs that dynamically generate all the webpages of a multi-page website — including any relevant CSS or JavaScript — so that they can be published in any number of places. The publishing host could be a GitHub pages branch, a Netlify instance, or any private server of your choosing, for example. There are a number of advantages of this approach, mostly around performance (your user's device isn’t building the page with JavaScript; it's already complete) and security (static pages have fewer attack vectors). These sites can still utilize JavaScript where they need to, but they are not dependent upon it. Static site generators take time to learn, just like any other tool, which can be a barrier to your development process.

- -

Static sites can have as few or as many unique pages as you want. Just as frameworks empower you to quickly write client-side JavaScript applications, static site generators allow you a way to quickly create HTML files you would otherwise have written individually. Like frameworks, static site generators allow developers to write components that define common pieces of your web pages, and to compose those components together to create a final page. In the context of static site generators, these components are called templates. Web pages built by static site generators can even be home to framework applications: if you want one specific page of your statically-generated website to boot up a React application when your user visits it for example, you can do that.

- -

Static site generators have been around for quite a long time, but they have seen a bit of a revival in the recent history of the web. A handful of powerful options are now available, such as Hugo, Jekyll, Eleventy, and Gatsby.

- -

If you'd like to learn more about static site generators on the whole, check out Tatiana Mac's Beginner's guide to Eleventy. In the first article of the series, she explains what a static site generator is, and how it relates to other means of publishing web content.

- -

总结

- -

And that brings us to the end of our introduction to frameworks — we’ve not taught you any code yet, but hopefully we've given you a useful background on why you'd use frameworks in the first place and how to go about choosing one, and made you excited to learn more and get stuck in!

- -

Our next article goes down to a lower level, looking at the specific kinds of features frameworks tend to offer, and why they work like they do.

- -

{{NextMenu("Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Main_features", "Learn/Tools_and_testing/Client-side_JavaScript_frameworks")}}

- -

In this module

- - diff --git a/files/zh-cn/learn/tools_and_testing/cross_browser_testing/accessibility/index.html b/files/zh-cn/learn/tools_and_testing/cross_browser_testing/accessibility/index.html new file mode 100644 index 0000000000..704f595fb4 --- /dev/null +++ b/files/zh-cn/learn/tools_and_testing/cross_browser_testing/accessibility/index.html @@ -0,0 +1,624 @@ +--- +title: 解决常见的可访问性问题 +slug: Learn/Tools_and_testing/Cross_browser_testing/可访问性 +tags: + - CSS + - CodingScripting + - HTML + - JavaScript + - 初学者 + - 可访问性 + - 学习 + - 工具 + - 文章 + - 测试 + - 跨浏览器 + - 键盘 +translation_of: Learn/Tools_and_testing/Cross_browser_testing/Accessibility +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}
+ +

接下来，我们将关注可访问性，提供关于一些常见问题的信息，如何进行简单测试以及如何使用审核/自动化工具来查找可访问性问题。

+ + + + + + + + + + + + +
前提:熟悉HTML, CSS,和JavaScript语言; 理解跨浏览器测试原理
目标:能够诊断常见的可访问性问题，并使用适当的工具和技术解决问题。
+ +

什么是可访问性？

+ +

当我们在web技术的背景下说可访问性时，大多数人立即想到确保残疾人可以使用网站/应用程序，例如：

+ + + +

但是，说可访问性仅与残疾人有关是错误的。实际上，可访问性的目的是使你的网站/应用程序在尽可能多的环境中被尽可能多的人使用，而不仅仅是那些使用高性能台式计算机的用户。极端的例子可能包括：

+ + + +

在某种程度上，本模块都是关于可访问性的 — 跨浏览器测试可确保你的网站可以被尽可能多的人使用。这篇可访问性是什么？ 更全面透彻地定义了什么是可访问性。

+ +

也就是说，本文将涵盖跨浏览器和有关残疾人的测试问题以及他们如何使用Web。我们在其他地方已经讨论过其他领域，例如响应式设计问题和性能。

+ +
+

Note: 就像Web开发中的许多事情一样，可访问性不是100%的成功或失败可以定义的；对于所有内容而言，几乎不可能实现100％的可访问性，尤其是当站点变得越来越复杂时。我们更多的是通过防御性编码并遵循最佳实践，努力使尽可能多的人可以访问尽可能多的内容。

+
+ +

常见可访问性问题

+ +

在本节中，我们将围绕Web可访问性，详细介绍与特定技术相关的一些主要问题、要遵循的最佳实践，以及可以进行的一些快速测试，以查看你的网站是否朝着正确的方向发展。

+ +
+

Note: 可访问性在道德上是正确的事情，对企业也有好处(残疾用户，移动用户等构成了重要的细分市场), 并且在世界许多地方，提供出来的网络媒体资源无法为残疾人服务也是违法的。阅读无障碍指南和法律获取更多相关信息。

+
+ +

HTML

+ +

HTML语义化 (语义化正确地使用HTML标签)对于可访问性来说是开箱即用的 — 这类内容可供无视障人士阅读（前提是你不会做任何愚蠢的事情，例如使文本变小或使用CSS隐藏它），也可被屏幕阅读器（从字面上读出网页的应用）之类的辅助技术使用，并赋予其他优势。

+ +

语义化结构

+ +

HTML语义化最重要的捷径是为你的内容使用标题和段落的结构；这是因为屏幕阅读器用户倾向于将文档标题用作导航，以更快地找到他们需要的内容。如果你的内容没有标题，那么他们将获得的是一大坨文字，没有任何可定位的标记。坏的例子和好的例子如下：

+ +
<font size="7">My heading</font>
+<br><br>
+This is the first section of my document.
+<br><br>
+I'll add another paragraph here too.
+<br><br>
+<font size="5">My subheading</font>
+<br><br>
+This is the first subsection of my document. I'd love people to be able to find this content!
+<br><br>
+<font size="5">My 2nd subheading</font>
+<br><br>
+This is the second subsection of my content. I think is more interesting than the last one.
+ +
<h1>My heading</h1>
+
+<p>This is the first section of my document.</p>
+
+<p>I'll add another paragraph here too.</p>
+
+<h2>My subheading</h2>
+
+<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>
+
+<h2>My 2nd subheading</h2>
+
+<p>This is the second subsection of my content. I think is more interesting than the last one.</p>
+ +

此外，你的内容应该在逻辑顺序上讲得通的 — 你总能在以后再为它们写CSS，但你应该在一开始就确定内容正确的顺序。

+ +

作为测试，你可以关闭网站的CSS，然后看看没有了CSS网站是否能被理解。你可以通过从代码中删除CSS来手动完成此操作，但是最简单的方法是使用浏览器功能，例如：

+ + + +

使用键盘

+ +

某些HTML功能可以使用键盘来选择 — 这是默认的，从早期web开始就是这样的。具有此功能的元素是允许用户与网页交互的常见元素，比如links, {{htmlelement("button")}}s, 以及表单元素，比如{{htmlelement("input")}}.

+ +

浏览native-keyboard-accessibility.html (查看源码) 尝试一下— 在新标签页中打开它，然后尝试按Tab键；按下几下后，你应该看到标签焦点开始在不同的可聚焦元素之间移动；在每个浏览器中，被聚焦的元素都被赋予突出的默认样式 (不同的浏览器表现略有不同) 以便你能分辨聚焦在哪个元素上。

+ +

+ +

然后，你可以按Enter / Return键来关注焦点链接，或者按一个按钮（我们已经包含一些JavaScript来使按钮提醒消息），或者在输入框开始输入文本，（其他表单元素具有不同的控件，例如{{htmlelement("select")}}元素可以使用向上和向下箭头键显示和循环显示其选项）。

+ +

请注意，不同的浏览器可能具有不同的键盘控制选项。大多数现代浏览器都遵循上述的标签模式（你也可以执行Shift + Tab来向后移动可聚焦元素），但是某些浏览器具有自己的特性：

+ + + +
+

重要: 你应该在所写的任何新页面上执行这种测试 — 确保可以通过键盘使用功能。

+
+ +

这个例子强调了正确使用语义元素的重要性。可以用CSS将任何元素的样式设置为看起来像链接或按钮，并使用JavaScript让其表现为像链接或按钮一样，但实际上它们不是链接或按钮，你将失去很多语义化元素带给你的可访问性。因此，尽量避免这样做。

+ +

另一个技巧 — 如我们的示例所示，你可以使用:focus伪类控制可聚焦元素在聚焦时的外观。最好将焦点和悬停样式加重显示，这样无论是使用鼠标还是键盘的用户，都能直观地察觉控件在被激活时将执行的操作

+ +
a:hover, input:hover, button:hover, select:hover,
+a:focus, input:focus, button:focus, select:focus {
+  font-weight: bold;
+}
+ +
+

Note: 如果你决定使用CSS删除默认的焦点样式，请确保将其替换为更适合你的设计的其他样式 — 这是一种非常有价值的可访问性工具，不应删除。

+
+ +

模拟键盘

+ +

有时可能无法使用键盘完成可访问性。你可能有一个语义不是很好的网站（也许你最终得到了一个糟糕的CMS网页，该CMS生成了由<div> 组成的按钮），或者你正在使用一个没有内置键盘可访问性的复杂控件，例如HTML5 {{htmlelement("video")}} 元素（令人惊奇的是，Opera是唯一允许你在<video>元素的默认浏览器控件之间进行制表的浏览器）。你有几种选择：

+ +
    +
  1. 使用<button>元素（默认情况下都是可以在button间使用Tab键）和JavaScript创建自定义控件，以连接其功能。有关此示例，请参见Creating a cross-browser video player。
    2. +
  2. 通过JavaScript创建键盘快捷键，因此当你按键盘上的某些键时，功能被激活。请参阅Desktop mouse and keyboard controls，以获取一些可用于任何目的（比如游戏）的例子。
    3. +
  3. 使用一些有趣的策略来伪造按钮行为。以我们的fake-div-buttons.html示例为例（查看源码）。这里我们通过为每个假按钮赋予属性tabindex="0"（请参阅​​WebAIM的tabindex文章以获取更多详细信息），使假的<div>按钮能够被聚焦（包括通过制表符）。这使我们可以跳到按钮上，但不能通过回车键激活它们。为此，我们必须添加以下JavaScript代码： + 
    document.onkeydown = function(e) {
+  if(e.keyCode === 13) { // The Enter/Return key
+    document.activeElement.onclick(e);
+  }
+};
    + 在这里，我们向document对象添加了一个监听器，以检测何时按下了键盘上的按钮。我们通过事件对象的keyCode属性检查按下了什么按钮；如果它是与回车键匹配的键码，则使用document.activeElement.onclick()运行存储在按钮的onclick处理程序中的函数。document.activeElement为我们提供了当前页面上被聚焦的元素。
    4. +
+ +
+

Note: 仅当你通过事件处理程序属性（例如onclick）设置原始事件处理程序时，此技术才有效。addEventListener将无法正常工作。重新构建功能会有很多额外的麻烦。并且肯定还有其他问题。最好能从根源解决问题，使用正确的语义化元素。

+
+ +

替代文本

+ +

替代文本对于可访问性非常重要 — 如果一个人有视觉或听觉障碍使他们无法看到或听到某些内容，那么这就是一个问题。可用的最简单的文本替代方法是alt属性，我们应该在所有包含相关内容的图像上包括该属性。其中应包含对图像的描述，该描述可在页面上成功传达其含义和内容，并由屏幕阅读器读取并读出给用户。

+ +
+

Note: 更多信息请阅读Text alternatives

+
+ +

可以通过多种方法来测试缺少的替代文本，例如，使用可访问性{{anch("审计工具")}}。

+ +

对于视频和音频内容，Alt文本稍微复杂一些。有一种方法可以定义文本轨道（例如，字幕）并在播放视频时以{{htmlelement("track")}}元素和WebVTT格式的形式显示它们（请参见Adding captions and subtitles to HTML5 video以获取详细信息）。这些功能的浏览器兼容性相当好，但是如果你想提供音频的替代文本或支持较旧的浏览器，则在页面某处或单独页面上显示一个简单的文本记录可能是个好主意。

+ +

元素关系和上下文

+ +

HTML中有某些功能和最佳实践，旨在提供元素之间的上下文和关系。三个最常见的示例是链接，表单标签和数据表。

+ +

使用屏幕阅读器的人们通常会使用一项共同的功能，即他们会拉出页面上所有链接的列表。在这种情况下，链接文本需要脱离上下文。例如，标记为“单击此处”，“单击此处”等的链接列表确实对可访问性不利。链接文本最好在上下文和上下文之外都有意义。

+ +

表单{{htmlelement("label")}}元素是允许我们使表单可访问的主要功能之一。表单的麻烦在于，你需要标签来说明应在每个表单输入中输入哪些数据。每个标签都必须包含在{{htmlelement("label")}}内，以将其明确链接到其对应的表单输入框（属性值的每个<label>的for属性值必须与表单元素id值匹配），即使源顺序不是完全合乎逻辑的，也能提供很好的可访问性。

+ +
+

Note: 更多关于链接文本和表单标签，请阅读有意义的文字标签

+
+ +

最后，简要介绍一下数据表。基本数据表可以用非常简单的标记编写（请参阅bad-table.html和源码)），但这存在问题 — 屏幕阅读器用户无法将行或列作为数据分组关联在一起，但你需要知道标题行是什么，以及标题行行的标题还是列的标题等。这些只能从可视化的表格才能知道。

+ +

相反，如果你看一下我们的punk-bands-complete.html示例（示例，源码），则可以在此处看到一些可访问性辅助，例如表头（{{htmlelement("th")}}和作用域属性），{{htmlelement("caption")}}元素等。

+ +
+

Note: 更多信息，请阅读可访问的表格

+
+ +

CSS

+ +

CSS往往提供的基本可访问性功能要比HTML少得多，但是如果使用不当，它仍然会对可访问性造成同样的损害。下面是一些涉及CSS的可访问性的点：

+ + + +

还有其他几个需要注意的地方。

+ +

颜色和颜色对比度

+ +

为你的网站选择配色方案时，应确保文本（前景）颜色与背景颜色形成鲜明对比。你的设计可能看起来很酷，但是如果视力障碍者（例如色盲）无法阅读你的内容，那就不好了。使用WebAIM的Color Contrast Checker之类的工具来检查你的方案是否有足够对比度。

+ +

另一个提示是不要仅依靠颜色来表示界标/信息，因为这对于看不见颜色的人来说是不好的。例如，不要将所需的表单字段标记为红色，而应使用星号和红色标记它们。

+ +
+

Note: 高对比度也可以让使用带有光滑屏幕的设备（例如智能手机或平板电脑）的人在明亮的环境（例如阳光）下可以更好地阅读页面。

+
+ +

隐藏的内容

+ +

在许多情况下，视觉设计要求并非一次显示所有内容。例如，在我们的Tabbed info box example“示例（查看源码）中，我们有三个信息面板，但是我们将它们放在彼此的顶部，用户可以通过单击以显示每个选项卡（也可以通过键盘访问 — 可以使用Tab键和回车键选择它们）。

+ +

+ +

屏幕阅读器用户根本不关心这些，只要源内容顺序有意义，他们就很满意，并且他们可以全部获取。绝对定位（在本示例中使用的定位）通常被视为隐藏内容以产生视觉效果的最佳机制之一，因为它不会阻止屏幕阅读器获取相关内容。

+ +

另一方面，你不应该使用{{cssxref("visibility")}}:hidden或者{{cssxref("display")}}:none, 因为它们会让屏幕阅读器取不到那些内容，除非你真的想让屏幕阅读器不读取那些内容。

+ +
+

Note: Invisible Content Just for Screen Reader Users有更多关于这个话题的详细信息

+
+ +

JavaScript

+ +

就可访问性而言，JavaScript具有与CSS相同的问题 — 如果使用不当或使用过度，可访问性可能会很糟糕。我们已经提到了与JavaScript相关的一些可访问性问题，主要是在HTML语义化那块 — 你应该始终使用适当的语义化HTML来在合适的地方实现功能，例如，适当地使用链接和按钮。尽量不要使用JavaScript代码中结合<div>元素来伪造功能 — 容易出错，并且比直接使用HTML标签还要做更多的工作。

+ +

简单的功能

+ +

通常，简单的功能只应使用HTML标签完成 — JavaScript仅用于增强功能，而不能用于实现简单功能。好的JavaScript用法包括：

+ + + +
+

Note: WebAIM的Accessible JavaScript提供了一些关于JavaScript可访问性注意事项的信息。

+
+ +

更复杂的JavaScript实现可能会带来可访问性问题 — 你需要尽力而为。例如，期望让使用WebGL编写的复杂3D游戏对盲人来说100％可访问性是不合理的，但是你可以实现键盘控件，以便非鼠标用户可以使用它，并使配色方案具有足够的对比度供有颜色分辨障碍的人使用。

+ +

复杂的功能

+ +

可访问性存在问题的主要领域之一是复杂的应用程序，其中涉及复杂的表单控件（例如日期选择器）和动态内容，内容会经常增量更新。

+ +

非自带的复杂的表单控件可能会存在问题，因为它们往往涉及大量嵌套的<div>，浏览器默认情况下不知道如何处理它们。如果你自己开发控件，则需要确保它们可以通过键盘访问。如果你使用的是某种第三方框架，请在开始使用之前仔细检查可用的选项以了解它们是否具有完备的可访问性。例如，Bootstrap就对可访问性有相当好的支持（尽管Rhiana Heath的Making Bootstrap a Little More Accessible探讨了它的一些问题（主要与色彩对比度有关），并着眼于一些解决方案）。

+ +

定期更新的动态内容可能会成为问题，因为屏幕阅读器用户可能会错过这些内容，尤其是在意外更新的情况下。如果你有一个包含主要内容面板的单页应用程序，该应用程序使用XMLHttpRequest或Fetch定期更新，那么屏幕阅读器用户可能会错过这些更新。

+ +

WAI-ARIA

+ +

你是否需要使用这种复杂的功能，或者使用普通的旧语义化HTML代替？如果确实需要复杂性，则应考虑使用WAI-ARIA（Accessible Rich Internet Applications - 可访问的互联网应用），该规范为诸如复杂的表单控件和更新面板之类的项目提供了语义（以新的HTML属性形式），这样大部分浏览器和屏幕阅读器就能理解内容。

+ +

要处理复杂的表单窗口小部件，你需要使用ARIA属性（例如roles）来声明窗口小部件中不同元素的角色（例如，它们是选项卡还是选项卡面板？），用aria-disabled来表示控件是否禁用等。

+ +

要处理内容定期更新的区域，可以使用aria-live属性，该属性标识更新区域。它的值指示屏幕阅读器如何处理更新内容：

+ + + +

例子如下：

+ +
<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>
+ +

浏览Freedom Scientific的ARIA (Accessible Rich Internet Applications)动态更新区域示例 — 高亮显示的段落每10秒更新一次内容，屏幕阅读器应将此内容读出给用户。ARIA Live Regions - Atomic是另一个很有用的例子。

+ +

我们这里没有足够的空间来详细介绍WAI-ARIA，你可以在WAI-ARIA basics了解更多。

+ +

可访问性测试工具

+ +

现在，我们已经介绍了不同Web技术的可访问性注意事项，包括一些测试方法（例如键盘导航和颜色对比度检查器），让我们看一下在进行可访问性测试时可以使用的其他工具。

+ +

审计工具

+ +

你可以使用许多审计工具检查你的网页，这些审计工具将检查它们并返回页面上存在的可访问性问题列表。一些审计工具：

+ + + +

看下面的例子，我们用的是Tenon。

+ +
    +
  1. 访问Tenon主页。
    2. +
  2. 使用bad-semantics.html示例测试，输入链接地址并按下Analyse Your Webpage（译者注：开始分析你的网页）。
    3. +
  3. 下滑，直到你看到错误/描述部分，如下图。
    4. +
+ +

+ +

你还可以探索一些选项（请参阅页面顶部附近的Show Options（译者注：显示选项）链接），或者使用Tenon的API。

+ +
+

Note: 这些工具不足以单独解决你的所有可访问性问题。你需要将这些，知识和经验，用户测试等结合起来才能获得完整的解决方案。

+
+ +

自动化工具

+ +

Deque's aXe tool比我们上面提到的审计工具更优秀。和其他工具一样，它检查页面并返回可访问性错误。它很有用，可以提供浏览器扩展程序：

+ + + +

扩展程序将可访问性选项卡添加到浏览器开发人员工具。例如，我们安装了Firefox版本，然后使用它来审核bad-table.html示例。我们得到以下结果：

+ +

+ +

aXe也可以使用npm安装，并且可以与任务运行器（如Grunt 和Gulp），自动化框架（如Selenium和Cucumber），单元测试框架（如Jasmin）集成，以及更多其他功能（详见main aXe page ）。

+ +

屏幕阅读器

+ +

为了了解有严重视力障碍的人是如何浏览网页的，我们需要测试屏幕阅读器。有几款屏幕阅读器：

+ + + +

通常，屏幕阅读器是独立运行的应用程序，并且不仅仅支持阅读网页，也支持阅读其他应用程序。也有例外（比如ChromeVox是一个浏览器扩展程序）。不同的屏幕阅读器可能在控制键和表现上稍有不同，所以你必须查阅你选择的屏幕阅读器的文档来获取相关细节。总体来说他们是大同小异的。

+ +

一起看一下我们对几款不同的屏幕阅读器的测试。这将帮助你大致了解它们如何工作以及如何测试它们。

+ +
+

Note: WebAIM的 Designing for Screen Reader Compatibility提供了一些关于屏幕阅读器的使用和如何开发应用以最好的适用屏幕阅读器的信息。你也可以看下Screen Reader User Survey #6 Results这篇有关屏幕阅读器一些有趣的统计信息的文章。

+
+ +

VoiceOver

+ +

VoiceOver (VO)是Mac/iPhone/iPad上的免费应用，所以如果你使用苹果公司的产品，可以用VO来进行测试。 我们在Mac OS X 系统上测试了它。

+ +

按下Cmd + Fn + F5打开它。如果你之前没用过VO，将会出现一个可以选择是否开启VO的欢迎界面，并且还会有教程指导你如何使用。再次按下Cmd + Fn + F5可以关闭。

+ +
+

Note: 你应该至少看一遍教程，它对于你了解VO是非常有用的。

+
+ +

当VO开启时，你会看到一个会显示当前选中信息的黑色框在屏幕的左下角，除此之外屏幕显示大体还是相同的。当前选中的部分也会出现一个黑色的边框以进行高亮显示，这个黑色框就是VO的光标。

+ +

+ +

在使用中，你会用到"VO修饰键"，"VO修饰键"是一个单独键或组合键，当你使用VO的快捷键时，你需要额外按下这个"VO修饰键"。屏幕阅读器通常都会有修饰键，防止它们的快捷键和其他程序的快捷键冲突。VO的修饰键是CapsLock, 或Ctrl + Option。

+ +

VO有很多快捷键，我们没有全部列出来。只把测试网页可访问性常用的一些在下面列出了。表格里，"VO"代表"VO修饰键"。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
常用的VO快捷键
快捷键描述
VO + 方向键移动VO光标
VO + 空格键选择/激活高亮的部分，包括Rotor里的内容（关于Rotor见下面）
VO + Shift + 下移动到组合项目里（比如HTML表格，或表单等）。进入组合里，你能使用下面的快捷键。
VO + Shift + 上离开组合项目
VO + C(当在表格里面时) 阅读当前列的头部
VO + R(当在表格里面时) 阅读当前行的头部
VO + C + C (当在表格里面时) 阅读当前列，包括列头
VO + R + R (当在表格里面时) 阅读当前行，包括对应于每个小行的头
VO + 左, VO + 右(当在水平的选项卡里面时，比如日期选择或时间选择) 切换选项
VO + 上, VO + 下(当在垂直的选项卡里面时，比如日期选择或时间选择) 切换选项
VO + U使用Rotor。Rotor使用列表展示标题，链接，表单选项等，以便为我们提供便利的导航。
VO + 左, VO + 右(当在Rotor里) 切换到其他列表
VO + 上, VO + 下(当在Rotor里) 在当前列表里，切换到其他项
Esc(当在Rotor里) 推出Rotor
Ctrl(当VO阅读时) 暂停/继续
VO + Z重复上一句话
VO + D进入Mac的程序坞，你能选择运行哪个应用
+ +

看起来很多，但当你用起来时还好，因为VO通常会给你提醒，在哪里应该用哪个快捷键。现在试试运行VO，在{{anch("屏幕阅读器测试")}}屏幕阅读器测试章节做个测试吧。

+ +

NVDA

+ +

NVDA只能运行在Window系统，你需要安装它。

+ +
    +
  1. 在nvaccess.org下载。你能选择免费下载，或赞助后再下载；你需要在下载前提供你的邮箱地址。
    2. +
  2. 下载完成后，开始安装 - 双击安装程序，接受条款，一步步按提示来。
    3. +
  3. 双击NVDA程序或快捷方式，或者按下Ctrl + Alt + N打开它。你会看见欢迎界面。你能选择一些选项，然后按下OK继续。
    4. +
+ +

NVDA现在在你的电脑上开启了。

+ +

在使用中，你会用到"NVDA修饰键"，"NVDA修饰键"是一个单独键，当你使用NVDA的快捷键时，你需要额外按下这个"NVDA修饰键"。屏幕阅读器通常都会有修饰键，防止它们的快捷键和其他程序的快捷键冲突。NVDA的修饰键是Insert键（默认）, 或CapsLock键（在欢迎界面可以选择使用该键）。

+ +
+

Note: 关于高亮方面，NVDA比VoiceOver做的更好。当滚动过标题、列表等元素时，你选中的项目会被一个细微的边框包住以高亮，但不是对于所有元素都是这样的。如果你感觉迷失方向了，可以按Ctrl + F5刷新页面，并从顶部重新开始。

+
+ +

NVDA有很多快捷键，我们没有全部列出来。只把测试网页可访问性常用的一些在下面列出了。表格里，"NVDA"代表"NVDA修饰键"。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
常用的NVDA快捷键
快捷键描述
NVDA + Q关闭NVDA
NVDA + 上阅读当前行
NVDA + 下在当前位置开始阅读
上和下, 或者Shift + Tab 和Tab移动到上/下一项，开始阅读
左和右移动到当前项的上/下一个字符，开始阅读
Shift + H 和 H移动到上/下一标题，开始阅读
Shift + K 和 K移动到上/下一链接项，开始阅读
Shift + D 和 D移动到上/下一文档界标（比如<nav>），开始阅读
Shift + 1–6 和 1–6移动到上/下一标题（标题1 - 6），开始阅读
Shift + F 和 F移动到上/下一表单选项，聚焦
Shift + T 和 T移动到上/下一数据表，聚焦
Shift + B 和 B移动到上/下一按钮，阅读它的label
Shift + L 和 L移动到上/下一列表，阅读它的第一项
Shift + I 和 I移动到上/下一列表，开始阅读
Enter/Return(当链接或按钮或其他可激活的项选中时) 激活项
NVDA + 空格(当选中表单时) 进入表单，或如果已经在表单里的情况下，离开表单
Shift Tab 和 Tab(当在表单里面时) 切换到下一个input
上 和 下(当在表单里面时) 改变input的值(例如选择框).
空格(当在表单里面时) 选择已选中的值
Ctrl + Alt + 方向键(当选中表格时) 切换表格单元格
+ +

屏幕阅读器测试

+ +

现在你学会了如何使用屏幕阅读器，来使用它做一些可访问性测试吧。这样你才能了解屏幕阅读器在好的网页和坏的网页之间不同的表现：

+ + + +

用户测试

+ +

如上所述，你不能仅依靠自动化工具来确定网站上的可访问性问题。建议在制定测试计划时，包含一些用户测试可访问性的计划(有关更多内容，请参阅前面的用户测试部分)。尝试让一些屏幕阅读器用户，一些全键盘用户，一些有听觉障碍的用户或其他用户参与测试，以满足你的需求。

+ +

测试可访问性检查清单

+ +

以下列表提供了一个清单，供参考，以确保已对项目执行建议的可访问性测试：

+ +
    +
  1. 确保HTML尽可能是语义化的。验证是一个好方法, 就像使用审计工具。
    2. +
  2. 检查当关闭CSS时，你的内容能够被理解。
    3. +
  3. 确认功能是全键盘可访问的。使用Tab键、回车键等做测试。
    4. +
  4. 确保非文本内容有替代文本。 审计工具能够很好地发现问题。
    5. +
  5. 确保颜色和颜色对比度是可接受的，使用合适的工具测试。
    6. +
  6. 确保隐藏的内容可以被屏幕阅读器读取。
    7. +
  7. 尽可能的使功能在没有JavaScript的情况下也可以正常使用。
    8. +
  8. 在合适的地方使用ARIA来提供可访问性。
    9. +
  9. 使用审计工具测试一下你的网站。
    10. +
  10. 使用屏幕阅读器实际测试一下。
    11. +
  11. 在你的网站上可以添加可访问性策略/声明，以说明你的为可访问性做了什么。
    12. +
+ +

寻找帮助

+ +

可访问性还会遇到许多其他问题。你要学会如何在线查找答案。请查阅HTML和CSS文章的“寻找帮助”部分，以获取一些指导。 

+ +

总结

+ +

希望本文能让你了解可访问性，以及帮助你解决遇到的一些可访问性问题。

+ +

下一篇文章，我们将详细介绍特征检测。

+ +

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}

+ +

指南

+ + diff --git a/files/zh-cn/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html b/files/zh-cn/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html new file mode 100644 index 0000000000..fb01cd2843 --- /dev/null +++ b/files/zh-cn/learn/tools_and_testing/cross_browser_testing/testing_strategies/index.html @@ -0,0 +1,367 @@ +--- +title: 进行测试的策略 +slug: Learn/Tools_and_testing/Cross_browser_testing/测试策略 +tags: + - 测试 + - 测试策略 + - 用户测试 + - 自动化测试 + - 虚拟机 仿真器 + - 跨浏览器测试 +translation_of: Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}
+ +


+ 这篇文章主要是讨论如何进行跨浏览器测试，回答一些比较常见的疑惑，譬如：“什么是跨浏览器测试？”，“会遇到哪些常见的问题？”以及“如何测试、区分以及修复问题？”

+ + + + + + + + + + + + +
准备:熟练掌握 HTML, CSS, 和 JavaScript 语言; 了解跨浏览器测试的核心概念。
对象:了解跨浏览器测试所涉及的高级概念。
+ +

是否需要测试？

+ +

开始跨浏览器测试（cross browser testing）之前您需要确定哪些浏览器将进入被测试名单。测试所有用户可能使用的浏览器或移动设备是不可能的——数量太大，而且浏览器和设备总在不断更新。

+ +

可行的替代方案是，尝试确保您的网站适用于最常见的浏览器和设备，然后进行防御性编码，以便为您的网站提供最广泛的支持范围。

+ +

防御性编码的实质是一种智能回退措施：如果某个功能或样式在浏览器中不起作用，该网站将将降级为不太令人兴奋的东西，但仍然能提供可接受的用户体验——核心是：虽然网站看起来不那么漂亮，仍然可以访问。

+ +

本章的目的是建立一个供您在测试时参考的浏览器/设备图表。 您可以根据需要将其设置成简单或复杂版本——常见的方法是具有多个等级的支持，例如：

+ +
    +
  1. A 级：普通/现代浏览器（仍在广泛使用）：需要彻底测试并提供全面支持。
    2. +
  2. B 级：较旧/较少的浏览器 （少数用户还在使用）：测试并提供更基本的体验，以提供对核心信息和服务的完全访问。
    3. +
  3. C 级：稀有/未知浏览器 ： 不进行测试，假设网站内容可以显示。 在我们的防御性编码起效的情况下，用户可以访问到网页的全部内容。
    4. +
+ +

在以下各节中，我们将以此等级为参考构建支持图表。

+ +
+

注意：雅虎最先使这一方法流行起来，详情参见《浏览器分级支持系统》（ Graded browser Support）。

+
+ +

有根据地假设

+ +

您可以称之为“假设”或“直觉”。这不是一种准确，科学的方法，但作为具有网络行业经验的人，您至少应该对待测试的一些浏览器有些想法。这将形成一个良好的初级浏览器分级支持系统。

+ +

例如，如果您居住在西欧或北美，您会发现许多人使用 Windows 和 Mac 的台式机或笔记本电脑，主要浏览器是 Chrome，Firefox，Safari，IE 和 Edge。您可以测试前三个浏览器最近的三个版本，因为它们会定期更新。对于Edge和IE，您应当近期的多个版本。这些浏览器都应该属于A级。

+ +
+

注意：您一次只能在计算机上安装一个版本的 IE 或 Edge，因此您可能必须使用虚拟机或其他方法来执行所需的测试。稍后请参阅虚拟机部分{{anch("Virtual machines")}}。

+
+ +

很多人使用 iOS 和 Android，因此您可能还想测试最新版本的 iOS Safari，最近几个版本的 Android stock 浏览器，以及适用于 iOS 和 Android 的 Chrome 和 Firefox。理想情况下，您应该在手机和平​​板电脑上测试这些，以确保响应式设计的正常运行。

+ +

您也许知道很多人仍然在使用 IE 9。这一版本陈旧而且功能较少，所以让我们把它放在B级别。

+ +

到目前为止，这为我们提供了以下支持级别：

+ +
    +
  1. A 级：用于 Windows / Mac 的 Chrome 和 Firefox，用于 Mac 的 Safari，用于 Windows的 Edge 和 IE（每个版本的最后两个版本），用于 iPhone / iPad 的 iOS Safari，用于手机/平板电脑的 Android stock 浏览器（最后两个版本），用于手机和平板电脑上的 Chrome 和适用于 Android 的Firefox（最后两个版本）。
    2. +
  2. B 级：适用于 Windows 的 IE 9
    3. +
  3. C 级：无
    4. +
+ +

如果您居住在其他地方，或者正在开发其他地方（例如某些国家或地区）的网站，那么您可能会有不同的常用浏览器进行测试。

+ +
+

注意：“我老板用Blackberry，所以我们最好确保它看起来很好”也可以是一个有说服力的论点。

+
+ +

浏览器支持检测

+ +

您可以调用的一个有用的措施是浏览器支持统计信息,用于告知您的浏览器测试选项。有许多网站提供此类统计信息,例如:

+ + + +

这些都以北美为中心,并不特别准确,但它们可以让您了解大趋势。

+ +

例如,让我们转到 Netmarketshare。您可以看到 Opera 被列为具有小但可见的使用数字,因此,我们也应该将其添加到支持图表中,作为 C 级。

+ +

IE8 被列为重要,但它较老且不再能够。Opera Mini 非常重要,但在运行时运行复杂的 JavaScript 方面,它的能力并不大(有关详细信息,请参阅 Opera Mini and JavaScrip)。我们也应该把它放到B级。

+ +

使用分析工具

+ +

更准确的数据源,如果你能得到它,来自像Google Analytics这样的分析应用程序。这是一个应用程序,将为您提供准确的统计数据,究竟是什么浏览器的人正在使用浏览您的网站。当然,这依赖于您已经有一个网站使用它,所以它是没有多大的适合全新的网站。

+ +

但是,分析历史记录可用于查找支持统计信息以影响公司网站的新版本或要添加到现有站点的新功能。如果您有这些可用,它们比上述全球浏览器统计信息更准确。

+ +

配置Google分析

+ +
    +
  1. 首先,您需要一个谷歌帐户。使用此帐户可登录Google Analytics。 
    2. +
  2. 选择 Google Analytics (web))选项,然后单击"注册"按钮。
    3. +
  3. 在注册页面中输入您的网站/应用详细信息。这是相当直观的设置;获得正确的最重要的字段是网站 URL。这需要是您的网站/应用的根 URL。
    4. +
  4. 填写完所有内容后,按"获取跟踪 ID"按钮,然后接受显示的服务条款。
    5. +
  5. 下一页为您提供一些代码段和其他说明。对于基本网站,您需要做的是复制网站跟踪代码块,并将其粘贴到您要在网站上使用 Google Analytics 跟踪的所有不同页面。您可以在关闭</body>标记下方,也可以位于其他适当位置,以防止其与应用程序代码混淆。
    6. +
  6. 将更改上载到开发服务器,或将代码上载到其他任何位置。
    7. +
+ +

就是这样！您的网站现在应该准备好开始报告分析数据。

+ +

学习分析数据

+ +

现在,您应该能够返回 Analytics Web主页,并开始查看您收集的有关网站的数据(当然,您需要留出一点时间才能真正收集一些数据)。

+ +

默认情况下,您应该看到报告选项卡,如下所示:

+ +

+ +

有大量的数据,你可以看看使用谷歌分析––自定义报告在不同的类别,等等––我们没有时间讨论这一切。 Getting started with Analytics 为初学者提供了一些有关报告(以及更多)的有用指导。

+ +

还应鼓励您查看左侧的不同选项,并查看您可以找到哪些类型的数据。例如,您可以通过从左侧菜单中选择" Audience > Technology > Browser & OS"来了解用户正在使用的浏览器和操作系统。

+ +
+

注意:使用 Google 分析时,您需要提防误导性偏见,例如"我们没有 Firefox 移动用户"可能会导致您不必为 Firefox 移动提供支持。但是,你不会有任何火狐移动用户,如果该网站被打破在火狐手机摆在首位。

+
+ +

其他注意事项

+ +

您可能还应包括其他注意事项。您绝对应该将辅助功能作为 A 级测试要求(我们将在处理常见辅助功能问题一文中介绍您应该测试的内容)

+ +

此外,您可能还有其他注意事项。如果要创建某种公司 Intranet,以便向经理提供销售数据,并且例如,所有经理都提供了 Windows 手机,则可能需要将移动 IE 支持作为优先事项。

+ +

最终的支持图表

+ +

因此,我们的最终支持图表最终将如下所示:

+ +
    +
  1. A 级:适用于 Windows/Mac 的 Chrome 和 Firefox、适用于 Mac 的 Safari、Windows 的"边缘"和"IE"(每个版本的最后两个版本)、iPhone/iPad 的 iOS Safari、手机/平板电脑上的 Android 股票浏览器(最后两个版本)、适用于 Android 的 Chrome 和 Firefox(最后两个版本)在手机平板电脑上.通过常见测试的可访问性。
    2. +
  2. B 级:IE 8 和 9 用于 Windows,Opera Mini。
    3. +
  3. C级:Opera,其他合适的现代浏览器。
    4. +
+ +

你想要测试什么？

+ +

当您的代码库有需要测试的新添加项时,在开始测试之前,应编写出需要通过才能接受的测试要求列表。这些要求可以是可视的,也可以是功能性的, 两者结合起来, 成为可用的网站功能。

+ +

思考下面的例子 (查看源码 , 在线预览):

+ +

+ +

此功能的测试标准可以这样编写:

+ +

A 级和 B 级:

+ + + +

A 级:

+ + + +

You may notice from the text in the example that it won't work in IE8 — this is a problem according to our support chart, which you'll have to work on, perhaps by using a feature detection library to implement the functionality in a different way if the browser doesn't support CSS transitions (see Implementing feature detection, later on in the course).您可能会从示例中的文本中注意到它在 IE8 中不起作用 ––根据我们的支持图表,这是一个问题,您必须处理这个问题,如果浏览器不采用其他方式,则可能使用功能检测库以不同的方式实现功能（如果浏览器不支持 CSS 转换的话）(请参阅实现功能检测,稍后将在本课程中)。

+ +

您可能还注意到,该按钮仅使用键盘无法使用, 这也需要纠正。也许我们可以使用一些JavaScript来实现一个键盘控件的切换,或者完全使用一些其他的方法?

+ +

这些测试条件很有用,因为:

+ + + +

建立一个测试实验室

+ +

执行浏览器测试的一个选项是自己进行测试。为此,您可能需要使用实际物理设备和模拟环境的组合(使用仿真器或虚拟机)。

+ +

真实设备

+ +

通常最好让一个实际的设备运行您要测试的浏览器 , 这在行为和整体用户体验方面提供了最高的准确性。对于合理的低级设备实验室,您可能需要以下内容:

+ + + +

如果可以获取这些选项,则以下是不错的选项:

+ + + +

您的主工作计算机也可以用于安装其他工具以用于特定目的,例如辅助功能审核工具、屏幕阅读器和仿真器/虚拟机。

+ +

一些大型公司拥有设备实验室,这些实验室库存了大量不同的设备,使开发人员能够在非常具体的浏览器/设备组合上查找 Bug。较小的公司和个人通常负担不起如此复杂的实验室,因此倾向于使用较小的实验室、仿真器、虚拟机和商业测试应用程序。

+ +

我们将介绍下面的其他选项。

+ +
+

注意:已做出一些努力用来创建可公开访问的设备实验室, 请参阅 Open Device Labs。

+
+ +
+

注意:我们还需要考虑辅助功能 — 可以在计算机上安装许多有用的工具,以方便辅助功能测试,但我们将在本课程的后面部分介绍"处理常见辅助功能问题"一文中的工具。

+
+ +

模拟器

+ +

仿真器基本上是在计算机内运行并模拟某种设备或特定设备条件的程序,允许您比查找要测试的特定硬件/软件组合更方便地执行某些测试。

+ +

仿真器可能与测试设备条件一样简单。例如,如果要对宽度/高度媒体查询进行一些快速而粗劣的测试以进行响应式设计,则可以使用 Firefox 的Responsive Design Mode。 Safari 也有类似的模式,可以通过访问 “Safari > 首选项”和"显示开发"菜单,然后选择"开发"&gt;"输入响应式设计模式"来启用。  Chrome 也有类似的功能:设备模式(请参阅Simulate Mobile Devices with Device Mode)。

+ +

不过,您经常必须安装某种仿真器。要测试的最常见设备/浏览器如下所示:

+ + + +

您也经常可以为其他移动设备环境找到模拟器，例如：

+ + + +
+

注意：许多模拟器实际上需要使用虚拟机（见下文）;在这种情况下，通常提供指令，和/或将虚拟机的使用合并到仿真器的安装程序中。

+
+ +

虚拟机

+ +

虚拟机是在台式计算机上运行的应用程序，允许您运行整个操作系统的仿真，每个操作系统都划分在自己的虚拟硬盘驱动器中（通常由主机硬盘上存在的单个大文件表示）。有许多流行的虚拟机应用程序可用，例如Parallels，VMWare和Virtual Box;我们个人喜欢后者，因为它是免费的。

+ +
+

注意：您需要可用的大容量硬盘空间来运行虚拟机模拟;模拟的每个操作系统都会占用大量内存。您可能倾向于为每次安装选择所需的硬盘空间;你也可能会试图侥幸使用10GB空间，但会被建议使用50GB空间或更多，以便让操作系统运行可靠。大多数虚拟机应用程序提供的一个很好的选择是创建一个动态分配（dynamically allocated）的硬盘驱动器，它会随着需要的增长和缩小而动态改变。

+
+ +

要使用虚拟盒，您需要：

+ +
    +
  1. 获取要模拟的操作系统的安装程序磁盘或映像（例如ISO文件）。 Virtual Box无法提供这些;大多数，如Windows操作系统，是无法自由分发的商业产品。
    2. +
  2. 下载适用于您的操作系统的相应安装程序并进行安装。
    3. +
  3. 打开应用程序;您将看到如下视图：
    4. +
  4. 要创建新虚拟机，请按左上角的“新建”按钮。
    5. +
  5. 按照说明进行操作，并根据需要填写以下对话框。你会： +
      +
    1. 为新虚拟机提供名称
      2. +
    2. 选择要在其上安装的操作系统和版本
      3. +
    3. 设置应分配多少RAM（我们建议使用2048MB或2GB）
      4. +
    4. 创建虚拟硬盘（在包含立即创建虚拟硬盘，VDI（虚拟磁盘映像）和动态分配的三个对话框中选择默认选项）。
      5. +
    5. 选择虚拟硬盘的文件位置和大小（选择一个合理的名称和位置来保留它，并且大小指定大约50GB，或者您可以轻松指定）。
      6. +
    +
    6. +
+ +

现在，新的虚拟框应出现在Virtual Box UI主窗口的左侧菜单中。此时，您可以双击它以打开虚拟机––它将开始启动虚拟机，但它还没有安装操作系统。此时，您需要将对话框指向安装程序映像/磁盘，它将运行在虚拟机上安装它的步骤，就像它是真正的计算机一样。

+ +

+ +
+

重要提示：您需要确保此时要在虚拟机上安装要安装的操作系统映像，然后立即安装。如果此时取消该进程，它可能会使虚拟机无法使用，并使其成为您需要删除它并再次创建它。这不是致命的，但令人讨厌。

+
+ +

完成此过程后，您应该有一台虚拟机在主机窗口内运行操作系统。

+ +

+ +

您需要像处理任何实际安装一样处理此虚拟操作系统安装 - 例如，安装要测试的浏览器，安装防病毒程序以保护其免受病毒侵害。

+ +

拥有多个虚拟机非常有用，特别是对于Windows IE / Edge测试 - 在Windows上，您无法并排安装多个版本的默认浏览器，因此您可能需要构建一个虚拟机库来处理根据需要进行不同测试，例如：

+ + + +
+

注意：虚拟机的另一个好处是虚拟磁盘映像是相当独立的。如果您正在团队中工作，则可以创建一个虚拟磁盘映像，然后复制并传递它。如果它是许可产品，只需确保您拥有运行所有Windows副本或正在运行的任何其他副本所需的许可证。

+
+ +

自动化和商业应用

+ +

正如上一章所述，通过使用某种自动化系统，您可以从浏览器测试中减少很多痛苦。您可以设置自己的测试自动化系统（Selenium是首选的流行应用程序），它确实需要一些设置，但是当您解决问题时可能会相当受益。

+ +

还有一些商业工具，如Sauce Labs和Browser Stack，可以为您做这种事情，如果您愿意在测试中投入一些资金，则无需担心设置的问题。

+ +

我们将在后续文章中查看如何使用此类工具。

+ +

用户测试

+ +

在我们继续之前，我们将通过谈论用户测试来完成本文––如果您有一个愿意用户组来测试您的新功能，这可能是一个很好的选择。请记住，这可以像你希望的那样廉价又有效––你的用户群可以是一群朋友，一群同事，或一群无偿或有偿志愿者，这取决于你是否有钱花在测试上。

+ +

通常，您可以让用户在某种开发服务器上查看包含新功能的页面或视图，这样您就不会在完成之前放置最终站点或更改。你应该让他们按照一些步骤报告他们得到的结果。提供一组步骤（有时称为脚本）非常有用，这样您就可以获得与您尝试测试的内容相关的更可靠的结果。我们在上面的{{anch("What are you going to test")}} 部分中提到了这一点––很容易将其中详述的测试标准转换为要遵循的步骤。例如，以下内容适用于有视力的用户：

+ + + +

运行测试时，最好还是：

+ + + +

这些步骤旨在确保您正在测试的浏览器尽可能“纯粹（pure）”，即没有安装任何可能影响测试结果的内容。

+ +
+

注意：如果您有可用的硬件，另一个有用的低功耗选项是在低端手机/其他设备上测试您的网站 - 随着网站变得更大并且具有更多效果，网站放慢速度的可能性更高，因此您需要开始给予表现更多考虑。尝试在低端设备上运行您的功能将使更高端设备的体验更有可能。

+
+ +
+

注意：某些服务器端开发环境提供了有用的机制，可以将站点更改部署到仅部分用户，从而提供了一种有用的机制，可以在不需要单独的开发服务器的情况下获取由用户子集测试的功能。示例：Django Waffle Flags。

+
+ +

总结

+ +

阅读本文后，您现在应该知道如何识别目标受众/目标浏览器列表，然后在该列表上有效地执行跨浏览器测试。

+ +

接下来，我们将把注意力转向测试可能发现的实际代码问题，从HTML和CSS开始。

+ +

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}

+ + + +

本章内容

+ +

+

diff --git "a/files/zh-cn/learn/tools_and_testing/cross_browser_testing/\345\217\257\350\256\277\351\227\256\346\200\247/index.html" "b/files/zh-cn/learn/tools_and_testing/cross_browser_testing/\345\217\257\350\256\277\351\227\256\346\200\247/index.html" deleted file mode 100644 index 704f595fb4..0000000000 --- "a/files/zh-cn/learn/tools_and_testing/cross_browser_testing/\345\217\257\350\256\277\351\227\256\346\200\247/index.html" +++ /dev/null @@ -1,624 +0,0 @@ ---- -title: 解决常见的可访问性问题 -slug: Learn/Tools_and_testing/Cross_browser_testing/可访问性 -tags: - - CSS - - CodingScripting - - HTML - - JavaScript - - 初学者 - - 可访问性 - - 学习 - - 工具 - - 文章 - - 测试 - - 跨浏览器 - - 键盘 -translation_of: Learn/Tools_and_testing/Cross_browser_testing/Accessibility ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}
- -

接下来，我们将关注可访问性，提供关于一些常见问题的信息，如何进行简单测试以及如何使用审核/自动化工具来查找可访问性问题。

- - - - - - - - - - - - -
前提:熟悉HTML, CSS,和JavaScript语言; 理解跨浏览器测试原理
目标:能够诊断常见的可访问性问题，并使用适当的工具和技术解决问题。
- -

什么是可访问性？

- -

当我们在web技术的背景下说可访问性时，大多数人立即想到确保残疾人可以使用网站/应用程序，例如：

- - - -

但是，说可访问性仅与残疾人有关是错误的。实际上，可访问性的目的是使你的网站/应用程序在尽可能多的环境中被尽可能多的人使用，而不仅仅是那些使用高性能台式计算机的用户。极端的例子可能包括：

- - - -

在某种程度上，本模块都是关于可访问性的 — 跨浏览器测试可确保你的网站可以被尽可能多的人使用。这篇可访问性是什么？ 更全面透彻地定义了什么是可访问性。

- -

也就是说，本文将涵盖跨浏览器和有关残疾人的测试问题以及他们如何使用Web。我们在其他地方已经讨论过其他领域，例如响应式设计问题和性能。

- -
-

Note: 就像Web开发中的许多事情一样，可访问性不是100%的成功或失败可以定义的；对于所有内容而言，几乎不可能实现100％的可访问性，尤其是当站点变得越来越复杂时。我们更多的是通过防御性编码并遵循最佳实践，努力使尽可能多的人可以访问尽可能多的内容。

-
- -

常见可访问性问题

- -

在本节中，我们将围绕Web可访问性，详细介绍与特定技术相关的一些主要问题、要遵循的最佳实践，以及可以进行的一些快速测试，以查看你的网站是否朝着正确的方向发展。

- -
-

Note: 可访问性在道德上是正确的事情，对企业也有好处(残疾用户，移动用户等构成了重要的细分市场), 并且在世界许多地方，提供出来的网络媒体资源无法为残疾人服务也是违法的。阅读无障碍指南和法律获取更多相关信息。

-
- -

HTML

- -

HTML语义化 (语义化正确地使用HTML标签)对于可访问性来说是开箱即用的 — 这类内容可供无视障人士阅读（前提是你不会做任何愚蠢的事情，例如使文本变小或使用CSS隐藏它），也可被屏幕阅读器（从字面上读出网页的应用）之类的辅助技术使用，并赋予其他优势。

- -

语义化结构

- -

HTML语义化最重要的捷径是为你的内容使用标题和段落的结构；这是因为屏幕阅读器用户倾向于将文档标题用作导航，以更快地找到他们需要的内容。如果你的内容没有标题，那么他们将获得的是一大坨文字，没有任何可定位的标记。坏的例子和好的例子如下：

- -
<font size="7">My heading</font>
-<br><br>
-This is the first section of my document.
-<br><br>
-I'll add another paragraph here too.
-<br><br>
-<font size="5">My subheading</font>
-<br><br>
-This is the first subsection of my document. I'd love people to be able to find this content!
-<br><br>
-<font size="5">My 2nd subheading</font>
-<br><br>
-This is the second subsection of my content. I think is more interesting than the last one.
- -
<h1>My heading</h1>
-
-<p>This is the first section of my document.</p>
-
-<p>I'll add another paragraph here too.</p>
-
-<h2>My subheading</h2>
-
-<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>
-
-<h2>My 2nd subheading</h2>
-
-<p>This is the second subsection of my content. I think is more interesting than the last one.</p>
- -

此外，你的内容应该在逻辑顺序上讲得通的 — 你总能在以后再为它们写CSS，但你应该在一开始就确定内容正确的顺序。

- -

作为测试，你可以关闭网站的CSS，然后看看没有了CSS网站是否能被理解。你可以通过从代码中删除CSS来手动完成此操作，但是最简单的方法是使用浏览器功能，例如：

- - - -

使用键盘

- -

某些HTML功能可以使用键盘来选择 — 这是默认的，从早期web开始就是这样的。具有此功能的元素是允许用户与网页交互的常见元素，比如links, {{htmlelement("button")}}s, 以及表单元素，比如{{htmlelement("input")}}.

- -

浏览native-keyboard-accessibility.html (查看源码) 尝试一下— 在新标签页中打开它，然后尝试按Tab键；按下几下后，你应该看到标签焦点开始在不同的可聚焦元素之间移动；在每个浏览器中，被聚焦的元素都被赋予突出的默认样式 (不同的浏览器表现略有不同) 以便你能分辨聚焦在哪个元素上。

- -

- -

然后，你可以按Enter / Return键来关注焦点链接，或者按一个按钮（我们已经包含一些JavaScript来使按钮提醒消息），或者在输入框开始输入文本，（其他表单元素具有不同的控件，例如{{htmlelement("select")}}元素可以使用向上和向下箭头键显示和循环显示其选项）。

- -

请注意，不同的浏览器可能具有不同的键盘控制选项。大多数现代浏览器都遵循上述的标签模式（你也可以执行Shift + Tab来向后移动可聚焦元素），但是某些浏览器具有自己的特性：

- - - -
-

重要: 你应该在所写的任何新页面上执行这种测试 — 确保可以通过键盘使用功能。

-
- -

这个例子强调了正确使用语义元素的重要性。可以用CSS将任何元素的样式设置为看起来像链接或按钮，并使用JavaScript让其表现为像链接或按钮一样，但实际上它们不是链接或按钮，你将失去很多语义化元素带给你的可访问性。因此，尽量避免这样做。

- -

另一个技巧 — 如我们的示例所示，你可以使用:focus伪类控制可聚焦元素在聚焦时的外观。最好将焦点和悬停样式加重显示，这样无论是使用鼠标还是键盘的用户，都能直观地察觉控件在被激活时将执行的操作

- -
a:hover, input:hover, button:hover, select:hover,
-a:focus, input:focus, button:focus, select:focus {
-  font-weight: bold;
-}
- -
-

Note: 如果你决定使用CSS删除默认的焦点样式，请确保将其替换为更适合你的设计的其他样式 — 这是一种非常有价值的可访问性工具，不应删除。

-
- -

模拟键盘

- -

有时可能无法使用键盘完成可访问性。你可能有一个语义不是很好的网站（也许你最终得到了一个糟糕的CMS网页，该CMS生成了由<div> 组成的按钮），或者你正在使用一个没有内置键盘可访问性的复杂控件，例如HTML5 {{htmlelement("video")}} 元素（令人惊奇的是，Opera是唯一允许你在<video>元素的默认浏览器控件之间进行制表的浏览器）。你有几种选择：

- -
    -
  1. 使用<button>元素（默认情况下都是可以在button间使用Tab键）和JavaScript创建自定义控件，以连接其功能。有关此示例，请参见Creating a cross-browser video player。
    2. -
  2. 通过JavaScript创建键盘快捷键，因此当你按键盘上的某些键时，功能被激活。请参阅Desktop mouse and keyboard controls，以获取一些可用于任何目的（比如游戏）的例子。
    3. -
  3. 使用一些有趣的策略来伪造按钮行为。以我们的fake-div-buttons.html示例为例（查看源码）。这里我们通过为每个假按钮赋予属性tabindex="0"（请参阅​​WebAIM的tabindex文章以获取更多详细信息），使假的<div>按钮能够被聚焦（包括通过制表符）。这使我们可以跳到按钮上，但不能通过回车键激活它们。为此，我们必须添加以下JavaScript代码： - 
    document.onkeydown = function(e) {
-  if(e.keyCode === 13) { // The Enter/Return key
-    document.activeElement.onclick(e);
-  }
-};
    - 在这里，我们向document对象添加了一个监听器，以检测何时按下了键盘上的按钮。我们通过事件对象的keyCode属性检查按下了什么按钮；如果它是与回车键匹配的键码，则使用document.activeElement.onclick()运行存储在按钮的onclick处理程序中的函数。document.activeElement为我们提供了当前页面上被聚焦的元素。
    4. -
- -
-

Note: 仅当你通过事件处理程序属性（例如onclick）设置原始事件处理程序时，此技术才有效。addEventListener将无法正常工作。重新构建功能会有很多额外的麻烦。并且肯定还有其他问题。最好能从根源解决问题，使用正确的语义化元素。

-
- -

替代文本

- -

替代文本对于可访问性非常重要 — 如果一个人有视觉或听觉障碍使他们无法看到或听到某些内容，那么这就是一个问题。可用的最简单的文本替代方法是alt属性，我们应该在所有包含相关内容的图像上包括该属性。其中应包含对图像的描述，该描述可在页面上成功传达其含义和内容，并由屏幕阅读器读取并读出给用户。

- -
-

Note: 更多信息请阅读Text alternatives

-
- -

可以通过多种方法来测试缺少的替代文本，例如，使用可访问性{{anch("审计工具")}}。

- -

对于视频和音频内容，Alt文本稍微复杂一些。有一种方法可以定义文本轨道（例如，字幕）并在播放视频时以{{htmlelement("track")}}元素和WebVTT格式的形式显示它们（请参见Adding captions and subtitles to HTML5 video以获取详细信息）。这些功能的浏览器兼容性相当好，但是如果你想提供音频的替代文本或支持较旧的浏览器，则在页面某处或单独页面上显示一个简单的文本记录可能是个好主意。

- -

元素关系和上下文

- -

HTML中有某些功能和最佳实践，旨在提供元素之间的上下文和关系。三个最常见的示例是链接，表单标签和数据表。

- -

使用屏幕阅读器的人们通常会使用一项共同的功能，即他们会拉出页面上所有链接的列表。在这种情况下，链接文本需要脱离上下文。例如，标记为“单击此处”，“单击此处”等的链接列表确实对可访问性不利。链接文本最好在上下文和上下文之外都有意义。

- -

表单{{htmlelement("label")}}元素是允许我们使表单可访问的主要功能之一。表单的麻烦在于，你需要标签来说明应在每个表单输入中输入哪些数据。每个标签都必须包含在{{htmlelement("label")}}内，以将其明确链接到其对应的表单输入框（属性值的每个<label>的for属性值必须与表单元素id值匹配），即使源顺序不是完全合乎逻辑的，也能提供很好的可访问性。

- -
-

Note: 更多关于链接文本和表单标签，请阅读有意义的文字标签

-
- -

最后，简要介绍一下数据表。基本数据表可以用非常简单的标记编写（请参阅bad-table.html和源码)），但这存在问题 — 屏幕阅读器用户无法将行或列作为数据分组关联在一起，但你需要知道标题行是什么，以及标题行行的标题还是列的标题等。这些只能从可视化的表格才能知道。

- -

相反，如果你看一下我们的punk-bands-complete.html示例（示例，源码），则可以在此处看到一些可访问性辅助，例如表头（{{htmlelement("th")}}和作用域属性），{{htmlelement("caption")}}元素等。

- -
-

Note: 更多信息，请阅读可访问的表格

-
- -

CSS

- -

CSS往往提供的基本可访问性功能要比HTML少得多，但是如果使用不当，它仍然会对可访问性造成同样的损害。下面是一些涉及CSS的可访问性的点：

- - - -

还有其他几个需要注意的地方。

- -

颜色和颜色对比度

- -

为你的网站选择配色方案时，应确保文本（前景）颜色与背景颜色形成鲜明对比。你的设计可能看起来很酷，但是如果视力障碍者（例如色盲）无法阅读你的内容，那就不好了。使用WebAIM的Color Contrast Checker之类的工具来检查你的方案是否有足够对比度。

- -

另一个提示是不要仅依靠颜色来表示界标/信息，因为这对于看不见颜色的人来说是不好的。例如，不要将所需的表单字段标记为红色，而应使用星号和红色标记它们。

- -
-

Note: 高对比度也可以让使用带有光滑屏幕的设备（例如智能手机或平板电脑）的人在明亮的环境（例如阳光）下可以更好地阅读页面。

-
- -

隐藏的内容

- -

在许多情况下，视觉设计要求并非一次显示所有内容。例如，在我们的Tabbed info box example“示例（查看源码）中，我们有三个信息面板，但是我们将它们放在彼此的顶部，用户可以通过单击以显示每个选项卡（也可以通过键盘访问 — 可以使用Tab键和回车键选择它们）。

- -

- -

屏幕阅读器用户根本不关心这些，只要源内容顺序有意义，他们就很满意，并且他们可以全部获取。绝对定位（在本示例中使用的定位）通常被视为隐藏内容以产生视觉效果的最佳机制之一，因为它不会阻止屏幕阅读器获取相关内容。

- -

另一方面，你不应该使用{{cssxref("visibility")}}:hidden或者{{cssxref("display")}}:none, 因为它们会让屏幕阅读器取不到那些内容，除非你真的想让屏幕阅读器不读取那些内容。

- -
-

Note: Invisible Content Just for Screen Reader Users有更多关于这个话题的详细信息

-
- -

JavaScript

- -

就可访问性而言，JavaScript具有与CSS相同的问题 — 如果使用不当或使用过度，可访问性可能会很糟糕。我们已经提到了与JavaScript相关的一些可访问性问题，主要是在HTML语义化那块 — 你应该始终使用适当的语义化HTML来在合适的地方实现功能，例如，适当地使用链接和按钮。尽量不要使用JavaScript代码中结合<div>元素来伪造功能 — 容易出错，并且比直接使用HTML标签还要做更多的工作。

- -

简单的功能

- -

通常，简单的功能只应使用HTML标签完成 — JavaScript仅用于增强功能，而不能用于实现简单功能。好的JavaScript用法包括：

- - - -
-

Note: WebAIM的Accessible JavaScript提供了一些关于JavaScript可访问性注意事项的信息。

-
- -

更复杂的JavaScript实现可能会带来可访问性问题 — 你需要尽力而为。例如，期望让使用WebGL编写的复杂3D游戏对盲人来说100％可访问性是不合理的，但是你可以实现键盘控件，以便非鼠标用户可以使用它，并使配色方案具有足够的对比度供有颜色分辨障碍的人使用。

- -

复杂的功能

- -

可访问性存在问题的主要领域之一是复杂的应用程序，其中涉及复杂的表单控件（例如日期选择器）和动态内容，内容会经常增量更新。

- -

非自带的复杂的表单控件可能会存在问题，因为它们往往涉及大量嵌套的<div>，浏览器默认情况下不知道如何处理它们。如果你自己开发控件，则需要确保它们可以通过键盘访问。如果你使用的是某种第三方框架，请在开始使用之前仔细检查可用的选项以了解它们是否具有完备的可访问性。例如，Bootstrap就对可访问性有相当好的支持（尽管Rhiana Heath的Making Bootstrap a Little More Accessible探讨了它的一些问题（主要与色彩对比度有关），并着眼于一些解决方案）。

- -

定期更新的动态内容可能会成为问题，因为屏幕阅读器用户可能会错过这些内容，尤其是在意外更新的情况下。如果你有一个包含主要内容面板的单页应用程序，该应用程序使用XMLHttpRequest或Fetch定期更新，那么屏幕阅读器用户可能会错过这些更新。

- -

WAI-ARIA

- -

你是否需要使用这种复杂的功能，或者使用普通的旧语义化HTML代替？如果确实需要复杂性，则应考虑使用WAI-ARIA（Accessible Rich Internet Applications - 可访问的互联网应用），该规范为诸如复杂的表单控件和更新面板之类的项目提供了语义（以新的HTML属性形式），这样大部分浏览器和屏幕阅读器就能理解内容。

- -

要处理复杂的表单窗口小部件，你需要使用ARIA属性（例如roles）来声明窗口小部件中不同元素的角色（例如，它们是选项卡还是选项卡面板？），用aria-disabled来表示控件是否禁用等。

- -

要处理内容定期更新的区域，可以使用aria-live属性，该属性标识更新区域。它的值指示屏幕阅读器如何处理更新内容：

- - - -

例子如下：

- -
<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>
- -

浏览Freedom Scientific的ARIA (Accessible Rich Internet Applications)动态更新区域示例 — 高亮显示的段落每10秒更新一次内容，屏幕阅读器应将此内容读出给用户。ARIA Live Regions - Atomic是另一个很有用的例子。

- -

我们这里没有足够的空间来详细介绍WAI-ARIA，你可以在WAI-ARIA basics了解更多。

- -

可访问性测试工具

- -

现在，我们已经介绍了不同Web技术的可访问性注意事项，包括一些测试方法（例如键盘导航和颜色对比度检查器），让我们看一下在进行可访问性测试时可以使用的其他工具。

- -

审计工具

- -

你可以使用许多审计工具检查你的网页，这些审计工具将检查它们并返回页面上存在的可访问性问题列表。一些审计工具：

- - - -

看下面的例子，我们用的是Tenon。

- -
    -
  1. 访问Tenon主页。
    2. -
  2. 使用bad-semantics.html示例测试，输入链接地址并按下Analyse Your Webpage（译者注：开始分析你的网页）。
    3. -
  3. 下滑，直到你看到错误/描述部分，如下图。
    4. -
- -

- -

你还可以探索一些选项（请参阅页面顶部附近的Show Options（译者注：显示选项）链接），或者使用Tenon的API。

- -
-

Note: 这些工具不足以单独解决你的所有可访问性问题。你需要将这些，知识和经验，用户测试等结合起来才能获得完整的解决方案。

-
- -

自动化工具

- -

Deque's aXe tool比我们上面提到的审计工具更优秀。和其他工具一样，它检查页面并返回可访问性错误。它很有用，可以提供浏览器扩展程序：

- - - -

扩展程序将可访问性选项卡添加到浏览器开发人员工具。例如，我们安装了Firefox版本，然后使用它来审核bad-table.html示例。我们得到以下结果：

- -

- -

aXe也可以使用npm安装，并且可以与任务运行器（如Grunt 和Gulp），自动化框架（如Selenium和Cucumber），单元测试框架（如Jasmin）集成，以及更多其他功能（详见main aXe page ）。

- -

屏幕阅读器

- -

为了了解有严重视力障碍的人是如何浏览网页的，我们需要测试屏幕阅读器。有几款屏幕阅读器：

- - - -

通常，屏幕阅读器是独立运行的应用程序，并且不仅仅支持阅读网页，也支持阅读其他应用程序。也有例外（比如ChromeVox是一个浏览器扩展程序）。不同的屏幕阅读器可能在控制键和表现上稍有不同，所以你必须查阅你选择的屏幕阅读器的文档来获取相关细节。总体来说他们是大同小异的。

- -

一起看一下我们对几款不同的屏幕阅读器的测试。这将帮助你大致了解它们如何工作以及如何测试它们。

- -
-

Note: WebAIM的 Designing for Screen Reader Compatibility提供了一些关于屏幕阅读器的使用和如何开发应用以最好的适用屏幕阅读器的信息。你也可以看下Screen Reader User Survey #6 Results这篇有关屏幕阅读器一些有趣的统计信息的文章。

-
- -

VoiceOver

- -

VoiceOver (VO)是Mac/iPhone/iPad上的免费应用，所以如果你使用苹果公司的产品，可以用VO来进行测试。 我们在Mac OS X 系统上测试了它。

- -

按下Cmd + Fn + F5打开它。如果你之前没用过VO，将会出现一个可以选择是否开启VO的欢迎界面，并且还会有教程指导你如何使用。再次按下Cmd + Fn + F5可以关闭。

- -
-

Note: 你应该至少看一遍教程，它对于你了解VO是非常有用的。

-
- -

当VO开启时，你会看到一个会显示当前选中信息的黑色框在屏幕的左下角，除此之外屏幕显示大体还是相同的。当前选中的部分也会出现一个黑色的边框以进行高亮显示，这个黑色框就是VO的光标。

- -

- -

在使用中，你会用到"VO修饰键"，"VO修饰键"是一个单独键或组合键，当你使用VO的快捷键时，你需要额外按下这个"VO修饰键"。屏幕阅读器通常都会有修饰键，防止它们的快捷键和其他程序的快捷键冲突。VO的修饰键是CapsLock, 或Ctrl + Option。

- -

VO有很多快捷键，我们没有全部列出来。只把测试网页可访问性常用的一些在下面列出了。表格里，"VO"代表"VO修饰键"。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
常用的VO快捷键
快捷键描述
VO + 方向键移动VO光标
VO + 空格键选择/激活高亮的部分，包括Rotor里的内容（关于Rotor见下面）
VO + Shift + 下移动到组合项目里（比如HTML表格，或表单等）。进入组合里，你能使用下面的快捷键。
VO + Shift + 上离开组合项目
VO + C(当在表格里面时) 阅读当前列的头部
VO + R(当在表格里面时) 阅读当前行的头部
VO + C + C (当在表格里面时) 阅读当前列，包括列头
VO + R + R (当在表格里面时) 阅读当前行，包括对应于每个小行的头
VO + 左, VO + 右(当在水平的选项卡里面时，比如日期选择或时间选择) 切换选项
VO + 上, VO + 下(当在垂直的选项卡里面时，比如日期选择或时间选择) 切换选项
VO + U使用Rotor。Rotor使用列表展示标题，链接，表单选项等，以便为我们提供便利的导航。
VO + 左, VO + 右(当在Rotor里) 切换到其他列表
VO + 上, VO + 下(当在Rotor里) 在当前列表里，切换到其他项
Esc(当在Rotor里) 推出Rotor
Ctrl(当VO阅读时) 暂停/继续
VO + Z重复上一句话
VO + D进入Mac的程序坞，你能选择运行哪个应用
- -

看起来很多，但当你用起来时还好，因为VO通常会给你提醒，在哪里应该用哪个快捷键。现在试试运行VO，在{{anch("屏幕阅读器测试")}}屏幕阅读器测试章节做个测试吧。

- -

NVDA

- -

NVDA只能运行在Window系统，你需要安装它。

- -
    -
  1. 在nvaccess.org下载。你能选择免费下载，或赞助后再下载；你需要在下载前提供你的邮箱地址。
    2. -
  2. 下载完成后，开始安装 - 双击安装程序，接受条款，一步步按提示来。
    3. -
  3. 双击NVDA程序或快捷方式，或者按下Ctrl + Alt + N打开它。你会看见欢迎界面。你能选择一些选项，然后按下OK继续。
    4. -
- -

NVDA现在在你的电脑上开启了。

- -

在使用中，你会用到"NVDA修饰键"，"NVDA修饰键"是一个单独键，当你使用NVDA的快捷键时，你需要额外按下这个"NVDA修饰键"。屏幕阅读器通常都会有修饰键，防止它们的快捷键和其他程序的快捷键冲突。NVDA的修饰键是Insert键（默认）, 或CapsLock键（在欢迎界面可以选择使用该键）。

- -
-

Note: 关于高亮方面，NVDA比VoiceOver做的更好。当滚动过标题、列表等元素时，你选中的项目会被一个细微的边框包住以高亮，但不是对于所有元素都是这样的。如果你感觉迷失方向了，可以按Ctrl + F5刷新页面，并从顶部重新开始。

-
- -

NVDA有很多快捷键，我们没有全部列出来。只把测试网页可访问性常用的一些在下面列出了。表格里，"NVDA"代表"NVDA修饰键"。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
常用的NVDA快捷键
快捷键描述
NVDA + Q关闭NVDA
NVDA + 上阅读当前行
NVDA + 下在当前位置开始阅读
上和下, 或者Shift + Tab 和Tab移动到上/下一项，开始阅读
左和右移动到当前项的上/下一个字符，开始阅读
Shift + H 和 H移动到上/下一标题，开始阅读
Shift + K 和 K移动到上/下一链接项，开始阅读
Shift + D 和 D移动到上/下一文档界标（比如<nav>），开始阅读
Shift + 1–6 和 1–6移动到上/下一标题（标题1 - 6），开始阅读
Shift + F 和 F移动到上/下一表单选项，聚焦
Shift + T 和 T移动到上/下一数据表，聚焦
Shift + B 和 B移动到上/下一按钮，阅读它的label
Shift + L 和 L移动到上/下一列表，阅读它的第一项
Shift + I 和 I移动到上/下一列表，开始阅读
Enter/Return(当链接或按钮或其他可激活的项选中时) 激活项
NVDA + 空格(当选中表单时) 进入表单，或如果已经在表单里的情况下，离开表单
Shift Tab 和 Tab(当在表单里面时) 切换到下一个input
上 和 下(当在表单里面时) 改变input的值(例如选择框).
空格(当在表单里面时) 选择已选中的值
Ctrl + Alt + 方向键(当选中表格时) 切换表格单元格
- -

屏幕阅读器测试

- -

现在你学会了如何使用屏幕阅读器，来使用它做一些可访问性测试吧。这样你才能了解屏幕阅读器在好的网页和坏的网页之间不同的表现：

- - - -

用户测试

- -

如上所述，你不能仅依靠自动化工具来确定网站上的可访问性问题。建议在制定测试计划时，包含一些用户测试可访问性的计划(有关更多内容，请参阅前面的用户测试部分)。尝试让一些屏幕阅读器用户，一些全键盘用户，一些有听觉障碍的用户或其他用户参与测试，以满足你的需求。

- -

测试可访问性检查清单

- -

以下列表提供了一个清单，供参考，以确保已对项目执行建议的可访问性测试：

- -
    -
  1. 确保HTML尽可能是语义化的。验证是一个好方法, 就像使用审计工具。
    2. -
  2. 检查当关闭CSS时，你的内容能够被理解。
    3. -
  3. 确认功能是全键盘可访问的。使用Tab键、回车键等做测试。
    4. -
  4. 确保非文本内容有替代文本。 审计工具能够很好地发现问题。
    5. -
  5. 确保颜色和颜色对比度是可接受的，使用合适的工具测试。
    6. -
  6. 确保隐藏的内容可以被屏幕阅读器读取。
    7. -
  7. 尽可能的使功能在没有JavaScript的情况下也可以正常使用。
    8. -
  8. 在合适的地方使用ARIA来提供可访问性。
    9. -
  9. 使用审计工具测试一下你的网站。
    10. -
  10. 使用屏幕阅读器实际测试一下。
    11. -
  11. 在你的网站上可以添加可访问性策略/声明，以说明你的为可访问性做了什么。
    12. -
- -

寻找帮助

- -

可访问性还会遇到许多其他问题。你要学会如何在线查找答案。请查阅HTML和CSS文章的“寻找帮助”部分，以获取一些指导。 

- -

总结

- -

希望本文能让你了解可访问性，以及帮助你解决遇到的一些可访问性问题。

- -

下一篇文章，我们将详细介绍特征检测。

- -

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}

- -

指南

- - diff --git "a/files/zh-cn/learn/tools_and_testing/cross_browser_testing/\346\265\213\350\257\225\347\255\226\347\225\245/index.html" "b/files/zh-cn/learn/tools_and_testing/cross_browser_testing/\346\265\213\350\257\225\347\255\226\347\225\245/index.html" deleted file mode 100644 index fb01cd2843..0000000000 --- "a/files/zh-cn/learn/tools_and_testing/cross_browser_testing/\346\265\213\350\257\225\347\255\226\347\225\245/index.html" +++ /dev/null @@ -1,367 +0,0 @@ ---- -title: 进行测试的策略 -slug: Learn/Tools_and_testing/Cross_browser_testing/测试策略 -tags: - - 测试 - - 测试策略 - - 用户测试 - - 自动化测试 - - 虚拟机 仿真器 - - 跨浏览器测试 -translation_of: Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}
- -


- 这篇文章主要是讨论如何进行跨浏览器测试，回答一些比较常见的疑惑，譬如：“什么是跨浏览器测试？”，“会遇到哪些常见的问题？”以及“如何测试、区分以及修复问题？”

- - - - - - - - - - - - -
准备:熟练掌握 HTML, CSS, 和 JavaScript 语言; 了解跨浏览器测试的核心概念。
对象:了解跨浏览器测试所涉及的高级概念。
- -

是否需要测试？

- -

开始跨浏览器测试（cross browser testing）之前您需要确定哪些浏览器将进入被测试名单。测试所有用户可能使用的浏览器或移动设备是不可能的——数量太大，而且浏览器和设备总在不断更新。

- -

可行的替代方案是，尝试确保您的网站适用于最常见的浏览器和设备，然后进行防御性编码，以便为您的网站提供最广泛的支持范围。

- -

防御性编码的实质是一种智能回退措施：如果某个功能或样式在浏览器中不起作用，该网站将将降级为不太令人兴奋的东西，但仍然能提供可接受的用户体验——核心是：虽然网站看起来不那么漂亮，仍然可以访问。

- -

本章的目的是建立一个供您在测试时参考的浏览器/设备图表。 您可以根据需要将其设置成简单或复杂版本——常见的方法是具有多个等级的支持，例如：

- -
    -
  1. A 级：普通/现代浏览器（仍在广泛使用）：需要彻底测试并提供全面支持。
    2. -
  2. B 级：较旧/较少的浏览器 （少数用户还在使用）：测试并提供更基本的体验，以提供对核心信息和服务的完全访问。
    3. -
  3. C 级：稀有/未知浏览器 ： 不进行测试，假设网站内容可以显示。 在我们的防御性编码起效的情况下，用户可以访问到网页的全部内容。
    4. -
- -

在以下各节中，我们将以此等级为参考构建支持图表。

- -
-

注意：雅虎最先使这一方法流行起来，详情参见《浏览器分级支持系统》（ Graded browser Support）。

-
- -

有根据地假设

- -

您可以称之为“假设”或“直觉”。这不是一种准确，科学的方法，但作为具有网络行业经验的人，您至少应该对待测试的一些浏览器有些想法。这将形成一个良好的初级浏览器分级支持系统。

- -

例如，如果您居住在西欧或北美，您会发现许多人使用 Windows 和 Mac 的台式机或笔记本电脑，主要浏览器是 Chrome，Firefox，Safari，IE 和 Edge。您可以测试前三个浏览器最近的三个版本，因为它们会定期更新。对于Edge和IE，您应当近期的多个版本。这些浏览器都应该属于A级。

- -
-

注意：您一次只能在计算机上安装一个版本的 IE 或 Edge，因此您可能必须使用虚拟机或其他方法来执行所需的测试。稍后请参阅虚拟机部分{{anch("Virtual machines")}}。

-
- -

很多人使用 iOS 和 Android，因此您可能还想测试最新版本的 iOS Safari，最近几个版本的 Android stock 浏览器，以及适用于 iOS 和 Android 的 Chrome 和 Firefox。理想情况下，您应该在手机和平​​板电脑上测试这些，以确保响应式设计的正常运行。

- -

您也许知道很多人仍然在使用 IE 9。这一版本陈旧而且功能较少，所以让我们把它放在B级别。

- -

到目前为止，这为我们提供了以下支持级别：

- -
    -
  1. A 级：用于 Windows / Mac 的 Chrome 和 Firefox，用于 Mac 的 Safari，用于 Windows的 Edge 和 IE（每个版本的最后两个版本），用于 iPhone / iPad 的 iOS Safari，用于手机/平板电脑的 Android stock 浏览器（最后两个版本），用于手机和平板电脑上的 Chrome 和适用于 Android 的Firefox（最后两个版本）。
    2. -
  2. B 级：适用于 Windows 的 IE 9
    3. -
  3. C 级：无
    4. -
- -

如果您居住在其他地方，或者正在开发其他地方（例如某些国家或地区）的网站，那么您可能会有不同的常用浏览器进行测试。

- -
-

注意：“我老板用Blackberry，所以我们最好确保它看起来很好”也可以是一个有说服力的论点。

-
- -

浏览器支持检测

- -

您可以调用的一个有用的措施是浏览器支持统计信息,用于告知您的浏览器测试选项。有许多网站提供此类统计信息,例如:

- - - -

这些都以北美为中心,并不特别准确,但它们可以让您了解大趋势。

- -

例如,让我们转到 Netmarketshare。您可以看到 Opera 被列为具有小但可见的使用数字,因此,我们也应该将其添加到支持图表中,作为 C 级。

- -

IE8 被列为重要,但它较老且不再能够。Opera Mini 非常重要,但在运行时运行复杂的 JavaScript 方面,它的能力并不大(有关详细信息,请参阅 Opera Mini and JavaScrip)。我们也应该把它放到B级。

- -

使用分析工具

- -

更准确的数据源,如果你能得到它,来自像Google Analytics这样的分析应用程序。这是一个应用程序,将为您提供准确的统计数据,究竟是什么浏览器的人正在使用浏览您的网站。当然,这依赖于您已经有一个网站使用它,所以它是没有多大的适合全新的网站。

- -

但是,分析历史记录可用于查找支持统计信息以影响公司网站的新版本或要添加到现有站点的新功能。如果您有这些可用,它们比上述全球浏览器统计信息更准确。

- -

配置Google分析

- -
    -
  1. 首先,您需要一个谷歌帐户。使用此帐户可登录Google Analytics。 
    2. -
  2. 选择 Google Analytics (web))选项,然后单击"注册"按钮。
    3. -
  3. 在注册页面中输入您的网站/应用详细信息。这是相当直观的设置;获得正确的最重要的字段是网站 URL。这需要是您的网站/应用的根 URL。
    4. -
  4. 填写完所有内容后,按"获取跟踪 ID"按钮,然后接受显示的服务条款。
    5. -
  5. 下一页为您提供一些代码段和其他说明。对于基本网站,您需要做的是复制网站跟踪代码块,并将其粘贴到您要在网站上使用 Google Analytics 跟踪的所有不同页面。您可以在关闭</body>标记下方,也可以位于其他适当位置,以防止其与应用程序代码混淆。
    6. -
  6. 将更改上载到开发服务器,或将代码上载到其他任何位置。
    7. -
- -

就是这样！您的网站现在应该准备好开始报告分析数据。

- -

学习分析数据

- -

现在,您应该能够返回 Analytics Web主页,并开始查看您收集的有关网站的数据(当然,您需要留出一点时间才能真正收集一些数据)。

- -

默认情况下,您应该看到报告选项卡,如下所示:

- -

- -

有大量的数据,你可以看看使用谷歌分析––自定义报告在不同的类别,等等––我们没有时间讨论这一切。 Getting started with Analytics 为初学者提供了一些有关报告(以及更多)的有用指导。

- -

还应鼓励您查看左侧的不同选项,并查看您可以找到哪些类型的数据。例如,您可以通过从左侧菜单中选择" Audience > Technology > Browser & OS"来了解用户正在使用的浏览器和操作系统。

- -
-

注意:使用 Google 分析时,您需要提防误导性偏见,例如"我们没有 Firefox 移动用户"可能会导致您不必为 Firefox 移动提供支持。但是,你不会有任何火狐移动用户,如果该网站被打破在火狐手机摆在首位。

-
- -

其他注意事项

- -

您可能还应包括其他注意事项。您绝对应该将辅助功能作为 A 级测试要求(我们将在处理常见辅助功能问题一文中介绍您应该测试的内容)

- -

此外,您可能还有其他注意事项。如果要创建某种公司 Intranet,以便向经理提供销售数据,并且例如,所有经理都提供了 Windows 手机,则可能需要将移动 IE 支持作为优先事项。

- -

最终的支持图表

- -

因此,我们的最终支持图表最终将如下所示:

- -
    -
  1. A 级:适用于 Windows/Mac 的 Chrome 和 Firefox、适用于 Mac 的 Safari、Windows 的"边缘"和"IE"(每个版本的最后两个版本)、iPhone/iPad 的 iOS Safari、手机/平板电脑上的 Android 股票浏览器(最后两个版本)、适用于 Android 的 Chrome 和 Firefox(最后两个版本)在手机平板电脑上.通过常见测试的可访问性。
    2. -
  2. B 级:IE 8 和 9 用于 Windows,Opera Mini。
    3. -
  3. C级:Opera,其他合适的现代浏览器。
    4. -
- -

你想要测试什么？

- -

当您的代码库有需要测试的新添加项时,在开始测试之前,应编写出需要通过才能接受的测试要求列表。这些要求可以是可视的,也可以是功能性的, 两者结合起来, 成为可用的网站功能。

- -

思考下面的例子 (查看源码 , 在线预览):

- -

- -

此功能的测试标准可以这样编写:

- -

A 级和 B 级:

- - - -

A 级:

- - - -

You may notice from the text in the example that it won't work in IE8 — this is a problem according to our support chart, which you'll have to work on, perhaps by using a feature detection library to implement the functionality in a different way if the browser doesn't support CSS transitions (see Implementing feature detection, later on in the course).您可能会从示例中的文本中注意到它在 IE8 中不起作用 ––根据我们的支持图表,这是一个问题,您必须处理这个问题,如果浏览器不采用其他方式,则可能使用功能检测库以不同的方式实现功能（如果浏览器不支持 CSS 转换的话）(请参阅实现功能检测,稍后将在本课程中)。

- -

您可能还注意到,该按钮仅使用键盘无法使用, 这也需要纠正。也许我们可以使用一些JavaScript来实现一个键盘控件的切换,或者完全使用一些其他的方法?

- -

这些测试条件很有用,因为:

- - - -

建立一个测试实验室

- -

执行浏览器测试的一个选项是自己进行测试。为此,您可能需要使用实际物理设备和模拟环境的组合(使用仿真器或虚拟机)。

- -

真实设备

- -

通常最好让一个实际的设备运行您要测试的浏览器 , 这在行为和整体用户体验方面提供了最高的准确性。对于合理的低级设备实验室,您可能需要以下内容:

- - - -

如果可以获取这些选项,则以下是不错的选项:

- - - -

您的主工作计算机也可以用于安装其他工具以用于特定目的,例如辅助功能审核工具、屏幕阅读器和仿真器/虚拟机。

- -

一些大型公司拥有设备实验室,这些实验室库存了大量不同的设备,使开发人员能够在非常具体的浏览器/设备组合上查找 Bug。较小的公司和个人通常负担不起如此复杂的实验室,因此倾向于使用较小的实验室、仿真器、虚拟机和商业测试应用程序。

- -

我们将介绍下面的其他选项。

- -
-

注意:已做出一些努力用来创建可公开访问的设备实验室, 请参阅 Open Device Labs。

-
- -
-

注意:我们还需要考虑辅助功能 — 可以在计算机上安装许多有用的工具,以方便辅助功能测试,但我们将在本课程的后面部分介绍"处理常见辅助功能问题"一文中的工具。

-
- -

模拟器

- -

仿真器基本上是在计算机内运行并模拟某种设备或特定设备条件的程序,允许您比查找要测试的特定硬件/软件组合更方便地执行某些测试。

- -

仿真器可能与测试设备条件一样简单。例如,如果要对宽度/高度媒体查询进行一些快速而粗劣的测试以进行响应式设计,则可以使用 Firefox 的Responsive Design Mode。 Safari 也有类似的模式,可以通过访问 “Safari > 首选项”和"显示开发"菜单,然后选择"开发"&gt;"输入响应式设计模式"来启用。  Chrome 也有类似的功能:设备模式(请参阅Simulate Mobile Devices with Device Mode)。

- -

不过,您经常必须安装某种仿真器。要测试的最常见设备/浏览器如下所示:

- - - -

您也经常可以为其他移动设备环境找到模拟器，例如：

- - - -
-

注意：许多模拟器实际上需要使用虚拟机（见下文）;在这种情况下，通常提供指令，和/或将虚拟机的使用合并到仿真器的安装程序中。

-
- -

虚拟机

- -

虚拟机是在台式计算机上运行的应用程序，允许您运行整个操作系统的仿真，每个操作系统都划分在自己的虚拟硬盘驱动器中（通常由主机硬盘上存在的单个大文件表示）。有许多流行的虚拟机应用程序可用，例如Parallels，VMWare和Virtual Box;我们个人喜欢后者，因为它是免费的。

- -
-

注意：您需要可用的大容量硬盘空间来运行虚拟机模拟;模拟的每个操作系统都会占用大量内存。您可能倾向于为每次安装选择所需的硬盘空间;你也可能会试图侥幸使用10GB空间，但会被建议使用50GB空间或更多，以便让操作系统运行可靠。大多数虚拟机应用程序提供的一个很好的选择是创建一个动态分配（dynamically allocated）的硬盘驱动器，它会随着需要的增长和缩小而动态改变。

-
- -

要使用虚拟盒，您需要：

- -
    -
  1. 获取要模拟的操作系统的安装程序磁盘或映像（例如ISO文件）。 Virtual Box无法提供这些;大多数，如Windows操作系统，是无法自由分发的商业产品。
    2. -
  2. 下载适用于您的操作系统的相应安装程序并进行安装。
    3. -
  3. 打开应用程序;您将看到如下视图：
    4. -
  4. 要创建新虚拟机，请按左上角的“新建”按钮。
    5. -
  5. 按照说明进行操作，并根据需要填写以下对话框。你会： -
      -
    1. 为新虚拟机提供名称
      2. -
    2. 选择要在其上安装的操作系统和版本
      3. -
    3. 设置应分配多少RAM（我们建议使用2048MB或2GB）
      4. -
    4. 创建虚拟硬盘（在包含立即创建虚拟硬盘，VDI（虚拟磁盘映像）和动态分配的三个对话框中选择默认选项）。
      5. -
    5. 选择虚拟硬盘的文件位置和大小（选择一个合理的名称和位置来保留它，并且大小指定大约50GB，或者您可以轻松指定）。
      6. -
    -
    6. -
- -

现在，新的虚拟框应出现在Virtual Box UI主窗口的左侧菜单中。此时，您可以双击它以打开虚拟机––它将开始启动虚拟机，但它还没有安装操作系统。此时，您需要将对话框指向安装程序映像/磁盘，它将运行在虚拟机上安装它的步骤，就像它是真正的计算机一样。

- -

- -
-

重要提示：您需要确保此时要在虚拟机上安装要安装的操作系统映像，然后立即安装。如果此时取消该进程，它可能会使虚拟机无法使用，并使其成为您需要删除它并再次创建它。这不是致命的，但令人讨厌。

-
- -

完成此过程后，您应该有一台虚拟机在主机窗口内运行操作系统。

- -

- -

您需要像处理任何实际安装一样处理此虚拟操作系统安装 - 例如，安装要测试的浏览器，安装防病毒程序以保护其免受病毒侵害。

- -

拥有多个虚拟机非常有用，特别是对于Windows IE / Edge测试 - 在Windows上，您无法并排安装多个版本的默认浏览器，因此您可能需要构建一个虚拟机库来处理根据需要进行不同测试，例如：

- - - -
-

注意：虚拟机的另一个好处是虚拟磁盘映像是相当独立的。如果您正在团队中工作，则可以创建一个虚拟磁盘映像，然后复制并传递它。如果它是许可产品，只需确保您拥有运行所有Windows副本或正在运行的任何其他副本所需的许可证。

-
- -

自动化和商业应用

- -

正如上一章所述，通过使用某种自动化系统，您可以从浏览器测试中减少很多痛苦。您可以设置自己的测试自动化系统（Selenium是首选的流行应用程序），它确实需要一些设置，但是当您解决问题时可能会相当受益。

- -

还有一些商业工具，如Sauce Labs和Browser Stack，可以为您做这种事情，如果您愿意在测试中投入一些资金，则无需担心设置的问题。

- -

我们将在后续文章中查看如何使用此类工具。

- -

用户测试

- -

在我们继续之前，我们将通过谈论用户测试来完成本文––如果您有一个愿意用户组来测试您的新功能，这可能是一个很好的选择。请记住，这可以像你希望的那样廉价又有效––你的用户群可以是一群朋友，一群同事，或一群无偿或有偿志愿者，这取决于你是否有钱花在测试上。

- -

通常，您可以让用户在某种开发服务器上查看包含新功能的页面或视图，这样您就不会在完成之前放置最终站点或更改。你应该让他们按照一些步骤报告他们得到的结果。提供一组步骤（有时称为脚本）非常有用，这样您就可以获得与您尝试测试的内容相关的更可靠的结果。我们在上面的{{anch("What are you going to test")}} 部分中提到了这一点––很容易将其中详述的测试标准转换为要遵循的步骤。例如，以下内容适用于有视力的用户：

- - - -

运行测试时，最好还是：

- - - -

这些步骤旨在确保您正在测试的浏览器尽可能“纯粹（pure）”，即没有安装任何可能影响测试结果的内容。

- -
-

注意：如果您有可用的硬件，另一个有用的低功耗选项是在低端手机/其他设备上测试您的网站 - 随着网站变得更大并且具有更多效果，网站放慢速度的可能性更高，因此您需要开始给予表现更多考虑。尝试在低端设备上运行您的功能将使更高端设备的体验更有可能。

-
- -
-

注意：某些服务器端开发环境提供了有用的机制，可以将站点更改部署到仅部分用户，从而提供了一种有用的机制，可以在不需要单独的开发服务器的情况下获取由用户子集测试的功能。示例：Django Waffle Flags。

-
- -

总结

- -

阅读本文后，您现在应该知道如何识别目标受众/目标浏览器列表，然后在该列表上有效地执行跨浏览器测试。

- -

接下来，我们将把注意力转向测试可能发现的实际代码问题，从HTML和CSS开始。

- -

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Introduction","Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS", "Learn/Tools_and_testing/Cross_browser_testing")}}

- - - -

本章内容

- -

-

-- cgit v1.2.3-54-g00ecf