可访问性事件

这个问题总是悬挂在空中，暂时不言而喻：“有没有办法知道什么时候……？”客户和开发人员都了解查询，但是表达出来的疑问是令人惊讶的困难。

最初，它似乎纯粹是技术性的 - 类似于询问特定设备上的功能。但是犹豫揭示了更深的一层。诸如“辅助浏览上下文”之类的短语不会像“手机上”或“缓慢连接”那样轻松地滚开舌头。前者是可访问专家的语言；后者，客户的日常现实。

终于表达的问题通常是类似的：“有没有办法知道何时使用屏幕读取器？”

很长一段时间以来，答案与典型的复杂网络开发响应相比是一个可喜的变化：“不，我们不能。”从技术上讲，这是不可能的；计算机不会以这种方式交流。 “否”提供了一种解脱的感觉，证实了他们不言而喻的假设。

我解释说，即使在技术上可行，也是不可取的。检测辅助技术的使用将增加我们的维护负担，而不是减少它。它类似于“电话用户”场景；我们无法可靠地确定浏览上下文，并假设导致问题。每个新功能都需要额外的工作来确保可访问性，这提出了一个问题：该功能是否足够必要以证明额外的努力？

一个完整的网站以及单独的，可访问的版本的想法似乎很吸引人。但是，这种方法很快就会崩溃：无法访问的主站点不可避免地意味着不完整的访问版本。创建独特的“可访问体验”将其降级为事后想法，反映了许多专用移动网站的局限性。

很少有分歧。我们都经历了被迫进入Subpar移动网站的挫败感。我们已经从过去的错误中学到了。

但是，这个问题超越了纯技术。这不仅涉及浏览器和屏幕尺寸。犹豫，停顿，绊倒言语的绊脚石将平凡的发展问题转化为更重要的事情。此事不言而喻的心是：“我们能知道用户是否有残疾吗？”

简单的“否”最初是授权的，这是一种方便的出路。但是iOS 12.2和MacOS 10.14.4中的“可访问性事件”的引入改变了一切。悄悄地引入此功能，允许浏览器识别配音用户。启用此设置（默认情况下），除非明确禁用，否则用户假定的残疾将被广播到Internet。

（2019年5月更新：苹果删除了此功能。）

愤怒是合理的，不仅对于用户，而且对于开发人员而言。苹果使知道用户是否有残疾，为歧视性做法打开了大门。这些信息可以捕获并用于目标营销或更糟。所有这些都是以包容性的幌子。

在某个时候，毫无疑问，“可访问性事件”的开发商涉及其可行性。他们的“是”可能是善意的，这是一个看似简单的技术解决方案。

将来，我将面临类似犹豫的问题。停顿会很熟悉。基于技术不可能的简单“否”已经消失了。我们可以知道用户是否正在使用辅助技术。这些信息可能会以无数方式滥用。

但是我不会参加苹果的错误。我的回答将是一个沉重，不舒服的“不”。不是因为我们不能，而是因为我们不应该。 “从技术上”借口消失了。答案是一个企业，明确的编号。

以上是可访问性事件的详细内容。更多信息请关注PHP中文网其他相关文章！