原理

在继续下去之前，有必要简单解释一下读屏器的基本原理。因为不了解原理的话，很容易就会认为这是读屏器的问题而不是那些软件的问题——毕竟这种简单原始的思路是很受大脑喜爱的。

Android的UI部分是用自己的一套库，其中每个可显示的部分都是一个View。每个View都有一个android:contentDescription属性。该属性就是为视障人士设计的：读屏器类的辅助工具会读取这个值，然后读出来。

于是流程很明确了：软件在设置UI的可显示部分之余，对每个组件（比如一个按钮）设置相应的android:contentDescription，以备无障碍服务使用。

当然实际使用中，无障碍服务应该还会分析层级关系，因为最起码要分析出「列表内」与否。

问题

在理解原理后，我遇到的问题就更令人迷惑了。

首先说ap15和trime：其中ap15是我用的launcher；trime是输入法。随便找张图就明白，ap15这个launcher就是一堆文字，连图标都不涉及，我实在是无法理解为什么在ap15上Talkback根本无法选取焦点。而trime也是类似的问题，无法选取虚拟按键。我个人推测，是这两个app对ViewGroup进行了某种魔改或不合理使用，于是使得Talkback没法正常分析其组件树，无法深入到最底层。

有人模仿ap15而做的Last-Launcher。它就没有ap15的这个问题。

微信的事情则是另一番状况，且该状况让我对微信团队的代码质量表示十分怀疑——虽然我早就怀疑了。

先说微信聊天界面，毕竟这里问题相对较小，而且无疑是微信的锅。没错，Talkback可以正常深入到每个组件，切换前后也还算正常（但从逻辑上来说，应该先聚焦到是谁说的，再到内容）。然而手动点击「对方」的头像时，Talkback无法正常聚焦到那里，而却聚焦到整个屏幕；如果是群聊，则前后变得混乱，完全没法正常使用；打开「更多功能」部分，无法切换到第二页，也没有任何提示指示那里还有个第二页；表情部分也无法切换到后续页面（当然，可以辩解，说看不见的情况下发表情没有意义）。

如果说微信聊天界面的问题是小问题的话，公众号文章则是大问题。其中问题分两部分：一部分是微信的锅，另一部分是作者的锅。对于作者锅这一部分，虽然微信不是这个问题的直接责任人，这却显示了微信限制的HTML没有达到预期的作用；而且正是因为微信做了种种限制，在某种意义上作者不得不铤而走险选择这种方案。

先说微信无论如何都甩不掉的问题：所有图片都是通过JS加载，而图片的「说明」是一串对人类没有意义的字符；如果只是这样就算了，大不了当个苍蝇记住算了，但似乎大多数图片都是同一个说明，然而又有个别图片会是其他说明；在让Talkback进行自动朗读的时候，有些文章有时在读到一半会自动返回顶部；同样地，本来聚焦在文中某个部分，但「从下一项开始朗读」时却回到了顶部。评论部分则更奇妙：用户头像-用户名-赞数这栏从右往左聚焦；赞数不提示这是赞数，而只有个数字；用户头像不叫「用户头像」而叫「96」。

公众号文章中图片读起来就是类似这样的一串： 640?wx_fmt=gif&tp=webp&wxfrom=5&wx_lazy=1 。 我实在是无法理解为什么要弄这样一个GET请求，而不是正常地不带查询地请求个图片（带alt属性）。 当然，我同样不理解为什么非得要用JS加载图片。

另外，还有一个不是非常严重，但很影响的问题：文章的整个Layout的说明不是中文，导致遇到它时整个理解逻辑变得复杂。

而之所以说作者锅那部分实际上还要怪微信，则是基于三个方面。

第一，微信用自己限制的HTML，但却没有对HTML进行检测，从而让生产出来的部分文章在一个<p><span></span></p>中拥有大量的段落，而另一部分文章每个换行都是一个<p></p>。而读屏器类的软件却是要按结构进行地，结果就是第一种无法选中中间段落，第二种每读几个字就加个「区域」。微信号称（腾讯）自己搞了个浏览器所以微信要用那个做内置浏览器，又自己专门限制HTML，但为何在将HTML结构转为Android UI视图结构时却和处理无限制的网页的chromium的表现一毛一样？

第二，微信限制了可用的前端功能，导致作者实际上只能用各种奇怪的方案完成一些功能。但本来这些功能可能有现成（良好维护）的工具完成，结果微信的限制导致不能使用它们。而维护微信公众号工具的又往往是一些封闭的人/机构（毕竟微信这个平台就是这样的东西），所以他们更不会去考虑这方面的事情，而且外部的人又不能参与改进（开源？那是啥）。

第三，微信公众号发文章前要审核。但审核人员似乎完全没有考虑过眼睛以外的东西。这点从许多公众号中明明应该用文本表现的内容（比如次级标题、分节）却以图片表现就可见一斑。（更不要说那些几乎全部是图片但又明明不是漫画的推文了。）

呓语

这次发现着实很有意思。因为我在开发Easer的过程中有时会看到Android Studio提醒我某某图片没有加android:contentDescription，所以虽然简单了解了一下其作用，但从来没认真考虑过这点。

于是我打开了Easer试了试，发现居然一切还好。但同时，这也让我对微信的恶感上升一层：我这样什么心都没操地去写，都不会影响；这微信团队到底是搞了什么么蛾子，导致Talkback在其上的表现是那个鬼样子？

这件事让我也感受到了视障人士（尤其是盲人）使用电子产品的障碍——尤其是在有这些（在某种意义上）「必不可少」但表现诡异的软件的状况下。我当时正是按盲人之类的做关键词去搜索，但并没有找到多少辅助软件。而找到的那些都是电脑使用的（值得一提的是，有个似乎是国人开发的这类软件有Linux版），似乎没有谁在开发手机使用的软件。

于是，Android/谷歌这边毕竟还有个Talkback服务——虽然个别软件对其不兼容，但整体还是能用。而且退一万步来说，这是辅助服务的一部分，所以总是可以通过开发软件来弥补的。而我看到的消息则说iOS上的（系统）读屏器基本就是废的，而且没有办法开发第三方软件，实在是让人百感交集。

总得来说，我看到了Android作为操作系统，其为增加人群的兼容上所做出的努力，而且可以说这是目前技术条件下最好的方案了（直到基于CV+NLP的技术成熟）。但同时也看到了有些公司，总是在用奇奇怪怪的方法，最终做出奇奇怪怪的软件，使得本来很容易可以达成的效果在其上变得一团糟。偏偏这些公司又是赚钱最多的一批，是最喜欢以用户名义搞封闭的一批。不得不让人觉得，这实在是充分体现了马克思所作的总结。