什么是模態？ (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。 一如既往地遵循準則，互相交談，并繼續進行測試。