# If you want to create a `button` from scratch, you must first create the universe # 如果你想从头开始制作一个 `button`，你必须首先创造宇宙 --- The title is a tongue-in-cheek parody of a famous quote by astronomer and science communicator Carl Sagan. In his 1980 television series *Cosmos*, Sagan famously remarked: *"If you want to make an apple pie from scratch, you must first invent the universe."* This quote underscores the idea that even the simplest creations rely on a vast chain of pre-existing cosmic, chemical, and evolutionary history. This concept ties in very well with the thought exercise we are doing today. 这个标题是对著名天文学家兼科普作家卡尔·萨根（Carl Sagan）名言的一个幽默模仿。萨根在 1980 年的电视系列片《宇宙》（*Cosmos*）中曾说：*“如果你想从头开始制作一个苹果派，你必须首先发明宇宙。”* 这句话强调了一个观点：即便是最简单的创造，也依赖于极其庞大且早已存在的宇宙演化与历史链条。这个概念与我们今天进行的思想实验高度契合。 When we start learning about web accessibility (often abbreviated as **A11y**), the first things we usually hear are one of two principles: 当我们开始学习网页无障碍（通常缩写为 **A11y**）时，最先听到的通常是以下两条原则之一： > 1. **The first rule of ARIA is to not use ARIA.** (ARIA, or Accessible Rich Internet Applications, is a set of attributes defined by the W3C to make web content more accessible, but misusing it often does more harm than good.) > > **ARIA 的第一条规则就是不要使用 ARIA。**（ARIA 即“可访问富互联网应用程序”，是 W3C 制定的一组属性，旨在提高网页内容的可访问性。但若使用不当，往往适得其反。） And: 以及： > 2. **If there is a native element, use that instead of recreating the element.** > > **如果有原生的元素，请直接使用它，而不是自己去重新创造一个。** But people never explain *why* this advice is given, and *why* we should not recreate things from scratch. 然而，人们很少解释*为什么*要给出这些建议，以及*为什么*我们不应该从头开始重建这些元素。 I’m going to try to explain why recreating some components from scratch is usually a **Sisyphean task** with the example of (mostly) recreating a `button` from scratch. (In Greek mythology, Sisyphus was condemned by the gods to roll a giant boulder up a hill, only for it to roll back down each time he neared the top, symbolizing an endless, ineffective struggle.) 接下来，我将以（基本）从头重建一个 `button` 元素为例，解释为什么从头重建一些组件通常是一项**希绪弗斯式的任务**。（在希腊神话中，希绪弗斯被神明惩罚将巨石推向山顶，但每当他快要到达山顶时，巨石就会滚落，使他陷入永无止境且徒劳无功的挣扎中。这里常用来比喻永无止境且毫无成效的苦役。） --- ## Newtonian laws of UX / 体验设计的“牛顿定律” Native elements have a set of expectations on their behaviour. They *follow some laws of UX*. 原生元素拥有一系列既定的行为预期。它们*遵循着体验设计（UX）的一些既定规律*。 Users on your application expect to interact with the element in specific ways and expect that the element will behave in specific ways. For references, we will use the following links as a base of what a button *is*, how it *behaves*, and how users expect to *interact* with it: 你应用中的用户期望以特定方式与元素进行交互，并期望该元素表现出特定的行为。作为参考，我们将以下列链接作为基础，来界定一个按钮究竟*是什么*、它是如何*运作*的，以及用户期望如何与它*交互*： * [Button role on MDN](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/button_role) * [Button pattern on APG (Accessible Rich Internet Applications Authoring Practices Guide)](https://www.w3.org/WAI/ARIA/apg/patterns/button/examples/button/) * [Button role on ARIA specification](https://w3c.github.io/aria/#button) * [Button element on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button) * [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) (WCAG is the international standard for web accessibility compliance developed by the W3C / WCAG 是由 W3C 制定的一套保障残障人士顺利访问网页内容的网页无障碍国际标准。) Those references give us the following list of requirements, along with the corresponding WCAG Success Criteria (SC) that represent that requirement: 这些参考资料为我们列出了以下需求清单，并附带了代表该需求的对应 WCAG 成功准则（SC）： 1. **Have a role of `button`.** (SC 4.1.2) 具有 `button` 的角色（Role）。(SC 4.1.2) 2. **Have an accessible label.** (SC 4.1.2, and SC 1.3.1) 具有可访问的标签（Accessible Label）。(SC 4.1.2 和 SC 1.3.1) 3. **Be focusable.** (SC 2.4.3, and SC 2.4.7) 可以获取焦点。(SC 2.4.3 和 SC 2.4.7) 4. **Activate with a mouse click.** 可通过鼠标点击激活。 5. **Activate by touch.** 可通过触摸激活。 6. **Activate by stylus and other pointing devices.** 可通过手写笔及其他指针设备激活。 7. **Activate on `Space` and `Enter` keys when focused.** (SC 2.1.1) 获取焦点时，可通过 `空格键`（Space）和 `回车键`（Enter）激活。(SC 2.1.1) 8. **Have a type and: submit a form; reset a form; or not do anything with the related form.** 具有类型属性（Type），并能：提交表单；重置表单；或者对关联表单不执行任何操作。 9. **A `name` and `value`, and form attributes when participating in forms.** (SC 4.1.2) 在参与表单时，具有 `name` 和 `value` 属性以及表单相关属性。(SC 4.1.2) 10. **Participate in form validation.** (SC 3.3.1) 参与表单验证。(SC 3.3.1) 11. **Support states, like `disabled`.** (SC 4.1.2) 支持状态，例如“禁用”（`disabled`）。(SC 4.1.2) 12. **Support newer APIs like Popover API, Invoker Commands API, or Interest Invokers API.** 支持较新的 API，例如弹出窗口 API（Popover API）、调用器命令 API（Invoker Commands API）或兴趣调用器 API（Interest Invokers API）。 If that didn’t scare you already of trying to re-implement a button from scratch, buckle up, because we will work through that list and I hope *that* will discourage you from recreating elements. 如果这些要求还没有让你打消从头重建按钮的念头，那请坐稳扶好，因为接下来我们将逐一拆解这张清单。我希望*接下来的内容*能彻底劝退你重新发明轮子的想法。 --- ## Custom element nuclei / 自定义元素的雏形 Our *custom element nucleus* will be a new tag. We do so because custom tags behave just like a `` by default. That gives us an “empty state” to start working on. We then add a `role` of `button` to it. Now it will be exposed to the accessibility tree as a button. 我们的*自定义元素雏形*将使用一个全新的标签。之所以这么做，是因为自定义标签在默认情况下与 `` 表现一致。这为我们提供了一个“白板状态”来开始工作。然后我们为其添加一个 `role="button"` 属性。现在，它就会在无障碍树中被暴露为一个按钮。 > **NOTE / 注意**: Styling the element will be left as an exercise to the reader for two reasons: > 1. It will make things unnecessarily longer for this blog post. > 2. Custom elements can be styled however you like, with no general restrictions. > > 元素的样式设计将作为练习留给读者，原因有二： > 1. 样式代码会使这篇博客篇幅过长。 > 2. 自定义元素可以根据你的喜好进行任何样式设计，没有普遍限制。 ```html A button from scratch ``` So far so good… 目前看起来还不错…… --- ## Periodic table of ARIA / ARIA 的“元素周期表” Our button should also have an accessible label, that can be either provided by the developer or as a last case fallback derived from the element’s content. The problem here is specifically icon buttons. If we update our markup to something like this: 我们的按钮还应该有一个可访问的标签（Accessible Label），该标签可以由开发人员手动提供，或者在没有提供时，作为兜底方案，从元素的内容中提取。这里最棘手的问题莫过于“图标按钮”。如果我们把标记更新成下面这样： ```html 💩 ``` It will be read by a screen reader as something like: 屏幕阅读器朗读它时的内容大概是： > *"Button, pile of poo"* > > *“按钮，一堆便便”* There are a few issues here: 这带来了几个问题： * Emojis are read out loud, by their full legal name (e.g., as defined by the Unicode Consortium). 表情符号（Emojis）会被大声朗读出来，使用的是它们的官方法定名称。 * Not all browsers/operating systems support all emojis. It may display as a replacement character (like `` or an empty box). 并非所有的浏览器/操作系统都支持所有的表情符号。它可能会显示为一个替代字符（如问号框或空白方块）。 * This gives no clue to the user what that button *does*. 这无法给用户提供任何关于该按钮*功能*的线索。 * It starts failing WCAG SC 2.4.6 (Headings and Labels) and SC 4.1.2 (Name, Role, Value). 这已经开始违反 WCAG SC 2.4.6（标题和标签）和 SC 4.1.2（名称、角色和值）的要求。 To remediate this we could add a label to the button, and mark the emoji as presentational and/or hide it, so it is not announced by screen readers. 为了解决这个问题，我们可以为按钮添加一个无障碍标签（`aria-label`），并将表情符号标记为装饰性内容（`role="presentation"`）并将其隐藏（`aria-hidden="true"`），这样屏幕阅读器就不会朗读它了。 The code will look as follows: 修改后的代码如下： ```html ``` --- ## The focusable universe / “可聚焦”的宇宙 The component now *looks like* a button, is *announced* like a button, but cannot be *interacted with* yet. 现在，这个组件*看起来*像一个按钮，*听起来（被朗读时）*也像一个按钮，但依然无法进行任何*交互*。 The first part is to make the element keyboard focusable. To do so, we need to add the `tabindex` attribute. This will make the element become part of the tab order of the page, meaning when a user presses `Tab` they will be able to navigate and reach the element. 首先，我们需要让该元素能够通过键盘获取焦点。为此，我们需要添加 `tabindex` 属性。这将使该元素成为页面 `Tab` 键导航顺序的一部分，意味着当用户按下 `Tab` 键时，他们可以导航并定位到该元素。 ```html ``` The value for the attribute here is `0` so the element will follow the existing natural order of the page. Any positive value (such as `tabindex="1"`) would make it jump ahead of other elements, causing the focus indicator to jump unpredictably around the page, so **it is not recommended**. 这里的属性值设为 `0`，这样元素就会遵循页面原有的自然焦点顺序。任何正数值（例如 `tabindex="1"`）都会使其强行跳转到其他元素前面，导致焦点指示器在页面上毫无规律地乱跳，因此**强烈建议不要使用大于 0 的值**。 --- ## Fundamental element interactions / 元素的基本交互 We then need to add some way to activate the component. Click, touch, and pointer interactions are ways to interact with the element using those modalities. They cover click for mouse buttons, touch for touch screens, and pointer for everything else like stylus. 接下来，我们需要添加激活该组件的方法。点击（Click）、触摸（Touch）和指针（Pointer）交互是用户与该元素互动的几种不同物理媒介。它们分别涵盖了鼠标按键点击、触摸屏触摸，以及像手写笔这样的其他指针设备。 > **NOTE / 注意**: For maintaining compatibility, browsers do map both touch and pointer events (to some extent) to `click` events but here we are implementing all of them independently for the sake of argument. Some keyboard events *may* also be mapped by default, but it gets more complicated than that... > > 为了保持兼容性，浏览器确实会在某种程度上将触摸和指针事件映射为 `click`（点击）事件，但为了理清论点，我们在这里将它们作为独立的事件进行实现。有些键盘事件在默认情况下*可能*也会被映射，但实际情况要复杂得多…… We then add the events, starting with the `mouseup` for handling mouse events: 然后我们开始添加事件，首先用 `mouseup` 来处理鼠标事件： ```html ``` Let’s also add two more events: * `ontouchend` for handling when the user lifts their finger from the element. * `onpointerup` for handling other pointer devices, like styluses. 我们再增加两个事件： * `ontouchend` 用于处理用户手指离开元素时的操作。 * `onpointerup` 用于处理其他指针设备（如手写笔）。 Now our component looks like this: 现在我们的组件变成了这样： ```html ``` --- ## JS galaxy formation / JS 宇宙的形成 The code for the custom element is getting a little bit verbose on the HTML side of things. We will give it a little bit more power by using JavaScript, registering the component, and attaching a **Shadow DOM** (the Shadow DOM is a web standard used to encapsulate HTML and CSS within a web component, preventing styles and scripts from leaking in or out). 在 HTML 侧，自定义元素的属性已经开始变得有些冗长了。我们将使用 JavaScript 来赋予它更强大的能力——注册该组件并为其挂载一个**影子 DOM（Shadow DOM）**。（影子 DOM 是一种网页标准，用于在 Web 组件内部封装 HTML 和 CSS，防止组件内外的样式和脚本发生冲突和泄漏）。 > **NOTE / 注意**: To make event handling easier, it is done using the `handleEvent` method of our component. This is a powerful, native Web Component design pattern where an object with a `handleEvent` method can act as an event listener directly. > > 为了简化事件处理，这里使用了组件的 `handleEvent` 方法。这是一种强大且原生的 Web 组件设计模式：任何拥有 `handleEvent` 方法的对象都可以直接作为事件监听器使用。 The JavaScript code for our element looks like this: 我们元素的 JavaScript 代码如下： ```javascript class SaganButton extends HTMLElement { // A reference to the element internals, // this allows us to do some things with the element we cannot do otherwise. // 引用元素内部 API (ElementInternals)， // 这使我们能够对元素执行一些无法通过其他常规方式完成的操作。 /** @type {ElementInternals} */ #internals; constructor() { super(); this.attachShadow({ mode: 'open' }); this.#internals = this.attachInternals(); // Add back the things we had before. // 恢复我们之前配置的各种属性。 this.#internals.role = 'button'; this.#internals.ariaLabel = 'Data Sharing Options'; this.tabindex = 0; } /** * @param {Event} evt */ handleEvent(evt) { // We here filter by event type // 在这里我们根据事件类型进行过滤 switch (evt.type) { // For all of those we want to do some action. // So here we use a fallthrough here. // 对于所有这些事件，我们都想执行相同的操作，因此在这里使用 case 穿透。 case 'mouseup': case 'touchend': case 'pointerup': this.#doButtonAction(evt); break; } } connectedCallback() { this.shadowRoot.innerHTML = ` `; // We add the event listeners when the element is added to the DOM. // 当元素被添加到 DOM 中时，注册这些事件监听器。 this.addEventListener('mouseup', this); this.addEventListener('touchend', this); this.addEventListener('pointerup', this); } disconnectedCallback() { // And remove the listeners when the element is removed from the DOM. // 当元素从 DOM 中移除时，清除这些事件监听器，避免内存泄漏。 this.removeEventListener('mouseup', this); this.removeEventListener('touchend', this); this.removeEventListener('pointerup', this); } /** * @param {Event} evt */ #doButtonAction(evt) { // TODO: Implement the actual button action. // 待办：实现按钮的实际业务操作。 } } ``` Okay, we are back to where we were before adding JS into the mix, but now with more complexity! 🎉 好了，我们回到了引入 JS 之前的状态，但现在代码复杂度直线上升！🎉 --- ## Cosmic Keyboard Interaction (CKI) / 宇宙键盘交互 The button can be activated with clicks, touches, and pointers, but not using the *keyboard*. We now need to add a `keyup` and `keydown` event listener so the component can be interacted with using the keyboard. 目前这个按钮可以通过点击、触摸和指针来激活，但还无法使用*键盘*。我们现在需要添加 `keyup` 和 `keydown` 事件监听器，以便让该组件支持键盘交互。 > **NOTE / 注意**: This is the bare minimum for a semi-working keyboard-accessible button. There is a lot more nuance to these events and user expectations. > > 这仅仅是一个“勉强可用”的、支持键盘访问的按钮的最低门槛。这些事件与用户预期之间还存在着非常多的技术细节和细微差别。 ```javascript class SaganButton extends HTMLElement { connectedCallback() { // ... this.addEventListener('keyup', this); this.addEventListener('keydown', this); } disconnectedCallback() { // ... this.removeEventListener('keyup', this); this.removeEventListener('keydown', this); } /** * @param {Event} evt */ handleEvent(evt) { switch (evt.type) { // ... case 'keyup': this.#handleSpaceActivation(evt); break; case 'keydown': this.#handleEnterActivation(evt); break; } } /** * @param {KeyboardEvent} evt */ #handleSpaceActivation(evt) { // Don't do anything if the space bar is not pressed. // 如果按下的不是空格键，则不执行任何操作。 if (evt.key !== ' ') { return; } if (document.activeElement !== this) { return; } this.#doButtonAction(evt); } /** * @param {KeyboardEvent} evt */ #handleEnterActivation(evt) { if (evt.key !== 'Enter') { return; } this.#doButtonAction(evt); } } ``` --- ## Absolute zero: When elements become `disabled` / 绝对零度：当元素被“禁用” Now we are getting into attribute territory, this means implementing behaviors to match the native `