最近半年时间，团队都在参与“数字广东”（广东省头号工程、腾讯今年最重要的一个任务）建设，在 To G 领域磕磕碰碰一段时间，在此抛砖引玉，总结一下 To G 领域的业务特点和我们前端技术的结合点，输出（占坑）以下文章，与大家共同探讨。
数广前端团队出品，系列包括：
- 所有人的公共服务
- 大规模分包与前端验收
- 集约化与可视化搭建系统
- ……
- 番外篇 行动路径和目标
1⃣ 什么是公共服务
与大部分人一样，一开始我们认为 To G 业务就是为政府开发 To C/To B 产品，如我们平常在线办理的办事预约、办证、登记、罚款等等政府业务，但当我们真正深入参与到“数字广东”的业务后，才发现我们平常接触的只是电子政务上的公共服务(Public Service) 部分，借用 whistle 的一张图，可以大致了解广东数字政府的整体架构和公共服务在上面的位置。
广东数字政府的整体架构体系，公共服务是政府与群众的触点
传统政府一般以公共设施和“人员”提供公共服务，如市政道路、公立医院、学校、社康、公共交通、治安警察、环卫邮递等等等，如果现在转换角色，我们由政务的“使用方”转变为“设计建设方”，是否可以参考公共服务过去的建设经验。
政府主要以公共设施和“人员”给群众提供服务
公共服务，与一般个人或企业提供服务的主要差别在两方面，在需求侧，它是非竞争性的，一个人使用这种服务，不会减少其他人使用的效益，换成互联网的思维，可以理解为不存在“增值服务”，如公办医院不可能为VIP提供优先排队的服务。在供给侧，它是非排他性的，即这种公共服务一旦存在，就意味他是对所有人开放的，一个人的使用不能排斥他人使用，例如路灯、公园。
当我们开发 To C/To B 产品，一定会先确定目标用户群体，这个产品，这项服务针对的是某类型用户，某规模企业，在研发过程中，我们也有对特定用户作假设，例如针对较年轻群体（或普遍用户），我们会做酷炫的动画，会做“更先进”体验的交互操作，但在公共服务上不一样，服务的群体是所有人，且所有人的优先级是一致的，酷炫的动画和不熟悉的交互操作可能对另一类人是有害的。
To C/To B的用户和公共服务的用户有区别
而且在公共服务领域，往往是越弱势的群体越依赖使用电子政务。例如，视障人群由于外出不便，很多时候会更依赖线上系统来完成实体办事⼤厅上的业务，如果我们不能⽀持读屏和键盘操作的话，那会是非常大的问题 。
弱势群体也许更依赖线上服务
因为过去的经验，我们很快联想到“信息无障碍”，为有障碍的人群提供专门针对性的开发，接下来，我们看看目前大部分电子政务系统是怎样解决这个问题的。
2⃣ 现状 – 无障碍通道
虽然信息无障碍的意识在互联网已经很普及，但目前绝大部分政务系统采用了另一种方式处理，单独为“障碍”人士提供无障碍模式。
很粗暴看似也有效果，但经过深入调研和分析后，我们发现这样一刀切的方式虽然有一定作用，但它复杂的交互和实现的不一致会导致了对真正有需要人来说，学习成本非常高，实际应用并不主流。另外，人为的区分“障碍”人群，建立“信息孤岛”其实并不科学，技术应该努力消除壁垒，而不是建立新的技术壁垒。
深圳政府在线是无障碍模式运用中相对理想的案例，但依然存在缺陷
3⃣ 尝试 – 信息无障碍开发
以互联网思维优化电子政务，我们开始用过去的经验，改造系统，按照以往的流程，我们在完成业务逻辑开发后，实施无障碍开发。
无障碍“打补丁”开发流程
但现实无情地打了我们一个响亮的巴掌，简单看只是在流程上增加了两项专门对视障人群的适配工作，但实际上这样打补丁的成本非常高。
例如，由于原来页面元素之间没有考虑键盘操作的关联，现在需要耗费大量时间逐一走查页面添加。在内容放置上，由于原来没有考虑到读屏重复朗读的问题（如页面导航），现在也要在各个页面都加入 Skip to Content 的方法。
而且这仅仅是增加了读屏，键盘操作的补丁的工作，还有对比度设置、屏幕放大、快捷键操作等等大量为其他有障碍人群提供的功能，这部分工作，也不简单是前端改代码就可以实现，涉及内容、交互、视觉等等方方面面的参与。
我们回头思考是否可以改变这种模式，公共服务既然以服务所有人为核心述求，那在项目开始阶段，为何不把这方面考虑提到最优先的位置。
4⃣ 赋能 – 通用性设计
在产品和环境设计领域有一个非常适合公共服务的设计理念 – 通用性设计，它强调无须改良或特别设计就能为所有人使用，当我们重新审视我们之前的无障碍开发流程时，自然发现后置处理的不合理性，如果我们从项目的开始，就确定为所有人设计，那么在：
- 需求阶段，应该先确定尽可能大的用户群体（失明、低视力、失聪和重听、学习障碍、认知障碍、行动不便、言语残疾、光过敏），和技术能实现的底线；
- 交互阶段，根据 WCAG 2.1 可感知性、可操作性、可理解性原则走查内容和交互形式的无障碍性；
- 视觉阶段，对设计稿进行色彩对比度检测，补充图示，对不同字号方案进行适配；
- 开发阶段，在代码加入读屏、键盘操作的支持，规划快捷键方式，与交互确定内容跳过方案，对不同多终端进行兼容性（鲁棒性）支持；
- 测试阶段，对产品进行自动化和手动的无障碍监测；
- 产品上线后，对业务进行持续无障碍校验和评分；
通用性设计的开发流程应该是在每个环节都充分考虑所有群体的需求
从项目起始到上线运营，这显然不是简单一项由前端工程师就能完成的工作，在项目中普及无障碍的意识显得格外重要，所有岗位和角色都应该参与进来。
通用性设计理念同时纠正了我们过去对“障碍”的定义，狭义的“障碍”是指某种机能性的残障，例如：视障、聋哑、肢体残障等等，但我们平常生活中也总会在某些时刻，或某些场景有“障碍”的情况，例如，我的常用手受伤了，这时另外一只手操作键盘会更加方便，例如，iMac鼠标没电了，插入充电后就只能用键盘操作，键盘操作显然不只是一项“无障碍”的开发工作。
“障碍”有永久性的机能障碍、短期的受伤情况和暂时因某种场景需要的障碍等
在 To C/To B 产品中，我们经常会对用户本身使用的方式加以限制，优先满足“正常人”的需求，已达到理想中一致的体验。
例如，为了保证在移动端上页面不会因屏幕缩放而变形，我们 Meta 元信息上禁用屏幕的缩放功能。
Bad Case:
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no">
在 To C/To B 产品中，这是可行的，因为我们要优先保证视觉的还原，但在公共服务上，这就有悖于“非排他性”。因为我们损坏了一部分希望能把屏幕放大的需求（例如老人视力不佳、例如需要把屏幕聚焦在某处的场景）。
还有，在 To C/To B 产品中我们常常会不自觉的优先为一部分人提供更优的体验，而忽略另一部分人的需求。
例如为了提升输入城市地名的正确率和效率，我们封装了一个有自动提醒列表的城市选择器，因为有了自动提醒，“正常人”的输入体验大幅提升，但是很快会发现，“障碍”人群的读屏和键盘操作是无法使用的。
Bad Case:
<template> <label>开户地市:</label> <autocomplete :items="[ '广州市', '深圳市', '汕头市', '汕尾市', …… ]" /> <p>请选择开户地市</p> </template>
在 To C/To B 产品中，这也许可行，因为我们大部分的服务是基于用户有“足够”的条件才能使用，但在公共服务上，这就有悖于“非竞争性”，我们不能因为一部分人的体验优化而忽略了另一部人的需求。
上面例子中，与HTML的 Label 和 Input 标签相比，我们的实现，读屏软件并不理解他们之间的关系（Label 有 for 属性或与Input 的嵌套关系），所以我们还需要添加 aria-labelledby 的属性，让读屏软件清楚他们之间的联系，正常朗读出“开户地市：”，“文本输入框”。我们的报错提示是用P标签隐藏的，读屏软件并不能理解它隐藏和显示的意义（Alert 提示出现会被马上朗读），因此需要添加 aria-live=”polite” 让读屏软件提醒用户这一变化。
还有我们的下拉列表，还需要添加键盘响应以便在没有鼠标的情况下也能完成选择。
渐进增强，依赖HTML标签是前端一直以来的信条，随着JavaScript语言的发展，框架和工具大大提高了前端的劳动生产率和实现能力。当我们决定要取代HTML、取代浏览器的能力时，在公共服务领域便意味着需要完整的实现浏览器原来做的工作，框架和浏览器大都提供使用接口。请一定记住遵循“渐进增强和优雅退化”的原则。
5⃣ 最后
通用性设计只是设计上的概念和理论，在我们日常前端开发的工作中，往往还是业务属性，产品需求决定我们的技术选择和应用，过去我们讲信息无障碍，大部分时候都是依靠情怀、道德、技术要求来驱动我们前端岗位来做这项工作，但在 ToG 公共服务领域，这项任务就再也不是单兵作战和只是额外完成的事情，它是整个项目团队不得不优先做，并且不得不做好的本分工作。
跟着公司对“数字政府”赋能脚步，我们有机会参与到广东省政务系统的升级优化，希望我们能继续把通用性设计理念运用到电子政务的体验优化中，作为老百姓，为自己做点事情，改变一点点东西。
下期预告，原有电子政务系统中都是由开发商、供应商支持开发的，面对不同能力水平和技术背景的开发团队，数字广东前端团队作为总包方、平台方选择怎样的开发合作模式和工具与开发商协同并进呢，请看下回分解。