我为什么关心语义网

三个原因

语义 HTML 主要不是为了提高代码的可读性

底线

被遗忘和忽略的用户

进一步阅读

这篇会比我平常的文章更个人化一些，技术含量也更低一些。它基于我之前一篇文章下一条评论的回复，我觉得它值得扩展成一个完整的内容。

几周前，我写了一篇关于语义HTML的文章<div>，鼓励Web开发者在遇到合适的元素时，尽量选择语义元素而不是 a。这篇文章引起了轰动（至少比我之前写过的任何文章都多），这真是太棒了。

但在评论区和推特上聊了几句之后，我发现很多读者似乎对语义标签的一个方面非常感兴趣，并且关注点在于：语义代码比传统的<div>slinging 代码简洁得多。诚然，这很重要，但在我看来，这并非最重要的。

具体来说，我在讨论部分（促成我撰写本文的那次）的一次对话是关于，是否应该超越现有的语义标签，使用自定义的非标准标签来使文档更易读。在我看来，这不是一个好主意，我在那篇文章中解释了原因，但这次对话确实让我意识到，如果我们不谨慎，我们可能会过于关注标记的外观，而忘记最初定义标准的初衷。

三个原因

经过大量的思考和讨论，我发现编写语义 HTML 基本上有三个主要原因，这三个原因使得每个为 Web 编写 HTML 的人都应该理解和使用它：

1. 代码更符合人体工程学，也就是说，对开发者更有利——语义元素更易于阅读，无论是作为 HTML 标签还是 CSS 选择器。它们的用途和含义定义清晰，使文档结构更加清晰。它们通常还具有某些默认样式和行为，这让开发者的工作更加轻松，因为我们无需花费时间自行添加。

2. 搜索引擎优化(SEO)，也就是对企业更有利——像谷歌这样的搜索引擎会关注你页面上的语义 HTML，尤其是当你超越语义元素，使用微数据属性（同样是 HTML5 的一部分）来调出搜索引擎关心的页面数据时。谷歌至少从 2010 年就开始关注这些内容了，他们使用微数据来创建当你搜索企业时出现的卡片。

3. 可访问性，即对用户更有利——许多语义元素在帮助用户更轻松地浏览和使用您的网站方面发挥着非常重要的作用。对于那些以鼠标+键盘+显示器+颜色+扬声器以外的方式与您的网站互动的用户来说，这一点尤为重要，因为鼠标+键盘+显示器+颜色+扬声器往往是唯一需要考虑的因素。帮助用户的辅助技术通常严重依赖某些语义元素来理解网页文档，包括标题（<h1>- <h6>）、区域元素（例如<section>和<article>），以及<nav>在文档和/或网站其他部分中调出导航的元素。

根据我文章的讨论部分以及我围绕它进行的一些讨论，我认为我犯了一个错误：我在文章中过于关注原因1，即代码对于开发人员来说更容易编写、阅读和维护。别误会，语义化的HTML代码在几乎所有情况下都更美观、更易于维护，这对开发人员来说非常好。但在我看来，原因1实际上是三个原因中最不重要的。而最重要的，正如你从本文标题中肯定猜到的那样，是原因3，即可访问性。

以下是今天的论文陈述：

语义 HTML 主要不是为了提高代码的可读性

如果语义 HTML 的主要动机是使用标签名来表达元素的用途，而不是使用 CSS 类和 HTML 属性，那么 W3C 可以走得更远：与其标准化一套非常具体且并非详尽的语义元素，不如简单地标准化动态设计的自定义标签名的使用，就像我们命名 CSS 类或 JavaScript 函数一样。但他们并没有这样做，我认为这是有充分理由的。

对我来说，最大的原因是我们需要计算机理解我们在做什么。当我们谈论语义网™时，我们不仅仅指标签向人类传达语义；它们对浏览器具有特定的含义，而浏览器又可以将其含义传达给辅助技术。但是，浏览器无法使用非标准标签做到这一点，因为这些标签没有任何定义的含义或行为供浏览器进行沟通。

使用 正确定义的自定义元素CustomElementRegistry允许开发人员向浏览器提供这些语义，这非常酷。由使用 JavaScript 和/或模板支持的 Web 框架定义的组件非常棘手，必须正确完成。默认情况下，它们也只是非标准标签，但组件模板可以添加语义元素属性，JavaScript 可以添加提供可访问行为所需的行为。

底线

重申一下，语义网不仅仅是个人偏好、风格或便利性的问题。它对众多依赖辅助技术的用户的生活有着巨大的直接影响。而辅助技术反过来又依赖于它们从 HTML 中解析出的语义来帮助这些用户。

如果您从未尝试过使用屏幕阅读器浏览网页，请务必尝试一下。我认为每个网页开发者都应该定期这样做，以便更好地了解有多少用户与网页互动，以及许多网页对于依赖辅助技术的用户来说究竟有多糟糕。在一个没有任何语义的网站上，基本上全是<div>“s”和<span>“s”，甚至还有非标准元素，屏幕阅读器最多只能从上到下阅读文本，无法让用户轻松浏览页面。但是，如果使用语义元素进行标记，屏幕阅读器就可以为用户提供页面轮廓，突出显示重要的地标，并提供便捷的跳转点，让他们能够更轻松地在页面上移动一百倍。

被遗忘和忽略的用户

根据我的经验，Web 开发培训中对语义的关注严重不足，这种知识差距会严重损害那些需要它的用户的利益。这正是我撰写语义 Web 技术和技巧文章的重要原因。我希望尽可能广泛地传播这些信息，并确保每一位 Web 开发者都能了解它。语义 HTML、微数据、ARIA，所有这些语义 Web 工具对于构建一个人人可用的 Web 都至关重要。可访问性应该成为 Web 开发培训的基础，就像 a<div>和 a之间的区别一样<span>。

这些东西直接影响着许多人的生活，其直接程度远超我们通常的想象或谈论。而关键在于：由于这些内容没有得到足够的讨论，由于HTML 101课程没有将其作为平台的基础部分进行讲解，我们最终忘记了它们，也忘记了需要它们的用户。他们不仅被遗忘，而且即使被想起，也常常被故意忽略。我听过、读过太多了解并关心无障碍问题的开发者的故事：他们加入一个团队，询问应用程序的无障碍缺陷，并提出改进建议，但却因为需要耗费太多开发时间和精力而被拒之门外。我自己就经历过这样的事。

老实说，他们说培训一支成熟团队掌握无障碍原则和技术以及更新大型现有代码库以提高无障碍性需要成本，这话没错。但这正是应该从一开始就教授无障碍性的另一个重要原因！从一开始就构建一个可访问的应用程序是免费的，但之后对其进行改造需要一定的初始成本。但事实上需要花钱，但这不应该阻止任何人这样做。如果您需要商业动机：(1) 您将可以接触到更多的用户，这意味着更多的潜在客户，(2) 您的代码将更易于维护，以及 (3) 您将拥有更好的 SEO。但同时，这也是正确的事情，我认为我们不应该总是用利润来定义它。

最终，我通过撰写有关网络语义和可访问性的文章，试图在改善网络上最缺乏服务、最被遗忘和最被忽视的用户群体之一的体验方面发挥一些小小的作用。

进一步阅读

• HTML5 中的可访问性- 对语义 HTML、ARIA 标准以及一般 Web 可访问性概念和最佳实践的精彩介绍；强烈推荐给所有编写 HTML 的人，即使对于经验丰富的开发人员来说，这也是一次很好的复习
• 网络可访问性有多昂贵？ ——关于如何以有效（且经济高效）的方式为现有代码库添加可访问性的一个非常有趣且实用的讨论
• html5accessibility.com - HTML5 中每个元素的可访问性功能的实现状态
• 无障碍 API：Web 无障碍的关键- Smashing Mag 的一篇文章，讨论了浏览器如何利用辅助技术公开语义的基础知识，以及我们作为开发人员如何利用浏览器 API 进一步实现这一点
• ARIA 地标角色- 地标是浏览器解释 HTML 语义的最基本、最基础、最易理解的部分。HTML5 中引入的语义元素通常默认具有这些角色（请参阅上文“HTML5 中的可访问性”链接），因此，如果我们使用它们，通常不需要手动分配角色。
• ARIA Landmarks Example - 来自 W3C 的一组示例，演示了如何有效地使用 ARIA Landmarks