前言：
APP 无障碍适配的总体过程，其实也是边学边实施。作为客户端的开发，在这方面的适配经验为0，这也使得整个适配的过程略显艰难。在深圳无障碍研究院人员的指导下，APP 完成了改造，并顺利通过无障碍测试。以此累积经验，输出心得分享。
实施前期：
立项阶段，作为开发需要有一些基础适配的知识储备，资料包括了深圳无障碍研究院提供的在线文档（部分其实是谷歌开发文档中无障碍适配部分的汇总）以及安卓开发者官网的相关文档。
APP 无障碍适配最终呈现给障碍人士的方面，不仅仅包括应用内界面布局上的简洁性，操作简易性，功能流程的清晰程度。在移动端开启无障碍模式下，能否准确地让受限的用户正确感知功能，以及做到针对障碍人士正确且简洁的交互，也是衡量改造是否成功的关键标准。
作为开发，让自己置身于障碍人士的角色中，在手机开启无障碍模式的情况下，去进行应用程序的相关功能的操作，就是一个不小的挑战。这个过程中遇到的问题：
[if !supportLists]（1） [endif]手机开启无障碍模式，滑动手势的改变，双指/三指的操作，单击/双击操作等
[if !supportLists]（2） [endif]应用程序中各种开源组件所带来的语音播报的文案的不可控、语音播报时机的不可控等
[if !supportLists]（3） [endif]作为金融类APP，在无障碍模式下，保证用户体验的同时，风险监控和安全性的保障等
上述的前两个问题，都需要开发者在实施改造前，站在障碍人士的第一人视角进行实操，体验，以此了解应用程序在无障碍模式下的使用的痛点，方便构造一个改造的大纲。作为亲历者，大概是花了一周的时间，去适应无障碍模式下APP的操作。而第3 个问题则是需要产品和设计师借鉴其他同类APP，制定适合自身产品的解决方案。
实施阶段：
开发中遇到的技术上的难点总结：
类型一：针对视觉障碍人士，APP 内字体大小、颜色、背景色对比度等。
解决思路：套用现成方案，快速解决问题。
解决方案：这些都可以在网络上找到现成的解决方案，不做赘述。
类型二：金融类 APP 的金额数字、单字母的播报问题。这一类的问题主要提现在手机开启 TalkBack功能之后，程序内展示的金额、图形验证码、用户输入的数字、英文单字等出现的连读/无法连读、数位区分等。
解决思路：基于对 TalkBack 播报时一些特殊字符的处理现象，改造现有组件。在开发过程发现了 TalkBack 对于某些特殊字符（如空格、连字符）等中断播报的现象后，利用好该原理，对存在播报问题的文本进行特殊处理。
解决方案：自定义文本展示和输入组件，通过穿插特殊字符（空格/连字符），实现正确的播报内容。
注意事项：对于特殊处理过的字符和传输元素，在交互时要还原，保证原有交易的正确校验。
类型三：混合开发的项目，前端需借助原生能力，进行部分无障碍实现。前端页面，在实现文本自动播报、界面元素分发事件上存在短板，需要借助原生能力实现功能。
解决思路：利用现有能力进行交互实现。
解决方案：借助 mPaaS 框架现有的前端与原生的交互能力，在前端页面需要调动手机系统功能（如喇叭）时，通过接口实现调用嫁接。
类型四：第三方组件框架在 TalkBack 模式下的视图焦点问题和触摸事件分发问题。（应用程序中集成了过多的第三方组件框架，在源码不可视、不可改的条件下，出现的焦点不可控、分发事件时机不可控的问题）。
解决思路：
[if !supportLists]（1） [endif]针对源码质量较轻的组件，改变集成模式，通过参考源码实现自定义/源码项目模型集成的方式，实现源码的可修改，进而实现焦点和分发事件的可控。
[if !supportLists]（2） [endif]针对实现方案（1）改造代价过大的组件，通过谷歌提供的无障碍能力，借助 Accessibility 相关 API，实现程序内视图分发事件的拦截、改造。
解决方案：
[if !supportLists]（1） [endif]改变第三方组件的集成模式（缺点：源码质量增大）
[if !supportLists]（2） [endif]自定义组件实现（缺点：耗时费力）
[if !supportLists]（3） [endif]分发事件的改造（缺点：适用的组件范围小）
实施后期：
整个的改造过程持续了有三个月的时间，期间不断地发现新问题、测试、优化，到最终上线以及通过深圳无障碍研究院的检测。
以单个/多个项目合并输出无障碍开发相关规范文档，为后续新增功能开发制定标准。