| 标准编号 | GB/T 36443-2018 (GB/T36443-2018) | | 中文名称 | 信息技术 用户、系统及其环境的需求和能力的公共访问轮廓(CAP)框架 | | 英文名称 | Information technology -- Framework for specifying a common access profile (CAP) of needs and capabilities of users, systems and their environments | | 行业 | 国家标准 (推荐) | | 中标分类 | L73 | | 国际标准分类 | 35.240.20 | | 字数估计 | 54,559 | | 发布日期 | 2018-06-07 | | 实施日期 | 2019-01-01 | | 发布机构 | 国家市场监督管理总局、中国国家标准化管理委员会 | GB/T 36443-2018
Information technology--Framework for specifying a common access profile (CAP) of needs and capabilities of users, systems and their environments
ICS 35.240.20
L73
中华人民共和国国家标准
信息技术 用户、系统及其环境的需求和
能力的公共访问轮廓(CAP)框架
(ISO/IEC 24756:2009,IDT)
2018-06-07发布
2019-01-01实施
国 家 市 场 监 督 管 理 总 局
中国国家标准化管理委员会 发 布
目次
前言 Ⅲ
引言 Ⅳ
1 范围 1
2 符合性 1
3 规范性引用文件 1
4 术语和定义 1
5 可访问性模型 2
6 识别访问潜能的格式 4
6.1 公共访问轮廓介绍 4
6.2 公共访问轮廓 5
6.3 描述总体的CAP 6
6.4 描述交互组件 6
6.5 描述IC组件特征 7
6.6 特定模式信息 9
6.7 特定能力信息 12
6.8 特定处理信息 16
6.9 扩展CAP 18
7 CAPs的操作 19
7.1 CAP运算符 19
7.2 一元运算 19
7.2.1 要求(SHALL) 19
7.2.2 可选(MAY) 19
7.2.3 排除(NOT) 20
7.3 二元运算符 20
7.3.1 包含(AND) 20
7.3.2 可代替(OR) 20
7.3.3 互斥(XOR) 21
8 使用CAP 21
8.1 CAP使用介绍 21
8.2 运用CAP识别障碍 21
8.3 运用CAP选择AT 22
8.4 运用CAP管理AT 23
8.4.1 开发基础配置 23
8.4.2 开发备选配置 23
8.4.3 重新配置当前配置 23
附录A(资料性附录) CAP构造实例 25
A.1 介绍 25
A.2 用户 25
A.2.1 用户CAP介绍 25
A.2.2 对示例用户Johann的描述 26
A.2.3 对听觉的备注 27
A.2.4 Johann的CAP 28
A.3 系统 35
A.3.1 系统CAP介绍 35
A.3.2 系统的CAP方法 35
A.3.3 描述一个实例系统 36
A.3.4 实例系统CAP 36
A.4 更多信息 49
参考文献 50
前言
本标准按照GB/T 1.1-2009给出的规则起草。
本标准使用翻译法等同采用ISO/IEC 24756:2009《信息技术 用户、系统及其环境的需求和能力
的公共访问轮廓(CAP)框架》。
与本标准中规范性引用的国际文件有一致性对应关系的我国的文件如下:
---GB/T 4880.3-2009 语种名称代码 第3部分:所有语种的3字母代码(ISO 639-3:2007,
IDT)
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。
本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归口。
本标准起草单位:中国电子技术标准化研究院、中国残疾人联合会信息中心、成都信息处理产品检
测中心、成都千泓标准化事务有限公司、四川软测技术检测中心有限公司。
本标准主要起草人:崔慧萍、周琴、车容俊、周鹏程、沈河、赵菁华、徐洋、王静、樊星。
引 言
不同环境中、不同系统的用户可能会遇到暂时或持久的无法访问。系统的潜在用户需要评估系统
在预期的使用环境中可访问性。由于环境的障碍或设计的缺陷,会导致无法访问,这些用户能借助辅助
技术(ATs)以保障必要的可访问性水平。目前,尚不存在描述可访问性需求和能力的公共框架。这促
使每个潜在用户制定他们自己的评估方法,并以此调查和评估不同的系统和辅助技术。由于缺乏一个
现有的方法,可能还缺少不同系统和辅助技术能力的相关信息,导致低效、混淆、受阻,以及用户满意度
普遍较低。
当试图制定适合的辅助技术以提高可访问性时可能遇到各种困难。潜在用户所遇到的可访问性问
题会限制它们获取所需要的信息,这些信息用于确定可能的辅助技术,以帮助提高可访问性。缺少辅助
技术的经验可能也会影响试图帮助潜在用户的信息技术支持人员。
可访问性需求遍及潜在用户可能访问的所有系统。关于个人用户的可访问性问题和解决方法的信
息收集能力具备跨系统和环境的可移动性是必不可少的。本标准介绍了一个可访问性模型,作为理解
与不同环境下用户和系统交互的访问的基础。
可访问性是多维度的;存在于多个层次。模型显示了用户和系统必须共享通信能力。本标准提供
了一个框架,用于指定交互系统、用户及其环境的公共访问能力轮廓,这是使可访问性成为可能所必
要的。
CAP指定为自上而下的方式,提供了可逐级增加细节能力的扩展性。
信息技术 用户、系统及其环境的需求和
能力的公共访问轮廓(CAP)框架
1 范围
本标准规定了一个用于指定用户、计算系统及其环境包括由辅助技术支持的访问的需求和能力的
公共访问轮廓框架,提供了以标准方式识别和处理跨平台可访问性问题的基础。
本标准适用于评估特殊环境下针对特殊用户的现有系统的可访问性。
2 符合性
包括辅助技术在内的系统与/或系统组件的规范,如果其遵守第6章和第7章,则符合本标准。
3 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
ISO 80000 量值和单位(Quantitiesandunits)
下列术语和定义适用于本文件。
4.1
可访问性 accessibility
对使用者而言,产品、服务、环境或工具对最广能力范围的可用性。
注1:可访问性概念针对于完整范围的用户能力,并且不限于被正式认定为有残障的用户。
注2:以可用性为导向的可访问性的概念,旨在考虑具体使用周境的情况下,达到尽可能高级别的有效性、效率和
满意度,同时特别关注具备完全能力的用户群。
4.2
可用性 usability
产品在具体应用场景时被特定用户使用以达到特定的效用、效率和满意目标的程度。
4.3
辅助技术 assistivetechnology;AT
添加到系统或与系统结合,为单个个体增加可访问性的硬件或软件。
示例:盲人显示器、屏幕阅读器、屏幕放大软件和眼球跟踪设备都是辅助技术。
4.4
应用场景 contextofuse
产品所使用的用户、任务、设备(硬件、软件和材料)和物理与社会环境。
4.5
障碍 handicap
任何可能妨碍用户和系统交互的可访问性的事物。
5 可访问性模型
可访问性包括用户和系统之间可用的交互。交互发生在包括系统、用户、用户的任务和环境在内的
使用周境内。图1说明了交互发生的环境。障碍是任何可能妨碍用户和系统交互的可访问性的事物。
障碍的来源可是系统、用户、交互、与/或环境中的一个或多个。该模型是“免责的”,因为解决交互中的
障碍相比于归责障碍的来源要重要。
图1 用户与系统交互模型
图1使用管道表示用户和系统之间的交互流,以阀门表示交互中不同级别的障碍。用户和系统之
间的阴影流表示发生在双向的多重通信的可能性。完全开放的阀门表示交互中无障碍。完全关闭的阀
门表示交互中完全受阻。对阀门的任何其他设置都表示交互部分受阻。
尽管采用通用设计特定组件可减少交互中的障碍,但它不能消除所有状况下交互的障碍。辅助技
术是减少这些障碍的一种方法。虽然辅助技术的使用者可能没有身体机能差异,但交互中的某组件仍
会阻碍它们。如某人参加了一个讲座,其中的演讲者使用了该听众不懂的语言。由于大多数人知道至
少一种语言,该听众可能最终会知道演讲所用的语言,但是此时演讲者和听众之间的交互却被一个人不
知道另一个人使用的语言给阻碍了。该听众在不使用翻译器的情况下,是不能明白演讲细节的。在该
场景中,翻译器就是一个辅助技术。
计算机相关的辅助技术可通过以下方式实现:替代输入设备(如轨迹球、左手鼠标、吹吸系统)、替代
输出设备(如声音、盲文显示器)、可访问软件(如屏幕控制软件)和“通用设计”(即无障碍设计)。由于交
互受阻,一个可访问的计算体验是通过减少这些障碍而实现的。
辅助技术可以一种打开用户和系统之间的阀门的方式模型化,如图2所示。
图2 用户与系统交互中的辅助技术
可访问性依赖于用户与系统在交互中所使用的兼容接口。图3为包含一种辅助技术可允许在两个
不兼容的接口之间做转换。为了评估当前和未来所计划的可访问性,需要一个标准的方法描述跨所有
系统和用户的用户-系统可访问性和用户-辅助技术-系统可访问性。
图3 组件间交互
可访问性的目标是使得系统可被用户访问。然而,不同的情形要求不同的系统包。当用户目标是
与特定应用程序包交互的情况下,用户可选择操作系统、计算机、外围设备和其他辅助技术,使得应用程
序最易被访问。当用户目标是与作为已有硬/软件系统一部分的应用程序包交互的情况下,出于可访问
性目标可能需要辅助技术。
无论系统边界所处何种位置,图3表示的模型概括了所有情形。在该模型中,辅助技术可被认为是
添加到基础系统中使其对用户可访问的任何事物。可作为辅助技术的对象范围很广,包括专用的辅助
技术、通用远程控制器、智能代理,以及为满足特殊用户可访问需求而专门挑选的组件。多个辅助技术
可按顺序与/或平行方式使用以支持访问。
图4说明了用户及其最终目标之间的路径,用户希望使用的应用程序(A1,A2,A3)。在组件间的
连接线的每个方向上都可有多重通信。被使用的应用程序必须是用户可访问的。为此,软件可作为操
作系统或添加到系统中的软件的一部分,以增加单个用户的可访问性时,基于软件的辅助技术(SAT),
软件可能是需要。基于软件的辅助技术的实例包括添加的或内置的屏幕阅读器。
图4 可访问性组件
用户和应用程序之间的每个层次(操作系统、硬件、外围设备、辅助技术和环境),虽然传统上不认为
是辅助技术,但是都能达到和辅助技术一样增加或减少访问的效果。选来与应用程序一起使用的操作
系统(OS1,OS2)可限制或增强用户对应用程序的访问。当它不支持用户与应用程序之间某种形式的
交互时,则会限制访问。当它支持用户和应用程序之间的交互以一种形式到另一种形式的转换时,则会
增强访问。操作系统与之交互的计算机(C)会进一步限制用户体验。用户还被可用于计算机的外围设
备(P1,P2,P3)的能力所限制。
如图中虚线框所示,用户也许会将应用程序、操作系统、计算机和外围设备的组合作为单个系统。
当考虑可访问性时,这些组件可单独建模或作为单个系统。
辅助技术(AT1,AT2)可用于转换外围设备的交互,使其具有更高的可访问性。环境条件(E)可进
一步降低特定交互的可访问性。
对于用户,全部体验过每一组件的可访问性,就有可能感知到整个系统的可访问性。为评价用户的
可访问性,确需对整个系统的可访问性予以规定。
6 识别访问潜能的格式
6.1 公共访问轮廓介绍
通信被传输(通过系统、用户,或通过信道和环境的辅助技术)至预期的接受者(系统、用户或辅助技
术)。这包含从系统到用户和从用户到系统的信息流。这些信息流的特征不一定一致(如:系统可输出
用户能够听到的语音,然而,若用户无说话能力,则选择使用键盘将信息输入至系统)。当感官能够接收
并理解传输来的消息时,则访问存在。本标准中,系统、用户、辅助技术、环境和信道将被看作交互组件
(ICs)。个人通信可以用以完成通信的感官端、信道和传送器来建模。交互包含交互中ICs之间双向传
输的多个通信集。
访问框架模型化了所有发射器、信道、接受器的集合,包括特殊用户与特殊系统之间可能的交互,可
用于评估给定环境内特殊用户对系统的可访问性。
该访问框架包括多个集合:
{交互,每一交互由一个或多个{接收器、信道、发射器}集合构成}
并非是处理每一个交互,基于对ICs的发射器、接收器和信道特征的兼容性的理解,模型化潜在交
互集合是可能的。
6.2 公共访问轮廓
一个完整的公共访问轮廓(CAPO)是由CAPIC的每个不同交互组件(IC)构成,包括如下内容:用户
(CAPUSE)、系统(CAPSYS)、辅助技术(CAPAT)和环境(CAPENV)。
(CAPO)=Σ(CAPIC)=any(CAPUSE)∪
any(CAPAT)∪
注:联合操作(∪)用于表示将低级别的CAPs组合(集合)成适合的CAP。本标准中,该组合被进一步引用为具体
CAP的“低级-CAP联接”(见表2和表3)。
每个IC(用户、系统、辅助技术、环境)的CAPIC进一步由它的每个组件特征(CAPCF)的CAP(s)组
成,提供各种定向通信的细节和过程,包括:IC中包含的:每个输入接收器(IR)的CAPIR,每个输出发射
器(OT)的CAPOT,以及每个处理功能(PF)的CAPPF。描述PFs对用户和系统是可选的,但对ATs是
必需的。
(CAPIC)=Σ(CAPCF)=any(CAPIR)∪
any(CAPPF)∪
ICs可使用一个或多个OTs与/或IRs。在需要多个OTs或IRs的情况下,会在CAP规范内进行
和(ANDed)操作。在可由OTs或IRs替代的情况下,会在CAP规范内进行或(ORed)操作。
注:(IR1ANDIR2)等价于(IR1,IR2)。
示例:(IR1AND(IR2ORIR3))要求一直使用输入接收器IR1,并且选择使用输入接收器IR2或输入接收者IR3
之一。
系统的目的在于帮助用户执行任务。系统可被用户直接访问,也可不被用户直接访问。系统的
CAP为指定环境的用户评估和改进系统的可访问性提供了一个起点。环境可降低系统的可访问性。
辅助技术可被用于增强系统的可访问性。因此,对访问的评估包括对系统、用户、环境和辅助技术的
CAP(s)的分析。
图5为CAP的结构。该四层结构将CF特定类型的信息[即模式(CAPM)、能力(CAPC)和处理
(CAPP)]放在其专门的表格中。为求简明和节省版面,仅将适用的记录表示出来。
图5 CAP结构
6.3 描述总体的CAP
一组ICs的整体CAPO 应按表1概括的内容详细规定。每个CAPO 规范具有标识信息部分,包含
CAPO 的唯一名称Name,类型Type(即CAPO)和限定符Qualifier等信息。其可能还包含一个未结构
化的叙述性描述。叙述性描述Description可用于记录初步信息,以及/或给出对所有CAP规范的结构
化详情的易读引言。所有可用的CAPO 规范具有到CAPIC的一个或多个联接,并且可有到其他CAPO
的联接。
表1 高层CAPO 结构
描述 可能值
标识
类型 记录的类型 CAPO
名称 CAPO 的标识符或周知的名字 任何(在CAP内必须是唯一的)
限定词 一元运算符,将该记录限定为需要的、可选的或排除的
下列三种限定词之一:
{SHALL
MAY
NOT}中的一个
描述 用于记录初步信息的叙述描述,与/或深入描述该对象的可选注释 任何
联接
Peer-CAPO 该CAPO 对等的CAPO
{< cap-o-name,linkage-type >,
< cap-o-name,linkage-type >,
Lower-
CAPIC
该CAPO 使用的IC
{< cap-ic-name,linkage-type >,
< cap-ic-name,linkage-type >,
联接描述为< cap-name,linkage-type >对。cap-name域是目标CAP的名。linkage-type域描述该
链接隐含的适用的二进制运算符(即AND,OR,XOR),但如果留下空白,将意味着已给IC类型的缺
省联接类型(即,在CAPSYS/CAPAT/CAPENV情况下用 AND,在CAPUSE情况下用 OR)。更多信息见
7.3。
6.4 描述交互组件
每个CAPIC应按表2概括的内容详细说明。每个CAPIC规范具有一个标识信息部分,包含CAPIC
的唯一名称Name和类型Type(即IC规范的CAPUSE,CAPSYS,CAPAT,orCAPENV以及一个无结构的
叙述描述Descriptions和限定符Qualifier)。所有CAPIC规范具有到一个或多个IR/OT/PF组件特征
规范的联接以及到其所属的CAPO 联接。
表2 交互组件CAPIC结构
描述 可能值
标识
类型 记录的类型
下列四种CAP之一:
{CAPUSE
CAPSYS
CAPAT
名称 IC的标识符或公共知晓的名字 任何 (在CAP内必须是唯一的)
限定词 一元运算符,将该记录限定为需要的、可选的或排除的
下列三种限定词之一:
{SHALL
MAY
NOT}中的一个
描述
用于记录初步信息的叙述描述,与/或深入描述该对象的可选
注释
任何
联接
Higher-CAPO 本IC所属的CAPO
{< cap-o-name,linkage-type >,
< cap-o-name,linkage-type >,
Peer-CAPIC
该IC对等的IC。到IC信道的联接,表示该IC具有的连接信
道的数量
{< cap-ic-name,linkage-type >,
< cap-ic-name,linkage-type >,
Lower-CAPIR 本IC使用的IR
{< cap-ir-name,linkage-type >,
< cap-ir-name,linkage-type >,
Lower-CAPPF 本IC使用的PF
{< cap-pf-name,linkage-type >,
< cap-pf-name,linkage-type >,
Lower-
CAPOT
本IC使用的OT
{< cap-ot-name,linkage-type >,
< cap-ot-name,linkage-type >,
6.5 描述IC组件特征
仅当OTs相应的IRs被使用时,通信才有可能。因此,一个公共的格式用于同时描述IRs和OTs。
环境可模型化为组件,具有自身IR和OT,并具有处理潜在抑制访问的能力。处理转换了输入和输出
之间的通信,因此被表示为一对输入和输出格式连同描述转换的规则。用户和系统处理通常在评估的
范围之外。环境处理只影响通信的可用性。AT处理通过转换其特征影响通信。
每项CAPIR,CAPOT,或CAPPF应按表3概括的内容详细说明。IC组件特征(CF)规范具有一个标
识信息部分,包含如CF唯一名称Name,CAPCF规范的类型Type(即CAPIR,CAPOT,或 CAPPF)。其
也可包含一个非结构的叙述描述Descriptions和一个限定符Qualifier。
表3 IC组件特征CAPCF通用格式
描述 可能值
标识
类型 记录的类型
{CAPIR
CAPPF
CAPOT}中的一个
名称 CF的标识符或公共知晓的名字 任何 (在CAP内必须是唯一的)
限定词 一元运算符,将该记录限定为需要的、可选的或排斥的
{SHALL
MAY
NOT}中的一个
描述
用于记录初步信息的叙述描述,与/或深入描述该对象的可选
注释
任何
联接
Higher-
CAPIC
本CF所属的CAPIC
{< cap-ic-name,linkage-type >,
< cap-ic-name,linkage-type >,
Peer-CAPIR 该CF使用的IR
{< cap-ir-name,linkage-type >,
< cap-ir-name,linkage-type >,
Peer-CAPPF 该CF使用的PF
{< cap-pf-name,linkage-type >,
< cap-pf-name,linkage-type >,
Peer-CAPOT 该CF使用的OT
{< cap-ot-name,linkage-type >,
< cap-ot-name,linkage-type >,
Lower-CAPM 该CF的模式规范
{< cap-m-name,linkage-type >,
< cap-m-name,linkage-type >,
Lower-CAPC 该CF的能力
{< cap-c-name,linkage-type >,
< cap-c-name,linkage-type >,
Lower-CAPP 该CF的处理规范
{< cap-p-name,linkage-type >,
< cap-p-name,linkage-type >,
表3(续)
描述 可能值
连通性
信道容量 CF可接受的最大信道数
{1
任何其他指定的整数
N}中的一个
共享容量 CF需要的专用信道
{SHARABLE
DEDICATED
CF计算符 CF要求使用信道的时间数
{INTERMITTENT
优先级 CF在使用共享信道的优先级
{LOW
MEDIUM
HIGH
UR......
|