什么是模态？ (What are modals?)

A modal, or modal dialog, is an overlay window that opens on top of the current primary content or screen. It places focus on itself, usually making the background inactive (“inert”) — i.e. visually greyed out or dimmed.

模态或模态对话框是在当前主要内容或屏幕顶部打开的覆盖窗口。 它专注于自身，通常使背景处于非活动状态(“惰性”)，即在视觉上变灰或变暗。

It can be dismissed by pressing some kind of close or X button, by tapping away from the on-focus area, or by pressing an appropriate “cancel” CTA.

可以通过按某种关闭或X按钮，轻按远离对焦区域或按适当的“取消” CTA来消除它。

In web design and development, there are three things that impact the success of modals:

在网站设计和开发中，有三件事会影响模式的成功：

1. Is there an appropriate use case?
   有合适的用例吗？

2. Is it designed in line with usability heuristics and W3C guidelines?

   它的设计是否符合可用性启发法和W3C准则 ？

3. Is it built in line with W3C and maximising ARIA practices?
   它是否符合W3C并最大化了ARIA做法？

Any of these can cause usability and accessibility issues for users.

这些中的任何一个都可能导致用户的可用性和可访问性问题。

In this article, I’m going to look at how UX Design and Front-end development skill sets can work together to achieve positive outcomes.

在本文中，我将研究UX设计和前端开发技能集如何协同工作以实现积极的成果。

Note: These are learnings from live projects and personal study, so as always — correct me in the comments. We’re all a work-in-progress.

注意：这些是从实际项目和个人学习中获得的经验，因此一如既往-在评论中纠正我。 我们都在进行中。

他们解决什么问题？ (What problem do they solve?)

There are two main accepted use cases for modals:

模态有两个主要的公认用例：

1. Data input — To allow users to complete a small additional task as part of a primary flow without opening a new window or starting a new journey.

1.数据输入 -允许用户作为主要流程的一部分完成少量其他任务，而无需打开新窗口或开始新旅程。

This allows user to provide data required by the system, without leaving the context and flow of the task they are currently engaged in. As an example, this could be a date picker, or some critical permissions. In ARIA practices, this is covered by a general modal dialog.

这允许用户提供系统所需的数据，而无需离开他们当前正在从事的任务的上下文和流程。例如，这可能是日期选择器或某些关键权限。 在ARIA实践中，这由常规的模态对话框覆盖。

2. An alert — To introduce necessary friction.

2.警报 —引入必要的摩擦。

Not every task, journey or experience should be frictionless. Sometimes we introduce friction deliberately to prevent user error. As an example, deleting files or content can have a significant impact on workflow, therefore this should be a high-friction action. In ARIA practices, this is called an alert dialog.

并非每项任务，旅程或经历都应该顺畅无阻。 有时我们故意引入摩擦以防止用户错误。 例如，删除文件或内容可能会对工作流程产生重大影响，因此这应该是一种高摩擦的动作。 在ARIA实践中，这称为警报对话框 。

它们会产生什么问题？ (What problems do they create?)

The way modals are used and designed can cause usability and user experience challenges. However, the most perfect visual affordance can still fall down when it comes to web accessibility, if the modal is not built correctly.

使用和设计模态的方式可能会导致可用性和用户体验方面的挑战。 但是，如果未正确构建模式，则在访问Web时，最完美的视觉承受力仍然会下降。

可用性失败 (Usability fail)

Using modals that introduce friction when it is not needed, or when a task can be completed in-line or as part of the main screen, can be a massive interruption to the user experience.

使用不需要摩擦的模态时，或者当任务可以在线或作为主屏幕的一部分完成时，可能会给用户体验带来极大的干扰。

Common occurrences of this are:

常见的情况是：

• Covering up broken journeys

  掩盖旅程

Someone decided to insert something into an existing journey and rather than redesign several screens, or think through the IA, a modal was deemed an expedient solution.

有人决定在现有流程中插入一些内容，而不是重新设计多个屏幕，或者通过IA进行思考，将模式视为一种权宜之计。

In this scenario, as designers we have to really question our own motivation and/or those of the PO or stakeholder suggesting this. Is it laziness? Or does it genuinely increase product usability and ease of task completion. In the example above I mentioned a date picker — so the question is does this have to be an overlay modal? Can this not be completed in line?

在这种情况下，作为设计师，我们必须真正质疑我们自己的动机和/或PO或利益相关者建议的动机。 懒惰吗？ 还是真的增加了产品的可用性并简化了任务的完成。 在上面的示例中，我提到了一个日期选择器-所以问题是这是否必须是覆盖模式？ 不能按顺序完成吗？

• Email sign up and general marketing trickery

  电子邮件注册和一般营销技巧

Plenty of websites use this deliberately — you’re reading an article or some content and up pops “please sign up to <random thing>”. It interrupts the journey and it can generate distrust of the entire site. This is marketing-centred design and it needs to be undertaken at the stakeholders’ own risk.

许多网站故意使用此功能-您正在阅读文章或某些内容，并且弹出窗口“请注册<random something>”。 它会中断旅程，并可能导致整个站点的不信任。 这是以市场为中心的设计，需要风险承担者自负。

In all cases and scenarios, because it is a sudden interruption to the journey, we need to be extremely clear what the purpose of the modal is — both internally and for our users.

在所有情况下，由于这是旅程的突然中断，因此我们需要非常清楚该模式的目的是什么-内部和对我们的用户而言。

If we’re going to bombard the user with sudden changes in the UI, then we need to be aware of the impact to their flow, and recognise that sudden changes can trigger stress response and as we know, even mild stress responses can lead to errors or task abandonment.

如果我们要用UI的突然变化来轰击用户，那么我们需要意识到对其流程的影响，并认识到突然的变化会触发压力响应 ，并且我们知道，即使是轻微的压力响应也可能导致错误或放弃任务。

辅助功能失败 (Accessibility fail)

Once you’ve got the visual design nailed, and overcome and the usual epic fails of colour contrast that plague the internet, you can still come a cropper.

一旦您确定了视觉设计，并克服了困扰互联网的常见色彩对比史诗般的失败 ，您仍然可以成为裁切者。

What looks like a functioning modal can turn out to be unreadable by screen readers and assistive technologies — so that they cannot even detect and communicate that the modal is being displayed. This leaves the user tabbing through the background content, unaware that the system requires an additional action from them.

屏幕阅读器和辅助技术可能无法正常显示看起来像正在运行的模态，因此它们甚至无法检测和传达模态正在显示。 这使用户在后台内容之间切换，而没有意识到系统需要他们执行其他操作。

The user can also become stuck, as the keyboard focus remains on the element that triggered the modal — the action is happening elsewhere and cannot be seen.

由于键盘焦点仍然停留在触发模式的元素上，因此用户也可能会卡住-该动作发生在其他地方并且无法看到。

Not only must modals be detected by assistive technology, but they must contain correct tab sequences, focus states, and close/dismiss functions. So working with our friends in Front-end Development is essential — those ARIA practices need to be on point.

模态不仅必须通过辅助技术进行检测，而且还必须包含正确的制表符序列，焦点状态和关闭/关闭功能。 因此，在前端开发中与我们的朋友一起工作非常重要- 这些ARIA做法必须正确 。

如何减轻失败 (How to mitigate the fails)

So we’ve decided we’re going to use a modal because you genuinely think that this pattern meets user as well as business needs — now how can we make them usable and accessible?

因此，我们已经决定要使用一种模式，因为您确实认为该模式既可以满足用户又可以满足业务需求-现在我们如何使它们可用和可访问？

There are a number of visual design and ARIA practices we can use. Many of which tie back to basic usability heuristics and W3C guidelines.

我们可以使用许多视觉设计和ARIA实践。 其中许多都与基本的可用性启发式方法和W3C准则有关 。

And of course W3C provides exhaustive guidance as always on dialog modals, so this is just a summary with a focus on the overall experience.

当然，W3C 一如既往地提供了有关对话框模式的详尽指导 ，因此，这只是一个总结，着重于整体体验。

1.屏幕填充和焦点更改 (1. Screen fill and focus change)

• Any modals on mobile-rendered websites should fill 100% of screen. This prevents background scrolling and ensures readability
  移动设备呈现的网站上的所有模式都应占据屏幕的100％。 这样可以防止背景滚动并确保可读性
• On non-mobile screens, or other scenarios that may appear in future where we are not filling 100%, we need to ensure that the background is dimmed or greyed to support visual focus on modal.
  在非移动屏幕上，或其他将来可能无法满足100％填充的情况下，我们需要确保背景变暗或变灰以支持对模式的视觉关注。

Because of this, a modal cannot require the user to have access to information displayed on the screen behind. If the user needs to access the information on the main screen to complete your task, that’s a massive hint you’re using the wrong design pattern.

因此，模式不能要求用户访问后面屏幕上显示的信息。 如果用户需要访问主屏幕上的信息以完成任务，则表明您使用的是错误的设计模式。

• When the modal is triggered, change the background to aria-hidden='true' and with the modal becoming aria-hidden='false' and{display:none;} becoming{display:block;}.

  触发模式后，将背景更改为aria-hidden='true' ，并使模式变为aria-hidden='false'而{display:none;}变为{display:block;}.

• Do not allow scrolling inside the modal itself. This will just become too difficult for users to manipulate, and plus you risk this becoming a content dumping ground unless you put tight guidelines and restrictions in place.
  不允许在模态本身内部滚动。 对于用户来说，这将变得太难了，另外，除非您设置了严格的准则和限制，否则您有冒险将其变成内容垃圾场的风险。

2.控制和解雇 (2. Control and dismiss)

Users should be able to dismiss the modal using a CTA (close/X) or by tapping away from the modal. The exception to this is when the modal is a data capture form, in which case being able to tap away could lose to loss of data already entered. In this scenario, a “cancel” button would be more appropriate. Again, introducing friction where there is a risk of error.

用户应该能够使用CTA(关闭/ X)或轻按离开模态的方式关闭模态。 例外情况是模态是数据捕获形式，在这种情况下，能够窃听可能会丢失已经输入的数据。 在这种情况下，“取消”按钮将更合适。 同样，在存在错误风险的地方引入摩擦。

Either way, it should be completely clear that it can be dismissed, and how to achieve that.

无论哪种方式，都应该完全清除它，以及如何实现它。

• The modal must be easy to dismiss — all CTA must be clear in language and design. And of course you’re using appropriate colour contrasts throughout.

•模式必须易于消除-所有CTA必须在语言和设计上清晰明了。 当然，您在整个过程中都会使用适当的颜色对比 。

• On close, the experience should revert to whatever the focus state was on the underlying screen — visual location for the user, or field focus state for the assistive tech. Where possible, screenreader focus reverts to the element that triggered the modal (unless it is no longer present).

•结束时，体验应恢复为基础屏幕上的焦点状态-用户的视觉位置，或辅助技术的现场焦点状态。 在可能的情况下，屏幕阅读器的焦点会恢复为触发模式的元素(除非不再存在)。

As with other screens, modals contain their own tab sequences, so using Tab and Shift + Tab should navigate within the modal only, without closing until the user selects close CTA or ESC.

与其他屏幕一样，模态包含它们自己的制表符序列，因此使用Tab和Shift + Tab只能在模态内导航，直到用户选择关闭 CTA或ESC才关闭 。

3.明确的信息和目的 (3. Clear message and purpose)

• The modal needs a header, which makes it clear what the modal is for and/or what the user can now do. Whether this is an alert (alert dialog)or an interaction modal (modal dialog) must be 100% clear.

•模态需要一个标题，以使模态清晰明了，并且/或者用户现在可以做什么。 这是警报(警告对话框)还是交互模式(模式对话框)必须100％清除。

• When creating an alert dialog, use alertdialog rather than dialogdialog to ensure that screenreaders know the modal can receive feedback from the user (i.e. the requirement for the user to confirm they have understood an error message)

• 创建警报对话框时，请使用alertdialog而不是dialog对话框，以确保屏幕阅读器知道模态可以接收到用户的反馈(即要求用户确认他们已理解错误消息)

• When labelling the modal use aria-labelledby so that the visible title is associated with the role=dialog container.

•在标记模式时，请使用aria-labelledby ，以使可见的标题与role=dialog容器相关联。

• Ensure that the action that triggered the modal, and the language used is reflected in the modal — i.e. Pressing a “select date” button, opens a modal with the header “select date” — or near-identical equivalent.

•确保触发模态的动作和所使用的语言在模态中得到反映-即，按下“选择日期”按钮，打开标题为“选择日期”的模态-或几乎相同。

• Do not stuff random extra words or buttons into the modal. Keep it as simple and minimal as possible (heuristic #8)

•不要将多余的单词或按钮随机塞入模态。 保持尽可能简单和最小( 启发式＃8 )

4.始终正确关注 (4. Correct focus throughout)

• Create visual focus on the modal, and on the modal’s primary task or interaction. Particularly if there is more than one step within a modal.

•将视觉焦点放在模式上以及模式的主要任务或交互上。 特别是模态中有多个步骤时。

• Maintain this clarity of purpose through any subsequent screens within the modal.

•通过模态内的任何后续屏幕保持目的清晰。

• For screenreaders, we need to ensure appropriate focus placement on each step of the journey, using aria-describedby to highlight content, fields and CTAs.

•对于屏幕阅读器，我们需要确保在旅程的每个步骤上都放置适当的焦点 ，并使用aria-describedby突出显示内容，字段和CTA。

• If the task offers complex or high impact decisions, then we should set focus on the least destructive element (i.e. cancel rather than “delete everything”).

•如果任务提供了复杂或影响较大的决策，则我们应将重点放在破坏性最小的元素上(即取消而不是“删除所有内容”)。

给UX设计师的建议 (Advice for UX Designers)

There are absolutely tons of resources online for front-end devs working with ARIA, but for UX designers working with modals, here are my top tips:

与ARIA合作的前端开发人员绝对在线上有大量资源，但是对于使用模式的UX设计人员，这是我的主要技巧：

• Be clear on your modal’s use case, be sure it’s supporting users and not just business-driven journey destruction. Incidentally, if you’ve done your IA work thoroughly and had it signed off, that should reduce the amount of random journey insertion from stakeholders. With luck.

•明确模态的用例，确保它支持用户，而不仅仅是业务驱动的旅程破坏。 顺便说一句，如果您已经彻底完成了IA工作并签字同意，那应该减少利益相关者插入随机旅程的数量。 祝你好运。

• Design everything in line with your basic heuristics. They have stood the test of time for a reason.

•根据您的基本试探法设计一切。 他们经受了时间的考验是有原因的。

• Show your wireframes and prototypes to devs early — have them validate that what you have constructed (and have tested with users) can be built, and can be built maximising ARIA practices.

•尽早向开发人员展示线框和原型-让他们验证可以构建您所构建的(并经过用户测试的)，并且可以构建最大化ARIA实践的框架。

• Test your prototypes with real users. Goes without saying. But there’s no point building anything that users can’t use. If the business is pushing for a quick (but bad) fix, video highlights reels of struggling users can really help stop the nonsense.

•与真实用户一起测试您的原型。 一点不吭就走了。 但是，构建用户无法使用的东西毫无意义。 如果企业要求快速(但不好)的解决方案，那么视频中的那些苦苦挣扎的用户将可以真正帮助您消除废话。

• Test your staging or live site with screen reader tech — there are lots of assistive tech and sim tools available.

•使用屏幕阅读器技术测试您的演出或现场站点-有很多辅助技术和模拟工具可用 。

• Check with the dev team, and generally support them in beta testing of your experience in different browsers — because which browsers can support which ARIA practices changes with each release.

•与开发团队联系，并为他们在不同浏览器中的使用体验进行Beta测试，通常会为他们提供支持-因为哪种浏览器可以支持每个版本的ARIA惯例会发生哪些变化 。

When it comes to accessibility, it really is 50-50 UX design (and research) and Front End Dev. As always follow the guidelines, talk to each other, and keep on testing.

当涉及到可访问性时，实际上是50-50 UX设计(和研究)和Front Dev。 一如既往地遵循准则，互相交谈，并继续进行测试。