Accessibility ― ICT products and services  
Part 1: Requirements   
 
 
 
 
KENYA  STANDARD  DKS  2952 -1:2021  
 
ICS 33.030.  
 
 
First  Edition  
 
 
 
 
 
 
 
© KEBS 2021  DKS 2952 -1:2021  
ii © KEBS 2021 – All rights reserved   
  
TECHNICAL COMMITTEE REPRESENTATION  
 
The following organizations were represented on the Technical Committee:  
 
University of Nairobi 
The Judiciary of Kenya 
Ministry of Health  
Kenya Agricultural and Livestock Research Organization (KAR LO) 
Communications Authority (CA)  
Kenya institute of blind 
National youth council (NYC)  
Kenya national association of deaf (KNAD) 
Information Communication Technology Authority 
Kenya Airport Authority (KAA)  
Ministry of Devolution  
Directorate of Occupational safety and Health Services 
Elimu Holdings Ltd.  
AMREF, Kenya  
Ministry of Public Services, Gender, Senior Citizens Affairs 
Kenya Bureau of Standards — Secretariat  
 
 
 
 
REVISION OF KENYA STANDARDS  
 
In order to keep abreast of progre ss in industry, Kenya Standards shall be regularly reviewed. Suggestions  
for improvements to published standards, addressed to the Managing Director, Kenya Bureau of Standards, 
are welcome.  
 
© Kenya Bureau of Standards, 2021  
 
Copyright. Users are reminded  that by virtue of Section 25 of the Copyright Act, Cap. 130 of 2001 of the Laws of Kenya, copyright 
subsists in all Kenya Standards and except as provided under Section 25 of this Act, no Kenya Standard produced by Kenya Bure au of 
Standards may be reprodu ced, stored in a retrieval system in any form or transmitted by any means without prior permission in writing 
from the Managing  Director.  © KEBS 2021 – All rights reserved  iii  
  
KENYA  STANDARD  DKS  2952 -1:2021  
 
ICS 33.030.  
 
 
First  Edition  
 
 
 
 
Accessibility ― ICT products and services  
 
 
Part 1: Requirements  
 
 
 
 
 
 
Kenya Bureau of Standards, Popo Road, Off Mombasa Road,  
P.O. Box 54974 - 00200, Nairobi, Kenya  
       +254 020 6948000, + 254 722202137, + 254  734600471  
       info@kebs.org
       @KEBS_ke  
Kenya  bureau of standards (kebs)  
DKS 2952 -1:2021  
iv © KEBS 2021 – All rights reserved   
  
Foreword  
 
This Kenya Standard was prepared by the Joint Working Group on Accessibility of ICT Products and Services 
for Persons with Disabilities under the guidance of the Standards Projects Committee, and it is in accordance 
with the procedures of the Kenya Bureau of Standards.  
 
Technology is making it possible for people to accomplish many things more efficiently and independently. In 
order to accommodate all people in the society, inclusive design and universal design principles should be 
integrated in products a nd services. Assistive Technology (AT) is widely adopted to ensure that Persons with 
Disabilities are able to access products and services. A combination of accessible ICT and AT enhances 
function, independence and overall wellbeing of Persons with Disabil ities. This standard specifies 
requirements for ensuring that ICT products, services and opportunities are made accessible to all, including 
Persons with  Disabilities.  
 
This standard is intended for use by policy makers, regulators, providers, procurers an d users of ICT products 
and services. The development of this standard is in response to the National Information, Communications 
and Technology (ICT) Policy of Kenya of 2019.  
 
This KS 2952 consists of the following series of standards with the general title Accessibility ― ICT Products  
and Services.  
 
— Part 1,  Requirements  
 
— Part 2,  Conformance  
 
This standard sets out in a single source, detailed, practical and quantifiable functional accessibility 
requirements that take note of global initiatives in that field and which are applicable to all Information and 
Communication Technology (ICT) products and services identified usable in public procurement.  
 
This standard contains the necessary functional requirements and provides a reference document such that if  
procedures are followed by different actors, the results of testing are similar and the interpretation of those 
results is clear. The test descriptions and evaluation methodology covered in part 2 of the standard are 
elaborated to a level of detail compli ant with ISO/IEC 17007, so that conformance testing can give conclusive 
results.  
 
During the preparation of this standard, reference was made to the following documents: 
EN 301 -549 V3.2.1:2021 -03, Accessibility Requirements for ICT Products and Services 
The National Information, Communications and Technology (ICT) Policy,  2019.  
The Data protection Act, 2019, Part IV — Principles and Obligations of personal data Protection 
Acknowledgement is hereby made for the assistance derived from these sources.  
. 
 DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  v  
  
 
 
Contents  Page  
 
Foreword  ................................ ................................ ................................ ................................ ............................  iv 
1 Scope  ................................ ................................ ................................ ................................ ......................  1 
2 Normative  references  ................................ ................................ ................................ ............................  1 
3 Terms  and definitions  ................................ ................................ ................................ ...........................  1 
4 Symbols (and  abbreviated  terms)  ................................ ................................ ................................ ........  7 
5 Functional  performance  principles  ................................ ................................ ................................ ..... 8 
5.1 General  ................................ ................................ ................................ ................................ ...................  8 
5.2 Functional  performance  principles  ................................ ................................ ................................ ..... 9 
5.2.1  Usage  without vision  ................................ ................................ ................................ .............................  9 
5.2.2  Usage with  limited  vision  ................................ ................................ ................................ ......................  9 
5.2.3  Usage without perception  of colour  ................................ ................................ ................................ .... 9 
5.2.4  Usage  without hearing  ................................ ................................ ................................ ..........................  9 
5.2.5  Usage with  limited  hearing  ................................ ................................ ................................ .................  10 
5.2.6  Usage with no or  limited  vocal  capability  ................................ ................................ .........................  10 
5.2.7  Usage with limited manipulation  or strength  ................................ ................................ ...................  10 
5.2.8  Usage with  limited  reach  ................................ ................................ ................................ ....................  10 
5.2.9  Usage with  photosensitive  seizures  ................................ ................................ ................................ .. 10 
5.2.10  Usage with limited cognition, language  or learning  ................................ ................................ ........  11 
5.2.11  Privacy  ................................ ................................ ................................ ................................ ..................  11 
6 Generic  requirements  ................................ ................................ ................................ .........................  11 
6.1 Closed  functionality  ................................ ................................ ................................ ............................  11 
6.1.1  Introduction  ................................ ................................ ................................ ................................ ..........  11 
6.1.2  General  ................................ ................................ ................................ ................................ .................  11 
6.1.3  Non-visual  access  ................................ ................................ ................................ ...............................  12 
6.1.4  Functionality closed to  text enlargement  ................................ ................................ .........................  15 
6.1.5  Visual output for  auditory  information  ................................ ................................ ..............................  16 
6.1.6  Operation without  keyboard  interface  ................................ ................................ ...............................  16 
6.1.7  Access  without speech  ................................ ................................ ................................ .......................  16 
6.2 Activation of  accessibility  features  ................................ ................................ ................................ ... 16 
6.3 Biometrics  ................................ ................................ ................................ ................................ ............  17 
6.4 Preservation of accessibility information  during  conversion  ................................ ........................  17 
6.5 Operable  parts  ................................ ................................ ................................ ................................ ..... 17 
6.5.1  Means  of operation  ................................ ................................ ................................ ..............................  17 
6.5.2  Operable  parts  discernibility  ................................ ................................ ................................ ..............  17 
6.6 Locking or  toggle  controls  ................................ ................................ ................................ .................  17 
6.6.1  Tactile or  auditory  status  ................................ ................................ ................................ ....................  17 
6.6.2  Visual  status  ................................ ................................ ................................ ................................ ........  17 
6.7 Key repeat  ................................ ................................ ................................ ................................ ............  18 
6.8 Double -strike  key acceptance  ................................ ................................ ................................ ............  18 
6.9 Simultaneous  user  actions  ................................ ................................ ................................ .................  18 
7 ICT with two -way voice  communication  ................................ ................................ ...........................  18 
7.1 Audio bandwidth  for speech  ................................ ................................ ................................ ..............  18 
7.2 Real -Time Text  (RTT) functionality  ................................ ................................ ................................ .... 18 
7.2.1  RTT provision  ................................ ................................ ................................ ................................ ...... 18 
7.2.2  Display  of RTT  ................................ ................................ ................................ ................................ ..... 19 
7.2.3  Interoperability  ................................ ................................ ................................ ................................ ..... 20 
7.2.4  RTT responsiveness  ................................ ................................ ................................ ...........................  20 
7.3 Caller  ID ................................ ................................ ................................ ................................ ................  21 
7.4 Alternatives to access  voice -based  services  ................................ ................................ ...................  21 
7.5 Video  communication  ................................ ................................ ................................ .........................  21 
7.5.1  General  ................................ ................................ ................................ ................................ .................. 21 
7.5.2  Resolution  ................................ ................................ ................................ ................................ ............ 21 DKS 2952 -1:2021  
vi © KEBS 2021 – All rights reserved   
 7.5.3  Frame  rate ................................ ................................ ................................ ................................ ............. 21 
7.5.4  Synchronization between audio  and video  ................................ ................................ ....................... 22 
7.5.5  Visual indicator of audio  with video  ................................ ................................ ................................ ..22 
7.5.6  Speaker identificatio n with video (sign  language)  communication  ................................ ............... 22 
7.6 Alternatives to access  video -based  services  ................................ ................................ ................... 22 
8 ICT with  video  capabilities  ................................ ................................ ................................ .................. 22 
8.1 Caption  processing  technology  ................................ ................................ ................................ ......... 22 
8.1.1  Captioning  playback  ................................ ................................ ................................ ............................ 22 
8.1.2  Captioning  synchronization  ................................ ................................ ................................ ............... 23 
8.1.3  Preservation  of captioning  ................................ ................................ ................................ ................. 23 
8.1.4  Captions  characteristics  ................................ ................................ ................................ ..................... 23 
8.1.5  Spoken  subtitles  ................................ ................................ ................................ ................................ ..23 
8.2 Audio  description  technology  ................................ ................................ ................................ ............ 23 
8.2.1  Audio  description  playback  ................................ ................................ ................................ ................ 23 
8.2.2  Audio  description  synchronization  ................................ ................................ ................................ ....24 
8.2.3  Preservation of  audio  description  ................................ ................................ ................................ ......24 
8.3 User controls for captions and  audio  description ................................ ................................ ............ 24 
9 Hardware  ................................ ................................ ................................ ................................ ............... 24 
9.1 General  ................................ ................................ ................................ ................................ .................. 24 
9.1.1  Generic  requirements  ................................ ................................ ................................ .......................... 24 
9.1.2  Standard  connections  ................................ ................................ ................................ ......................... 24 
9.1.3  Colour  ................................ ................................ ................................ ................................ ................... 24 
9.2 Hardware products with  speech  output  ................................ ................................ ............................ 25 
9.2.1  Speech  volume  gain ................................ ................................ ................................ ............................ 25 
9.2.2  Magnetic  coupling  ................................ ................................ ................................ ............................... 25 
9.3 Stationary  ICT ................................ ................................ ................................ ................................ ...... 25 
9.3.1  General  ................................ ................................ ................................ ................................ .................. 25 
9.3.2  Forward or  side reach  ................................ ................................ ................................ ......................... 26 
9.3.3  Forward  reach  ................................ ................................ ................................ ................................ ......26 
9.3.4  Side  reach  ................................ ................................ ................................ ................................ ............. 28 
9.3.5  Clear floor or  ground  space  ................................ ................................ ................................ ................ 29 
9.3.6  Visibility  ................................ ................................ ................................ ................................ ................ 31 
9.3.7  Installation  instructions  ................................ ................................ ................................ ...................... 31 
9.4 Mechanically  operable  parts  ................................ ................................ ................................ ............... 31 
9.4.1  Numeric  keys  ................................ ................................ ................................ ................................ ........ 31 
9.4.2  Operation of  mechanical  parts  ................................ ................................ ................................ ........... 31 
9.4.3  Keys, tickets and  fare cards  ................................ ................................ ................................ ............... 31 
9.5 Tactile indication of  speech  mode  ................................ ................................ ................................ .....31 
10 Web  ................................ ................................ ................................ ................................ ......................  32 
10.1 General  ................................ ................................ ................................ ................................ .................. 32 
10.2 Perceivable  ................................ ................................ ................................ ................................ ........... 32 
10.2.1  Text alternatives  ................................ ................................ ................................ ................................ .. 32 
10.2.3  Adaptable  ................................ ................................ ................................ ................................ .............  33 
10.2.4  Distinguishable  ................................ ................................ ................................ ................................ ....33 
10.3 Operable  ................................ ................................ ................................ ................................ ............... 34 
10.3.1  Keyboard  accessible  ................................ ................................ ................................ ........................... 34 
10.3.2  Enough  time ................................ ................................ ................................ ................................ ......... 34 
10.3.3  Seizures and  physical  reactions  ................................ ................................ ................................ ........ 34 
10.3.4  Navigable  ................................ ................................ ................................ ................................ .............. 35 
10.3.5  Input  modalities  ................................ ................................ ................................ ................................ ...35 
10.4 Understandable  ................................ ................................ ................................ ................................ ....36 
10.4.1  Readable  ................................ ................................ ................................ ................................ ............... 36 
10.4.2  Predictable  ................................ ................................ ................................ ................................ ...........  36 
10.4.3  Input  assistance  ................................ ................................ ................................ ................................ .. 36 
10.5 Robust  ................................ ................................ ................................ ................................ ................... 37 
10.5.1  Compatible  ................................ ................................ ................................ ................................ ........... 37 
10.6 WCAG 2.1, AAA  Success  Criteria  ................................ ................................ ................................ ...... 37 
10.7 WCAG  conformance  requirements  ................................ ................................ ................................ .... 38 
11 Non-web documents  ................................ ................................ ................................ ...........................  39 
11.1 General  ................................ ................................ ................................ ................................ .................  39 DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  vii  
 11.2 Perceivable  ................................ ................................ ................................ ................................ ...........  39 
11.2.1  Text alternatives  ................................ ................................ ................................ ................................ .. 39 
11.2.2  Time -based  media ................................ ................................ ................................ ...............................  39 
11.2.3  Adaptable  ................................ ................................ ................................ ................................ .............  40 
11.2.4  Distinguishable  ................................ ................................ ................................ ................................ .... 41 
11.3 Operable  ................................ ................................ ................................ ................................ ...............  42 
11.3.1  Keyboard  accessible  ................................ ................................ ................................ ...........................  42 
11.3.2  Enough  time ................................ ................................ ................................ ................................ .........  43 
11.3.3  Seizures and  physical  reactions  ................................ ................................ ................................ ........  44 
11.3.4  Navigable  ................................ ................................ ................................ ................................ ..............  44 
11.3.5  Input  modalities  ................................ ................................ ................................ ................................ ... 45 
11.4 Understandable  ................................ ................................ ................................ ................................ ... 46 
11.4.1  Readable  ................................ ................................ ................................ ................................ ...............  46 
11.4.2  Predictable  ................................ ................................ ................................ ................................ ...........  47 
11.4.3  Input  assistance  ................................ ................................ ................................ ................................ .. 47 
11.5 Robust  ................................ ................................ ................................ ................................ ..................  47 
11.5.1  Compatible  ................................ ................................ ................................ ................................ ...........  47 
11.6 Caption  positioning  ................................ ................................ ................................ .............................  48 
11.7 Audio  description  timing  ................................ ................................ ................................ ....................  49 
12 Software  ................................ ................................ ................................ ................................ ...............  49 
12.1 General  ................................ ................................ ................................ ................................ .................  49 
12.2 Perceivable  ................................ ................................ ................................ ................................ ...........  49 
12.2.1  Text alternatives  ................................ ................................ ................................ ................................ .. 49 
12.2.3  Adaptable  ................................ ................................ ................................ ................................ .............  51 
12.2.4  Distinguishable  ................................ ................................ ................................ ................................ .... 52 
12.3 Operable  ................................ ................................ ................................ ................................ ...............  54 
12.3.1  Keyboard  accessible  ................................ ................................ ................................ ...........................  54 
12.3.2  Enough  time ................................ ................................ ................................ ................................ .........  55 
12.3.3  Seizures and  physical  reactions  ................................ ................................ ................................ ........  57 
12.3.4  Navigable  ................................ ................................ ................................ ................................ ..............  57 
12.3.5  Input  modalities  ................................ ................................ ................................ ................................ ... 58 
12.4 Understandable  ................................ ................................ ................................ ................................ ... 59 
12.4.1  Readable  ................................ ................................ ................................ ................................ ...............  59 
12.4.2  Predictable  ................................ ................................ ................................ ................................ ...........  59 
12.4.3  Input  assistance  ................................ ................................ ................................ ................................ .. 59 
12.5 Robust  ................................ ................................ ................................ ................................ ..................  60 
12.5.1  Compatible  ................................ ................................ ................................ ................................ ...........  60 
12.6 Interoperability with  assistive  technology  ................................ ................................ ........................  61 
12.6.1  Closed  functionality  ................................ ................................ ................................ ............................  61 
12.6.2  Accessibility  services  ................................ ................................ ................................ .........................  62 
12.7 Documented  accessibility  usage  ................................ ................................ ................................ ....... 65 
12.7.1  User control of  accessibility  features  ................................ ................................ ...............................  65 
12.7.2  No disruption of  accessibility  features  ................................ ................................ .............................  65 
12.8 User  preferences  ................................ ................................ ................................ ................................ . 65 
12.9 Authoring  tools  ................................ ................................ ................................ ................................ .... 65 
12.9.1  General  (informative)  ................................ ................................ ................................ ..........................  65 
12.9.2  Content  technology  ................................ ................................ ................................ .............................  65 
12.9.3  Accessible  content creation  ................................ ................................ ................................ ...............  65 
12.9.4  Preservation of accessibility information  in transformations  ................................ ........................  66 
12.9.5  Repair  assist ance  ................................ ................................ ................................ ................................  66 
12.9.6  Templates  ................................ ................................ ................................ ................................ .............  66 
13 Documentation and  support services  ................................ ................................ ...............................  66 
13.1 Product  documentation  ................................ ................................ ................................ ......................  66 
13.1.1  Accessibility and  compatibility  features  ................................ ................................ ...........................  66 
13.1.2  Accessible  documentation  ................................ ................................ ................................ ................. 66 
13.2 Support  services  ................................ ................................ ................................ ................................ ..67 
13.2.1  General  ................................ ................................ ................................ ................................ .................. 67 
13.2.2  Information on accessibility and  compatibility  features  ................................ ................................ .67 
13.2.3  Effective  communication  ................................ ................................ ................................ .................... 67 
13.2.4  Accessible  documentation  ................................ ................................ ................................ ................. 67 DKS 2952 -1:2021  
vii
i © KEBS 2021 – All rights reserved   
 14 ICT providing relay or emergency  service  access  ................................ ................................ ........... 68 
14.1 Relay  services  requireme nts ................................ ................................ ................................ .............. 68 
14.1.1  General  ................................ ................................ ................................ ................................ .................. 68 
14.1.2  Text relay  services  ................................ ................................ ................................ ............................... 68 
14.1.3  Sign  relay  services  ................................ ................................ ................................ .............................. 68 
14.1.4  Lip-reading  relay  services  ................................ ................................ ................................ .................. 68 
14.1.5  Captioned  telephony  services  ................................ ................................ ................................ ............ 68 
14.1.6  Speech to speech  relay  services  ................................ ................................ ................................ .......68 
14.2 Access to  relay  services  ................................ ................................ ................................ ..................... 68 
15 Conformance  ................................ ................................ ................................ ................................ ........ 69 
Annex A (Informative) Relationship between requirements and functional performance  
principles  ................................ ................................ ................................ ................................ .............  70 
A.1 Relationships between clauses 6 to 14 and the functional  performance  principles  .................... 70 
A.2 Interpretation of  Table  A.2 ................................ ................................ ................................ .................. 80 
A.2.1  General  ................................ ................................ ................................ ................................ .................. 80 
A.2.2  Example  ................................ ................................ ................................ ................................ ................ 81 
Bibliography  ................................ ................................ ................................ ................................ ...................... 83 
 
 
  
  
KENYA  STANDARD  DKS 2952 -1: 2021  
 
 
 
Accessibility ― ICT products and services: Part: 1 Requirements  
1 Scope  
This Draft Kenya standard specifies the functional accessibility requirements applicable to ICT produc ts and 
services.  
 
This standard covers both software and hardware as well as services and it intended to be used with web - 
based , non -web and hybrid technologies.  
 
2 Normative  references  
The following referenced documents referred to in the text in such a way that some or all of their content 
constitutes requirements of this document. For dated references, only the edition cited applies. For undated 
references, the latest edition of the referenced document (including any amendments) applies.  
 
ANSI/IE EE C63.19 (2011): American National Standard Method of Measurement of Compatibility between 
Wireless Communication Devices and Hearing Aids  
 
ANSI/TIA -4965: Telecommunications telephone terminal equipment receive volume control requirements for 
digital and analog wireline handset terminals.  
 
ETSI ES 200 381 -1 (V1.2.1) (October 2012): Telephony for hearing impaired people; Inductive coupling of 
telephone earphones to hearing aids; Part 1: Fixed -line speech terminals.  
 
ETSI ES 200 381 -2 (V1.1.1) (October 2012) : Telephony for hearing impaired people; Inductive coupling of 
telephone earphones to hearing aids; Part 2: Cellular speech terminals.  
 
ETSI ETS 300 381 (Edition 1) (December 1994): Telephony for hearing impaired people; Inductive coupling of 
telephone ear phones to hearing aids.  
 
ETSI ES 202 975: Human Factors (HF); Requirements for relay services Web Content Accessibility 
Guidelines 2.0 (WCAG) 2.0.  
 
IETF RFC 4103 (2005): "RTP Payload for Text Conversation".  
 
ISO/IEC 40500:2012: Information technology — W3C  Web Content Accessibility Guidelines (WCAG) 2.0 
KS ISO 21542: "Building construction - Accessibility and usability of the built environment  
Recommendation ITU -T V.18 (2000): "Operational and interworking requirements for DCEs operating in the 
text telephone mode".  
 
Web Content Accessibility Guidelines (WCAG) 2.1  
 
3 Terms and  definitions  
For the purposes of this document, the following terms and definitions apply.  
 
ISO and IEC maintain terminological databases for use in standardization at the following addresses:  
 
• IEC Electropedia: available at  https:// www.electropedia.org  
 
• ISO Online browsing platform: available at  https:// www.iso.org/obp  
 
 
 
© KEBS 2021 y – All rights  reserved  1 2 © KEBS:2021: – All rights reserved   
 3.1 
accessibility  
extent to which products, systems, services, environments  and facilities can be used by people from a 
population with the widest range of user needs, characteristics and capabilities, to achieve identified goals in 
identified contexts of use [ KS ISO 9241 -11:2018 ] 
 
Note to entry 1: Context of use includes direct  use or use supported by assistive technologies.  
 
Note to entry 2: The context in which the ICT is used may affect its overall accessibility. This context could include other 
products and services with which the ICT may interact.  
 
3.2 
access space  
space i ntended to be occupied by the person, including their assistive technology, while they are using the 
product  
 
3.3 
Assistive Listening Devices (ALDs)  
devices that help separate the sounds, particularly speech, that a person wants to hear from background 
noise by bringing sound directly into the  ear 
 
Note to entry: These are often found in meetings and public venues such as plays, concerts and places of worship. They 
can also be used at home with televisions and other products with auditory output.  
 
3.4 
Assistive Technology (AT)  
equipment, product system, hardware, software or service that is used to increase, maintain or improve 
capabilities of individuals [ISO/IEC Guide 71:2014]  
 
Note to entry 1: Assistive technology is an umbrella term that is broader th an assistive products.  
 
Note to entry 2: Assistive technology can include assistive services, and professional services needed for assessment, 
recommendation and provision.  
 
Note to entry 3: Where ICT does not support directly connected assistive technolog y, but which can be operated by a 
system connected over a network or other remote connection, such a separate system (with any included assistive 
technology) can also be considered assistive technology. This is an additional note, not included in ISO/IEC G uide 
71:2014  
 
3.5 
assistive product  
any product (including devices, equipment, instruments and software), especially produced or generally 
available, used by or for persons with disability for participation, to protect, support, train, measure or 
substitute for body functions/structures and activities, or to prevent impairments, activity limitations or 
participation  restrictions  
 
3.6 
audio description  
additional audible narrative, interleaved with the dialogue, which describes the significant aspec ts of the visual 
content of audio -visual media that cannot be understood from the main soundtrack alone  
 
Note to entry: This is also variously described using terms such as "video description" or variants such as "descriptive 
narration".  
 
3.7 
authoring tool 
software that can be used to create or modify content  
 
Note to entry 1: An authoring tool may be used by a single user or multiple users working collaboratively.  
 
Note to entry 2: An authoring tool may be a single stand -alone application or be comprised of collections of applications.  © KEBS 2021 – All rights reserved  3 DKS 2952 -1: 2021   
  
Note to entry 3: An authoring tool may produce content that is intended for fur ther modification or for use by end -users.  
 
3.8 
caption  
synchronized visual and/or text alternative for both speech and non -speech audio information needed to 
understand the media content  
 
Note to entry: This is also variously described using terms such as  "subtitles" or variants such as "subtitles for the deaf 
and hard-of-hearing".  
 
3.9 
closed functionality  
functionality that is limited by characteristics that prevent a user from attaching, installing or using assistive 
technology  
 
3.10 
communications assistant  
person working in a relay service with major conversions, as a human intermediary (including sign language 
interpreters for video relay services)  
 
Note to entry: also known as interpreter, operator, call handler, telephone operator, etc  
 
3.11 
content  
information and sensory experience to be communicated to the user by means of software, including code or 
mark -up that defines the content's structure, presentation, and interactions  
 
Note to entry: Content occurs in three places: web pages, docume nts and software. When content occurs in a web page 
or a document, a user agent is needed in order to communicate the content's information and sensory experience to the 
user. When content occurs in software, a separate user agent is not needed in order to  communicate the content's 
information and sensory experience to the user - the software itself performs that  function.  
 
3.12 
context of use  
combination of users, goals and tasks, resources, and environment. [ ISO 9241 -11:2018 ] 
 
Note to entry: The "environm ent" in a context of use includes the technical, physical, social, cultural and organizational 
environments.  
 
3.13 
document  
logically distinct assembly of content (such as a file, set of files, or streamed media) that functions as a single 
entity rather th an a collection, that is not part of software and that does not include its own user agent  
 
Note to entry 1: A document always requires a user agent to present its content to the user.  
 
Note to entry 2: Letters, e -mail messages, spreadsheets, books, pictures, presentations, and movies are examples of 
documents.  
 
Note to entry 3: Software configuration and storage files such as databases and virus definitions, as well as computer 
instruction files such as source code, batch/script files, and firmware, are examples of files that function as part of software 
and thus are not examples of documents. If and where software retrieves "information and sensory experience to be 
communicated to the user" from such files, it is just another part of the content that  occurs in software and is covered by 
WCAG2ICT  like any other parts of the software. Where such files contain one or more embedded documents, the 
embedded documents remain documents under this definition.  
 
Note to entry 4: A collection of files zipped toge ther into an archive, stored within a single virtual hard drive file, or stored in 
a single encrypted file system file, do not constitute a single document when so collected together. The software that 
archives/encrypts those files or manages the contents of the virtual hard drive does not function as a user agent for the 
individually collected files in that collection because that software is not providing a fully functioning presentation of th at 
content.  4 © KEBS:2021: – All rights reserved   
 Note to e ntry 5: Anything that can present its own content without involving a user agent, such as a self -playing book, is 
not a document but is  software.  
 
Note to entry 6: A single document may be composed of multiple files such as the video content and closed caption text. 
This fact is not usually apparent to the end -user consuming the document/content.  
Note to entry 7: An assembly of files that represented the video, audio, captions and timing files for a movie is an example 
of a document.  
 
Note to entry 8: A  binder file used to bind together the various exhibits for a legal case would not be a document. 
Note to entry 9: Documents may contain sub -documents.  
3.14 
embedded  
directly included in the content that is downloaded to the user agent and its extension, a nd is intended to be 
used in rendering the web page  
 
Note to entry:  Something that is downloaded using a mechanism on the web page but is not used in rendering the page  
is not "embedded" in the  page.  
 
3.15 
Information and Communication Technology (ICT)  
technology, equipment, or interconnected system or subsystem of equipment for which the principal function 
is the creation, conversion, duplication, automatic acquisition, storage, analysis, evaluation, manipulation, 
management, movement, control, display, switching, interchange, transmission, reception, or broadcast of 
data or  information  
 
Note to entry: Examples of ICT are web pages, electronic content, telecommunications products, computers and ancillary 
equipment, software including mobile applications,  information kiosks and transaction machines, videos, IT services, and 
multifunction office machines which copy, scan, and fax documents.  
 
3.15.1  
ICT network  
technology and resources supporting the connection and operation of interconnected ICT  
 
3.16 
mecha nically operable part  
operable part that has a mechanical interface to activate, deactivate, or adjust the ICT  
 
Note to entry: Examples of mechanically operable parts include scanner covers, notebook docking stations and lids as 
well as physical switches a nd latches.  
 
3.17 
mechanism for private listening  
auditory output designed so that only the current user can receive the sound  
 
Note to entry: Personal headsets, directional speakers and audio hoods are examples of mechanisms for private  
listening.  
 
3.18 
non-text content  
content that is not a sequence of characters that can be programmatically determined or where the sequence 
is not expressing something in human language  
 
3.19 
non-web document  
document that is not a web page, not embedded in web pages nor used in the rendering or functioning of the 
page  DKS 2952 -1: 2021  
3.20 
© KEBS 2021 – All rights reserved  5  
 non-web software  
software that is not a web page, not embedded in web pages nor used in the rendering or functioning of the 
page  
 
3.21 
open functionality  
functionality that supports access  by assistive technology 
Note  to entry:  This is the opposite of closed  functionality.  
3.22 
operable part  
component of ICT used to activate, deactivate, or adjust the ICT  
 
Note to entry 1: Operable parts can be provided in either hardware (see mechanically  operable parts, above) or software. 
An on -screen button is an example of an operable part provided by software.  
Note to entry 2: Operable parts do not include parts involved only in maintenance or repair or other actions that are not 
expected of a typical  user if the product is not malfunctioning. These actions include: clearing paper jams internal to the 
machine, replacing items or parts internal to the machine that may expose the end user to sharp or hot surfaces, replacing 
or repairing items designated by manufacturers as service or maintenance items in user documentation.  
 
3.23 
platform software (platform)  
collection of software components that runs on an underlying software or hardware layer, and that provides a 
set of software services to other softwa re components that allows those applications to be isolated from the 
underlying software or hardware layer [ ISO/IEC 13066 -1] 
 
Note to entry: A particular software component might play the role of a platform in some situations and a client in others.  
 
3.24 
programmatically determinable  
able to be read by software from developer -supplied data in a way that other software, including assistive 
technologies, can extract and present this information to users in different modalities  
 
Note to entry: WCAG 2.1 uses "determined" where this definition uses "able to be read" (to avoid ambiguity 
with the word "determined").  
 
3.25 
relay service  
electronic communications service that enables users of different modes of communication (e.g text, sign, or 
speech) to interact by providing conversion between different modes of communication, usually through a 
communications assistant  
 
3.26 
Real -Time Text (RTT)  
form of a text conversation in point to point situations or in multipoint conferencing where the text being 
entered is s ent in such a way that the communication is perceived by the user as being continuous  
 
Note to entry 1: Users will perceive communication as continuous if the delay between text being created by the sender 
and received by the recipient is less than 500 ms.  However, the actual delay will be dependent on the communication 
network.  
 
Note to entry 2: The creation of text will differ between systems where text is entered on a word -by-word basis (e.g. 
speech‑to‑text and predictive -text based systems) and systems where each character is separately generated (e.g. typing 
on a physical keyboard).  6 © KEBS:2021: – All rights reserved   
 3.27 
satisfies a success criterion  
success criterion does not evaluate to "false" when applied to the ICT  
 
3.28 
single user connection  
connection that consists of sound, RTT or video (or a combination of two or three of those media) that is 
established by a sin gle user action  
 
Note to entry: Even though the different media may travel over different channels, and more than one piece of hardware 
may be involved, it appears to the user like a single connection, and is treated by any intermediate technologies (e.g.  
network, auto -reception) as a single connection for purposes such as transfer.  
 
3.29 
spoken captions/subtitles audio captions/subtitles  
captions/subtitles that are voiced over the audio visual content (from ISO/IEC TS 20071 -25) 
 
3.30 
stationary ICT  
ICT that stands on the floor, or is mounted on a wall or other immovable structure, and is not intended to be 
moved by its user  
 
Note to  entry 1: Typically, stationary ICT rests on the ground (such as an information kiosk) or is installed in a wall (such 
as a machine that dispenses cash or performs other banking  services).  
 
Note to entry 2: A manufacturer cannot control the height of ICT t hat is put on a table by someone else, but they are able 
to control the reach dimensions of self -contained ICT that rests on the ground and can specify the heights for installation in 
walls.  
 
3.31 
terminal  
combination of hardware and/or software with which  the end user directly interacts and that provides the user 
interface  
 
Note to entry 1: The hardware may consist of more than one device working together e.g. a mobile device and a 
computer.  
 
Note to entry 2: For some systems, the software that provides th e user interface may reside on more than one device such 
as a telephone and a server.  
 
3.32 
turn-taking  
type of organization in conversation and discourse where participants speak one at a time in alternating turns  
 
3.32 
user agent  
software that retrieves and presents content for users  
 
Note to entry 1: Software that only displays the content contained within it is treated as software and not considered to be 
a user  agent.  
 
Note to entry 2: An example of software that is not a user agent is a calculator application that does not retrieve the 
calculations from outside the software to present it to a user. In this case, the calculator software is not a user agent, it  is 
simply software with a user interface.  
 
Note to entry 3: Software that only shows a preview of content such as a thumbnail or other non -fully functioning 
presentation is not providing user agent functionality.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  7  
  
3.33 
user interface  
all component s of an interactive system (software or hardware) that provide information and/or controls for the 
user to accomplish specific tasks with the interactive system (from ISO 9241 -110) 
 
3.34 
 
user interface element  
 
entity of the user interface that is present ed to the user by the software [ ISO 9241 -171] 
 
Note to entry 1: This term is also known as "user interface component". 
Note to entry 2: User -interface elements can be interactive or not.  
3.35 
web content  
content that belongs to a web page, and that is used in the rendering or that is intended to be used in the 
rendering of the web page  
 
3.36 
web page  
non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the 
rendering or intended to be rendered together wit h it by a user agent  
 
4 Symbols (and abbreviated  terms)  
 
For the purposes of the standard, the following abbreviations apply: 
ANSI  American National Standards  Institute  
AT Assistive Technology  
 
ATAG  Authoring Tool Accessibility Guidelines (of W3C) 
CEN  Comité Européen de  Normalisation  
CSS Cascading Style Sheets 
DOM  Document Object Model 
EFTA  European Free Trade  Area  
ETSI  European Telecommunications Standards Institute 
EU European  Union  
FPSFrames Per Second  
 
FXML  XML-based user interface markup language 
HTML HyperText Markup  Language  
HTTP  HyperText Transfer  Protocol  
 
ICT Information and Communication Technology 
IETF  Internet Engineering Task  Force  8 © KEBS:2021: – All rights reserved   
 IMS IP Multimedia  System 
IP Internet  Protocol  
ISO International Organization for Standardization  
 
ITU-T International Telecommunication Union - Telecommunication standardization sector 
JWG  Joint Working Gro up (of  CEN/CENELEC/ETSI)  
LED Light Emitting Device 
ODF  Open Document  Format  
OOXML Office Open eXtensible Markup Language 
PSTN  Public Switched Telephone Network 
QVGA  Quarter Video Graphics  Array  
RFC Request For Comment 
RTTReal -Time  Text 
SIP Session Initiation Protocol  
 
UAAG  User Agent Accessibility Guidelines (of W3C) 
URI Uniform Resource  Identifier  
USB Universal Serial Bus 
VGA  Video Graphics Array 
VOIP  Voice Over  IP 
W3C  World Wide Web Consortium 
WAI Web Accessibility  Initiative  
WCAG Web Content Acce ssibility Guidelines (of W3C) 
WLAN  Wireless Local Access  Network  
XML eXtensible Markup Language 
XULXML User interface Language 
URL Uniform Resource  Locator  
5 Functional performance  principles  
5.1 General  
 
The principles set out in clause 5.2  are intended to describe the functional performance of ICT enabling 
people to locate, identify, and operate ICT functions, and to access the information provided, regardless of 
physical,  cognitive  or sensory  abilities.  Any differences  in ability  may be permanent,  temporary  or situational.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  9  
  
The requirements in clauses 6 to 14 provide specific testable criteria for accessible ICT, corresponding to the 
user needs reflected in 5.2.  
 
NOTE 1: The relationship between the requirements from clau ses 6 to 14 and the functional performance 
principles is set out in Annex A.  
 
NOTE 2: The intent of clause 5.2 is to describe the ICT performance in enabling users to access the full 
functionality and documentation of the product or the service with or wit hout the use of assistive technologies.  
 
NOTE 3: The methods of meeting the accessibility needs of users with multiple access needs will depend on 
the specific combination of needs. Meeting these user accessibility needs may be addressed by considering 
multiple clauses in clause 5.2.  
 
NOTE 4: Several users' accessibility needs rely  on ICT providing specific modes of operation. If a user is to 
activate, engage or switch to the mode that complies with his or her user accessibility needs, the method for 
activating, engaging or switching to that mode would need to comply with the same u ser accessibility needs.  
 
5.2 Functional performance  principles  
 
5.2.1  Usage without  vision  
 
Where ICT provides visual modes of operation, the ICT should provide at least one mode of operation that 
does not require vision. This is essential for users without vision and benefits many more users in different 
situations.  
 
NOTE 1: A web page or application with a well -formed semantic structure can allow users without vision to identify, 
navigate and interact with a visual user interface.  
 
NOTE 2: Audio and tactile user i nterfaces may contribute towards complying with the requirements of this clause.  
 
5.2.2  Usage with limited  vision  
 
Where ICT provides visual modes of operation, the ICT should provide features that enable users to make 
better use of their limited vision. This is  essential for users with limited vision and benefits many more users in 
different situations.  
 
NOTE 1: Magnification, reduction of required field of vision and control of contrast, brightness and intensity can contribute  
towards compliance with this claus e. 
 
NOTE 2: Where significant features of the user interface are dependent on depth perception, the provision of additional 
methods of distinguishing between the features may contribute towards compliance with this clause.  
 
NOTE 3: Users with limited visio n may also benefit from non -visual access (see clause 5.2.1).  
 
5.2.3  Usage without perception of  colour  
 
Where ICT provides visual modes of operation, the ICT should provide a visual mode of operation that does 
not require user perception of colour. This is esse ntial for users with limited colour perception and benefits 
many more users in different situations.  
 
NOTE Where significant features of the user interface are colour -coded, the provision of additional methods of 
distinguishing between the features may con tribute towards compliance with this clause.  
 
5.2.4  Usage without  hearing  10 © KEBS:2021: – All rights reserved   
 Where ICT provides auditory modes of operation, the ICT should provide at least one mode of operation that 
does not require hearing. This is essential for users without hearing and benefits many more users in different 
situations.  
 
NOTE Visual, haptic and tactile user interfaces, including those based on sign language or vibrations may contribute 
towards compliance with this clause  
 
5.2.5  Usage with limited  hearing  
 
Where ICT provides auditory modes of operation, the ICT should provide enhanced audio features. This is 
essential for user s with limited hearing and benefits many more users in different situations.  
 
NOTE 1: Enhancement of the audio clarity, reduction of background noise, providing a joint monaural option, adjustment 
of balance of both audio channels, increased range of volum e and greater volume in the higher frequency range can 
contribute towards compliance with this  clause.  
 
NOTE 2: Allowing the use of assistive listening devices, such as headsets with noise cancellation (connected by cable, 
Bluetooth or WLAN) can contribute  towards compliance with this clause.  
 
NOTE 3: Users with limited hearing may also benefit from non -hearing access (see clause 5.2.4).  
 
5.2.6  Usage with no or limited vocal  capability  
 
Where ICT requires vocal input from users, the ICT should provide at least on e mode of operation that does 
not require them to generate vocal output. This is essential for users with no or limited vocal capability and 
benefits many more users in different situations.  
 
NOTE 1: Vocal output includes speech and other orally generated sounds, such as whistles and clicks. 
NOTE 2: Keyboard, pen or touch user interfaces may contribute towards compliance with this clause.  
5.2.7  Usage with limited manipulation or  strength  
 
Where ICT requires manual actions, the ICT should provide features that ena ble users to make use of the ICT 
through alternative actions not requiring manipulation, simultaneous action or hand strength. This is essential 
for users with limited manipulation or strength and benefits many more users in different situations.  
 
NOTE 1: Examples of operations that users may not be able to perform include those that require fine motor control, path 
dependent  gestures, pinching, twisting of the wrist, tight grasping, or simultaneous manual actions.  
 
NOTE 2: One -handed operation, sequential key entry, speech user interfaces and eye control may contribute towards 
compliance with this clause.  
 
NOTE 3: Some users have limited hand strength and may not be able to achieve the level of strength to perform an 
operation. Alternative user interface so lutions that do not require hand strength may contribute towards compliance with 
this clause.  
 
5.2.8  Usage with limited  reach  
 
Where ICT products are free -standing or installed, all the elements required for operation should be within 
reach of all users. This is  essential for users with limited reach and benefits many more users in different 
situations.  
 
NOTE    Considering the needs of wheelchair users and the range of user statures in the placing of operational     
elements of the user interface may contribute towards compliance with this  clause.  
 
5.2.9  Usage with photosensitive  seizures  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  11  
  
Where ICT provides visual modes of operation, the ICT should provide at least one mode of operation that 
minimizes the potential for triggering photosensitive seiz ures. This is essential for users with photosensitive 
seizure triggers.  
 
NOTE Limiting the area and number of flashes per second may contribute towards compliance with this clause.  
 
5.2.10  Usage with limited cognition, language or  learning  
 
The ICT should provide features and/or presentation that makes it simpler and easier to understand, operate 
and use. This is essential for users with limited cognition, language or learning, and benefits many more users 
in different situations.  
 
NOTE 1: Adjustable timing s, error indication and suggestion, and a logical focus order are examples of design features 
that may contribute towards compliance with this  clause.  
 
NOTE 2: Providing an audio output of the text is an example of providing support for people with limited  reading abilities.  
 
NOTE 3: Providing spelling aid and word prediction of the text is an example of providing support for people with limited 
writing abilities.  
 
NOTE 4: Interaction with content can be made easier, and less prone to errors, by presenting tasks in steps that are easy 
to follow.  
 
5.2.11  Privacy  
 
Where ICT provides features for accessibility, the ICT should maintain the privacy of users of these features at 
the same level as other users.  
 
NOTE: Enabling the connection of personal headsets for privat e listening,  not  providing  a  spoken  version  of  
characters being masked and enabling user control of legal, financial and personal data are examples of design features 
that may contribute towards compliance with this  clause.  
 
6 Generic  requirements  
6.1 Closed  functionality  
 
6.1.1  Introduction  
 
ICT has closed functionality for many reasons, including design or policy. Some of the functionality of products 
can be closed because the product is self -contained  and users are precluded from adding peripherals or 
software in order to access that functionality.  
 
ICT may have closed functionality in practice even though the ICT was not designed, developed or supplied to 
be closed.  
 
Computers that do not allow end -users to adjust settings or install software are functionally closed.  
 
6.1.2  General  
 
6.1.2.1  Closed  functionality  
 
Where ICT has closed functionality, it shall meet the requirements set out in clauses 6.2 to 1 4, as applicable.  
 
NOTE 1: ICT may close some, but not all, of  its functionalities. Only the closed functionalities have to conform to the 
requirements of 6.1. 12 © KEBS:2021: – All rights reserved   
 NOTE 2: The requirements within this clause replace those in clauses 6.2 to 14 that specifically state that they do not 
apply to closed functionality. This may be because they relate to compatibility with assistive technology or to the ability f or 
the user  to adjust system accessibility settings in products with closed functionality (for example, products that prevent 
access to the system settings control  panel).  
 
6.1.2.2  Assistive  technology  
 
Where ICT has closed functionality, that closed functionality shall be o perable without requiring the user to 
attach, connect or install assistive technology and shall comply with the generic requirements of 6.1.3 to 6.1.6 
as applicable.  
 
Personal headsets and personal induction loops shall not be classified as assistive te chnology for the purpose 
of this  clause.  
 
6.1.3  Non-visual  access  
 
6.1.3.1  Audio output of visual  information  
 
Where visual information is needed to enable the use of those functions of ICT that are  closed to assistive 
technologies for screen reading, ICT shall provide at least one mode of operation using non -visual access to 
enable the use of those functions.  
 
NOTE 1: Non -visual access may be in an audio form, including speech, or a tactile form suc h as braille for deaf - blind 
users.  
 
NOTE 2: The visual information needed to enable use of some functions may include operating instructions and 
orientation, transaction prompts, user input verification, error messages and non -text content.  
 
6.1.3.2  Auditory outp ut delivery including  speech  
 
Where auditory output is provided as non -visual access to closed functionality, the auditory output shall be 
delivered:  
 
a) either directly by a mechanism included in or provided with the ICT;  or 
 
b) by a personal headset that can be connected through a 3.5 mm audio jack, or an industry standard 
connection, without requiring the use of  vision.  
 
NOTE 1: Mechanisms included in or provided with ICT may be, but are not limited to, a loudspeaker, a built -in 
handset/headset, or other indu stry standard coupled peripheral.  
 
NOTE 2: An industry standard connection could be a wireless connection. 
NOTE 3: Some users may benefit from the provision of an inductive loop.  
6.1.3.3  Auditory output  correlation  
 
Where auditory output is provided as non -visual access to closed functionality, and where information is 
displayed on the screen, the ICT should provide auditory information that allows the user to correlate the 
audio with the information displayed on the  screen.  
 
NOTE 1: An audio alternative that is bo th complete and complementary includes all visual information such as focus or 
highlighting, so that the audio can be correlated with information that is visible on the screen at any point in time.  
 
NOTE 2: Examples of auditory information that allows the user to correlate the audio with the information displayed on the 
screen include structure and relationships conveyed through presentation.  
 
6.1.3.4  Speech output user  control  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  13  
  
Where speech output  is provided as non -visual access to closed functionality, the speech output shall be 
capable of being interrupted and repeated when requested by the user, where permitted by security 
requirements.  
 
NOTE 1: It is recommended to allow the user to pause spee ch output rather than just allowing them to interrupt it.  
 
NOTE 2: It is recommended to allow the user to repeat only the most recent portion rather than requiring play to start from 
the beginning.  
 
NOTE 3: The user should be able to select the content len gth of the speech output they want to repeat. This includes by 
character, word, line or paragraph. It is now common on text to speech engines such as screen readers.  
 
6.1.3.5  Speech output automatic  interruption  
 
Where speech output is provided as non -visual access to closed functionality, the ICT shall interrupt current 
speech output when a user action occurs and when new speech output begins.  
 
NOTE:   Where it is essential that the user hears the entire message, for example, a safety instruction or warning, the   
ICT may need to block all user action so that speech is not  interrupted.  
 
6.1.3.6  Speech output for non -text content  
 
Where ICT presents non -text content, the alternative for non -text content shall be presented to users via 
speech output unless the non -text content is purely for decoration or is used only for visual formatting. The 
speech output for non -text content shall follow the guidance for "text alternative" described in WCAG 2.1, 
Success Criterion 1.1.1.  
 
6.1.3.7  Speech output for video  information  
 
Where pre -recorded video content is needed to enable the use of closed functions of ICT and where speech 
output is provided as non -visual access to closed functionality, the speech output shall present equivalent 
information for the pre -recorded video content.  
 
NOTE : This speech output can take the form of an audio description or an auditory transcript of the video content.  
 
6.1.3.8  Masked  entry  
 
Where auditory output is provided as non -visual access to closed functionality, and the characters displayed 
are masking character s, the auditory output shall not be a spoken version of the characters entered unless the 
auditory output is known to be delivered only to a mechanism for private listening, or the user explicitly 
chooses to allow non -private auditory output.  
 
NOTE 1: Masking characters are usually displayed for security purposes and include, but are not limited to asterisks 
representing personal identification numbers.  
 
NOTE 2: Unmasked character output may be preferred when closed functionality is used, for exam ple, in the privacy of  
the user's home. A warning highlighting privacy concerns may be appropriate to ensure that the user has made an 
informed  choice.  
 
6.1.3.9  Private access to personal  data 
 
Where auditory output is provided as non -visual access to closed func tionality, and the output contains data 
that is considered to be private according to the applicable privacy policy, the corresponding auditory output 
shall only be delivered through a mechanism for private listening that can be connected without requiring  the 
use of vision, or through any other mechanism explicitly chosen by the user.  14 © KEBS:2021: – All rights reserved   
 NOTE 1: This requirement does not apply in cases where data is not defined as being private according to the applicable 
privacy policy or where there is no applicable privacy policy.  
 
NOTE 2: Non -private output may be preferred when closed functionality is used, for ex ample, in the privacy of the user's 
home. A warning highlighting privacy concerns may be appropriate to ensure that the user has made an informed choice.  
 
6.1.3.10  Non-interfering audio  output  
 
Where auditory output is provided as non -visual access to closed functi onality, the ICT shall not automatically 
play at the same time, any interfering audible output that lasts longer than three seconds.  
 
6.1.3.11  Private listening  volume  
 
Where auditory output is provided as non -visual access to closed functionality and is delivered  through a 
mechanism for private listening, ICT shall provide at least one non -visual mode of operation for controlling the 
volume.  
 
6.1.3.12  Speaker  volume  
 
Where auditory output is provided as non -visual access to closed functionality and is delivered through 
speakers on ICT, a non -visual incremental volume control shall be provided with output amplification up to a 
level of at least 65 dBA.  
 
NOTE: For noisy environments, 65 dBA may not be sufficient, but should not exceed 85 dBA.  
 
6.1.3.13  Volume  reset  
 
Where auditory out put is provided as non -visual access to closed functionality, a function that resets the 
volume to be at a level of 65 dBA or less after every use, shall be provided, unless the ICT is dedicated to a 
single user.  
 
NOTE:  A feature to disable the volume rese t function may be provided in order to enable the single -user exception to 
be met. 
 
6.1.3.14  Spoken  languages  
 
Where speech output is provided as non -visual access to closed functionality, speech output shall be in the 
same human language as the displayed content provided, except:  
 
a) for proper names, technical terms, words of indeterminate language, and words or phrases that have 
become part of the vernacular of the immediately surrounding  text; 
b) where the content is generated externally and not under the control of the ICT vendor, this clause 
shall not be required to apply for languages not supported by the ICT's speech  synthesizer;  
c) for displayed languages that cannot be selected using non -visual access;  and 
d) where the user explicitly selects a speech language that is  different from the language of the 
displayed  content.  
6.1.3.15  Non-visual error  identification  
 
Where speech output is provided as non -visual access to closed functionality and an input error is 
automatically detected, speech output shall identify and describe the  item that is in error.  
 
6.1.3.16  Receipts, tickets, and transactional  outputs  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  15  
  
Where ICT is closed to visual access and provides receipts, tickets  or other outputs as a result of a self - 
service transaction, speech output shall be provided which shall include all information necessary to complete 
or verify the transaction.  
 
In the case of ticketing machines, printed copies of itineraries and maps sh all not be required to be audible.  
 
NOTE: The speech output may be provided by any element of the total ICT system.  
 
6.1.4  Functionality closed to text  enlargement  
 
Where any functionality of ICT is closed to the text enlargement features of platform or assisti ve technology, 
the ICT shall provide a mode of operation where the text and images of text necessary for all functionality is 
displayed in such a way that a non -accented capital "H" subtends an angle of at least 0.7 degrees at a viewing 
distance specified by the supplier.  
 
The subtended angle, in degrees, may be calculated from:  
 
Ψ = (180 x H) / (π x D)  
 
Where:  
 
ψ is the subtended angle in degrees 
H is the height of the  text 
D is the viewing  distance  
 
D and H are expressed in the same units  
 
NOTE 1: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.  
 
NOTE 2: Table 1 and Figure 1 illustrate the relationship between the maximum viewing distance and minimum character 
height at the specified minim um subtended angle.  
 
Table 1 ― Relationship between maximum design viewing distance and minimum character height at 
the limit of subtended angle  
 
Minimum subtended angle  Maximum  design  viewing 
distance  
(mm)  Minimum  character 
height  
(mm)  
 
 
 
 
 
 
 
0.7 degrees  100 1.2 
200 2.4 
250 3.1 
300 3.7 
350 4.3 
400 4.9 
450 5.5 
500 6.1 
550 6.7 
600 7.3 16 © KEBS:2021: – All rights reserved   
 
 
 
 
 
 
 
 
 
 
 
 
 
 
      
 
 
 
 
 
 
 
 
 
 
Figure 1 ― Relationship between minimum character height and maximum design viewing distance  
 
6.1.5  Visual output for auditory  information  
 
Where auditory information is needed to enable the use of closed  functions of ICT, the ICT shall provide visual 
information that is equivalent to the auditory output.  
 
NOTE: This visual information can take the form of captions or text transcripts.  
 
6.1.6  Operation without keyboard  interface  
 
6.1.6.1  Closed  functionality  
 
Where ICT functionality is closed to keyboards or keyboard interfaces, all functionality shall be operable 
without vision as required in 6.1.3.  
 
6.1.6.2  Input focus  
 
Where ICT functionality is closed to keyboards or keyboard interfaces and where input focus can be  moved to 
a user interface element, it shall be possible to move the input focus away from that element using the same 
mechanism, in order to avoid trapping the input focus.  
 
6.1.7  Access without  speech  
 
Where speech is needed to operate closed functions of ICT,  the ICT shall provide at least one mode of 
operation using an alternative input mechanism that does not require speech.  
 
6.2 Activation of accessibility  features  
 
Where ICT has documented accessibility features, it shall be possible to activate those document ed 
accessibility features that are required to meet a specific need without relying on a method that does not 
support that need.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  17  
  
6.3 Biometrics  
 
Where ICT uses biological characteristics, it shall not rely on the use of a particular biological characteristic as 
the only means of user identification or for control of ICT.  
 
NOTE 1: Alternative means of user identification or for control of ICT could be non -biometric or biometric.  
 
NOTE 2: Biometric methods based on dissimilar biological  characteristics increase the likelihood that individuals with 
disabilities possess at least one of the specified biological characteristics. Examples of dissimilar biological characterist ics 
are fingerprints, eye retinal patterns, voice, and face.  
 
6.4 Prese rvation of accessibility information during  conversion  
 
Where ICT converts information or communication, it shall preserve all documented non -proprietary 
information that is provided for accessibility, to the extent that such information can be contained i n or 
supported by the destination format.  
 
6.5 Operable  parts  
 
6.5.1  Means of  operation  
 
Where ICT has operable parts that require grasping, pinching, or twisting of the wrist to operate, an accessible 
alternative means of operation that does not require these actions shall be provided.  
 
NOTE: One -handed operation, sequential key entry, speech user interfaces and eye control may contribute towards 
compliance with this clause.  
 
6.5.2  Operable parts  discernibility  
 
Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision 
and without performing the action associated with the operable part.  
 
NOTE: Ways of complying with this requirement include but not limited to by making the operable parts tactilely 
discernible, use o f tactics or  vibrations.  
 
6.6 Locking or toggle  controls  
 
6.6.1  Tactile or auditory  status  
 
Where ICT has a locking or toggle control and the status of that control is visually presented to the user, the 
ICT shall provide at least one mode of operation where the status of the control can be determined either 
through touch or sound without operating the  control.  
 
NOTE 1: Locking or toggle controls are those controls that can only have two or three states and that keep their state 
while being  used.  
 
NOTE 2: An example of a locking or toggle control is the "Caps Lock" key found on most keyboards. Another example is 
the volume button on a pay telephone, which can be set at normal, loud, or extra loud volume.  
 
6.6.2  Visual  status  
 
Where ICT has a locking or toggle contro l and the status of the control is non -visually presented to the user, 
the ICT shall provide at least one mode of operation where the status of the control can be visually determined 
when the control is presented.  18 © KEBS:2021: – All rights reserved   
 NOTE 1: Locking or toggle controls are those controls that can only have two or three states and that keep their state 
while being  used.  
 
NOTE 2: An example of a locking or toggle control is the "Caps Lock" key found on most keyboards. An example of 
making the status of a control determinable is a visual status indicator on a  keyboard.  
 
6.7 Key repeat  
 
Where ICT has a key repeat function that cannot be turned off:  
 
a) the delay before the key repeat shall be adjustable to at least two seconds;  and 
b) the key repeat rate shall be adjustable down to one character per two  seconds.  
6.8 Double -strike key  acceptance  
 
Where ICT has a keyboard or keypad, the de lay after any keystroke during which an additional key -press will 
not be accepted if it is identical to the previous keystroke, shall be adjustable up to at least 0.5 seconds.  
 
6.9 Simultaneous user  actions  
 
Where ICT has a mode of operation requiring simultaneous user actions for its operation, such ICT shall 
provide at least one mode of operation that does not require simultaneous user actions to operate the ICT.  
 
NOTE:  Having to use both hands to open the lid of a laptop, having to press two or more  keys at the same time or   
having to touch a surface with more than one finger are examples of simultaneous user  actions.  
 
7 ICT with two -way voice  communication  
7.1 Audio bandwidth for  speech  
 
Where ICT provides two -way voice communication, in order to provide  good audio quality, the ICT shall be 
able to encode and decode two -way voice communication with a frequency range with an upper limit of at 
least 7000  Hz. 
 
NOTE 1: For the purposes of interoperability, support of Recommendation ITU -T G.722 is widely used.  
 
NOTE 2: Where codec negotiation is implemented, other standardized codecs such as Recommendation ITU -T.G.722.2 
are sometimes used so as to avoid transcoding.  
 
7.2 Real -Time Text (RTT)  functionality  
 
7.2.1  RTT provision  
 
7.2.1.1  RTT communication  
 
Where ICT is in a mode  that provides a means for two -way voice communication, the ICT shall provide a 
means for two -way RTT communication, except where this would require design changes to add input or 
output hardware to the ICT.  
 
 
 
NOTE 1: This requirement includes those produ cts which do not have physical display or text entry capabilities but have 
the capability to connect to devices that do have such capabilities. It also includes intermediate ICT between the endpoints 
of the communication.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  19  
  
NOTE 2: There is no requirement to add: a hardware display, a hardware keyboard, or hardware to support the ability to 
connect to a display or keyboard, wired or wirelessly, if this hardware would not normally be provided.  
 
NOTE 3: For the purposes of interoperability, support of Recommendation ITU -T T.140 is widely used.  
 
NOTE 4 :This is to enable the recipient to read the message as it is being written, and respond in real -time 
simultaneously.  
 
7.2.1.2  Concurrent voice and  text 
 
Where ICT provides a means for two -way voice co mmunication and for users to communicate by RTT, it shall 
allow concurrent voice and text through a single user connection.  
 
NOTE 1: With many -party communication, as in a conference system, it is allowed (but not required or necessarily 
recommended) that RTT be handled in a single display field and that "turn -taking" be necessary to avoid confusion (in the 
same way that turn -taking is required for those presenting/talking with voice).  
 
NOTE 2: With many -party communication, best practice is for hand -raisin g for voice users and RTT users to be handled in 
the same way, so that voice and RTT users are in the same queue.  
 
NOTE 3: With a many -party conference system that has chat as one of its features - the RTT (like the voice) would 
typically be separate from the chat so that RTT use does not interfere with chat (i.e. people can be messaging in the chat 
field while the person is presenting/talking with RTT - in the same manner that people message using the chat feature 
while people are talking with voice). RTT users would then use RTT for presenting and use the chat feature to message 
while others are presenting (via voice or  RTT).  
 
NOTE 4: The availability of voice and RTT running concurrently (and separately from chat) can also allow the RTT field to 
support text captioning when someone is speaking (and it is therefore not being used for RTT since it is not the RTT user's 
turn to speak).  
 
NOTE 5: Where both server -side software and local hardware and software are required to provide voice communication, 
where neither part can support voice communication without the other and are sold as a unit for the voice communication 
function, the local and server -side components are considered a single product.  
 
7.2.2  Display of  RTT 
 
7.2.2.1  Visually distinguishable  display  
 
Where ICT has RTT send and receive capabilities, displayed sent text shall be visually differentiated from, and 
separated from, received text.  
 
NOTE:  The ability of the user to choose between having the send and receive text be displayed in -line or separa tely,   
and with options to select, allows users to display RTT in a form that works best for them. This would allow Braille users to  
use a single field and take turns and have text appear in the sequential way that they may need or  prefer.  
 
7.2.2.2  Programmatical ly determinable send and receive  direction  
 
Where ICT has RTT send and receive capabilities, the send/receive direction of transmitted/received text shall 
be programmatically determinable, unless the RTT is implemented as closed functionality.  
 
NOTE: This enables screen readers to distinguish between incoming text and outgoing text when used with RTT 
functionality.  
 
7.2.2.3  Speaker  identification  
 
Where ICT has RTT capabilities, and provides speaker identification for voice, the ICT shall provide speaker 
identifica tion for RTT.  20 © KEBS:2021: – All rights reserved   
 NOTE:       This is necessary to enable both voice and RTT participants to know who is currently communicating, whether 
it be in RTT or  voice.  
 
7.2.2.4  Visual indicator of audio with  RTT 
 
Where ICT provides two -way voice communication, and has RTT capabilities, the ICT shall provide a real -time 
visual indicator of audio activity on the display.  
 
NOTE 1: The visual indicator may be a simple character position on the display that flickers on and off to reflect audio 
activity, or presentation of the information in another way that can be both visible to sighted users and passed on to deaf - 
blind use rs who are using a braille display.  
 
NOTE 2: Without this indication, a person who lacks the ability to hear does not know when someone is talking.  
 
7.2.3  Interoperability  
 
Where ICT with RTT functionality interoperates with other ICT with RTT functionality (as required by clause 
7.2.1.1) they shall support the applicable RTT interoperability mechanisms described below:  
 
a) ICT interoperating with other ICT directly connected to the Public Switched Telephone Network (PSTN), 
using Recommendation ITU -T V.18 or any of its annexes for text telephony signals at the  PSTN interface;  
b) ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using RTT that 
conforms to IETF RFC 4103. For ICT interoperating with other ICT using the IP Multimedia Su b-System 
(IMS) to implement VOIP, the set of protocols specified in ETSI TS 126 114, ETSI TS 122 173 and ETSI 
TS 134 229 describe how IETF RFC 4103 would  apply;  
c) ICT interoperating with other ICT using technologies other than a) or b), above, using a releva nt and 
applicable common specification for RTT exchange that is published and available for the environments 
in which they will be operating. This common specification shall include a method for indicating loss or 
corruption of characters;  and 
d) ICT interope rating with other ICT using a standard for RTT that has been introduced for use in any of the 
above environments, and is supported by all of the other active ICT that support voice and RTT in that 
environment.  
NOTE 1: In practice, new standards are introduced as an alternative codec/protocol that is supported alongside the 
existing common standard and used when all end -to-end components support it while technology development, combined 
with other reasons including societal development and cost effici ency, may make others become obsolete.  
 
NOTE 2: Where multiple technologies are used to provide voice communication, multiple interoperability mechanisms may 
be needed to ensure that all users are able to use RTT.  
 
EXAMPLE:   A conferencing system that supports voice communication through an internet connection might provide   
RTT over an internet connection using a proprietary RTT method (option c). However, regardless of whether the RTT 
method is proprietary or non -proprietary, if the conferencing system also offers telephony communication it will also need 
to support options a) or b) to ensure that RTT is supported over the telephony  connection.  
 
7.2.4  RTT responsiveness  
 
Where ICT utilises RTT input, that RTT input shall be transmitted to the ICT network or platform on which the 
ICT runs within 500 ms of the time that the smallest reliably composed unit of text entry is available to the ICT 
for transmission. Delays due to platform or network performance shall not be includ ed in the 500 ms limit.  
 
NOTE 1: For character by character input, the "smallest reliably composed unit of text entry" would be a character. For 
word prediction it would be a word. For some voice recognition systems - the text may not exit the recognition software 
until an entire word (or phrase) has been spoken. In this case, the smallest reliably composed unit of text entry available t o 
the ICT would be the word (or  phrase).  
 
NOTE 2: The 500 ms limit allows buffering of characters for this period before t ransmission so character by character 
transmission is not required unless the characters are generated more slowly than 1 per 500 ms.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  21  
  
NOTE 3: A delay of 300 ms, or less, produces a better impression of flow to the user.  
 
7.3 Caller  ID 
 
Where ICT provides caller identification or similar telecommunications functions, the caller identification and 
similar telecommunications functions shall be available in text form as well as being programmatically 
determinable, unless the functionality is  closed.  
 
7.4 Alternatives to access voice -based  services  
 
Where ICT provides real -time voice -based communication and also provides voice mail, auto -attendant, or 
interactive voice response facilities, the ICT shall offer users a means to access the informati on and carry out 
the tasks provided by the ICT without the use of hearing or speech.  
 
NOTE 1: Tasks that involve both operating the interface and perceiving the information would require that both the 
interface and information be accessible without use of speech or hearing.  
 
NOTE 2: Solutions capable of handling audio, RTT and video media could comply with the above requirement.  
 
7.5 Video  communication  
 
7.5.1  General  
 
7.5.1.1  This clause provides performance requirements that support users who communicate using sign 
language and lip -reading. For these users, good usability is achieved with a resolution of at least Quarter 
Video Graphics Array (QVGA, 320 x 240), a frame rate of 20 frames per second and over, with a time 
difference between speech audio and video that do es not exceed 100  ms. 
 
7.5.1.2  Increasing the resolution and frame rate further improves both sign language and lip -reading, with 
frame rate being more important than  resolution.  
 
7.5.1.3  Time differences between audio and video (asynchronicity) can have a great impact on  lip- 
reading - with video that lags behind audio having greater negative  effect.  
 
7.5.1.4  End-to-end latency can be a problem in video (sign) communication. Overall delay values below 
400 ms are preferred, with an increase in preference down to 100 ms. Overall de lay depends on multiple 
factors, including e.g. network delay and video processing. For this reason, a testable requirement on 
minimum values for overall delay cannot be  produced.  
 
NOTE: Recommendation ITU -T F.703 defines and gives requirements for Total  Conversation that  relate to the  
integration of audio, RTT and video in a single user  connection.  
 
7.5.2  Resolution  
 
Where ICT that provides two -way voice communication includes real -time video functionality, the ICT:  
 
a) shall support at least QVGA resolution;  and 
b) should preferably support at least VGA  resolution.  
7.5.3  Frame  rate 
 
Where ICT that provides two -way voice communication includes real -time video functionality, the ICT:  
 
a) shall support a frame rate of at least 20 Frames Per Second (FPS);  and 22 © KEBS:2021: – All rights reserved   
 b) should preferably support a frame rate of at least 30 Frames Per Second (FPS) with or without sign 
language in the video  stream.  
7.5.4  Synchronization between audio and  video  
 
Where ICT that provides two -way voice communication includes real -time video functionality, the ICT shall 
ensure a maximum time difference of 100 ms between the speech and video presented to the user.  
 
7.5.5  Visual indicator of audio with  video  
 
Where ICT provides two -way voice communication, and includes real -time video functionality, the ICT shall 
provide a real -time visual indicator of audio activity.  
 
NOTE 1: The visual indicator may be a simple visual d ot or LED, or other type of on/off indicator, that flickers to reflect 
audio activity.  
 
NOTE 2: Without this indication a person who lacks the ability to hear does not know when someone is talking.  
 
7.5.6  Speaker identification with video (sign language)  communication  
 
Where ICT provides speaker identification for voice users, it shall provide a means for speaker identification 
for real - time signing and sign language users once the start of signing has been  indicated.  
 
NOTE 1: The speaker ID can be in the  same location as for voice users for multiparty calls.  
 
NOTE 2: This mechanism might be triggered manually by a user, or automatically where this is technically achievable.  
 
7.6 Alternatives to access video -based  services  
 
Where ICT provides real -time video -based communication and also provides answering machine, auto 
attendant or interactive response facilities, the ICT should offer users a means to access the information and 
carry out the tasks related to the following facilities:  
 
a) for audible information, w ithout the use of  hearing;  
b) for spoken commands, without the use of  speech;  
c) for visual information, without the use of vision:  and 
d) For signing information, without use of speech /hearing  . 
NOTE: Solutions capable of generating real -time captions or handling  RTT could comply with the above requirement.  
 
8 ICT with video  capabilities  
8.1 Caption processing  technology  
 
8.1.1  Captioning  playback  
 
Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available 
captions. Where clos ed captions are provided as part of the content, the ICT shall allow the user to choose to 
display the captions.  
 
NOTE 1: Captions may contain information about timing, colour and positioning. This caption data is necessary for caption 
users. Timing is use d for caption synchronization. Colour can be used for speaker identification. Position can be used to 
avoid obscuring important information.  
 
NOTE 2: If a Braille device is connected, the ICT should provide an option to display captions on the Braille device.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  23  
  
NOTE 3: This clause refers to the ability of the player to display captions. Clauses 10.2.2.2, 11.2.2.2 and 12.2.2.2 refer to  
the provision of captions for the content (the video).  
 
8.1.2  Captioning  synchronization  
 
Where ICT displays  captions, the mechanism to display captions shall preserve synchronization between the 
audio and the corresponding captions as follows:  
 
a) Captions in recorded material: within 100 ms of the time stamp of the  caption.  
b) Live captions: within 100 ms of the ava ilability of the caption to the  player.  
8.1.3  Preservation of  captioning  
 
Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such 
that it can be displayed in a manner consistent with 8.1.1 and 8.1.2.  
 
8.1.4  Captions  characteristics  
 
Where ICT displays captions, it shall provide a way for the user to adapt the displayed characteristics of 
captions to their individual requirements, except where the captions are displayed as unmodifiable characters.  
 
NOTE 1: Defining th e background and foreground colour of subtitles, font type, size opacity of the background box of 
subtitles, and the contour or border of the fonts can contribute to compliance with this requirement.  
 
NOTE 2: Subtitles that are bitmap images are examples o f unmodifiable characters.  
 
8.1.5  Spoken  subtitles  
 
Where ICT displays video with synchronized audio, it shall have a mode of operation to provide a spoken 
output of the available captions, except where the content of the displayed captions is not programmatical ly 
determinable.  
 
NOTE 1: Being able to manage speech output range for spoken subtitles independently from general ICT speech is 
preferable for most users. That is possible when the audio file with spoken subtitle is delivered in a separ ate audio track 
and mixed in the end users device.  
 
NOTE 2: Presenting the separate audio track with spoken subtitles in synchronization with the displayed subtitles/captions 
improves understandability of the subtitles.  
 
NOTE 3: Providing subtitles/caption s as separate text -streams, facilitates converting the respective texts into audio.  
 
NOTE 4: Subtitles that are bitmap images are examples where the content of the displayed captions will not be 
programmatically determinable.  
 
8.2 Audio description  technology  
 
8.2.1  Audio description  playback  
 
Where ICT displays video with synchronized audio, it shall provide a mechanism to select and play available 
audio description to the default audio channel.  
 
Where video technologies do not have explicit and separate mechanisms for audio description, an ICT is 
deemed to comply with this requirement if the ICT enables the user to select and play several audio tracks.  
 
NOTE 1: In such cases, the video content can include the audio description as one of the available audio tracks.  24 © KEBS:2021: – All rights reserved   
 NOTE 2: Audio descriptions in digital media sometimes include information to allow descriptions that are longer than the 
gaps between dialogue. Support in digital media players for this "extended audio description" feature is useful, especially 
for digital media that is viewed personally.  
 
8.2.2  Audio description  synchronization  
 
Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the 
audio/visual content and the corresponding audio description.  
 
8.2.3  Preservation of audio  description  
 
Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description 
data such that it can be played in a manner consistent with 8.2.1 and 8.2.2.  
 
8.3 User controls for captions and audio  description  
 
Where ICT primarily displays materials containing video with associated audio content, user con trols to 
activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the 
number of steps to complete the task) as the primary media controls.  
 
NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.  
 
NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured 
to display video through software but which is not its primary purpose, would not need ded icated hardware controls for 
captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at 
the same level of interaction.  
 
NOTE 3: It is recommended for ICT to include additional controls enabling t he user to select whether captions and audio 
description are turned on or off by default.  
 
9 Hardware  
9.1 General  
 
9.1.1  Generic  requirements  
 
The generic requirements of clause 6 also apply to ICT that is hardware.  
 
9.1.2  Standard  connections  
 
Where an ICT provides user input or output device connection points, the ICT shall provide at least one input 
and/or output connection that conforms to an industry standard non -proprietary format, directly or through the 
use of commercially available adapters.  
 
NOTE 1: The intent of  this requirement is to ensure compatibility with assistive technologies by requiring the use of 
standard connections on ICT.  
 
NOTE 2: The word connection applies to both physical and wireless connections.  
 
NOTE 3: Current examples of industry standard non -proprietary formats are USB and Bluetooth.  
 
9.1.3  Colour  
 
Where the ICT has hardware aspects that use colour, colour shall not be used as the only visual means of 
conveying information, indicating an action, prompting a response, or distinguishing a visual elem ent. DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  25  
  
9.2 Hardware products with speech  output  
 
9.2.1  Speech volume  gain 
 
9.2.1.1  Speech volume  range  
 
Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level 
over a range of at least 18 dBA but should not exceed 85 dBA.  
 
NOTE: Fixed -line handsets and headsets fulfilling the requirements of ANSI/TIA -4965 are deemed to comply with this 
requirement.  
 
 
 
9.2.1.2  Incremental volume  control  
 
Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one 
intermediate step of 12 dBA gain above the lowest volume setting.  
 
9.2.2  Magnetic  coupling  
 
9.2.2.1  Fixed -line devices  
 
Where ICT hardware is a fixed -line communication device with speech output and which is normally held to 
the ear, it shall provide a means of magnetic coupling which meets the requirements of ETSI ES 200 381 -1 
and shall carry the "T" symbol specified in ETSI ETS 300  381. 
 
NOTE 1: ICT fulfilling the requirements of TIA -1083 -A is deemed to comply with the requirements of this cl ause. 
NOTE 2: Magnetic coupling is also known as inductive coupling for T -coil. 
9.2.2.2  Wireless communication  devices  
 
Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, 
it shall provide a means of magnetic  coupling to hearing technologies which meets the requirements of ETSI 
ES 200 381 -2. 
 
NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.  
 
9.3 Stationary  ICT 
 
9.3.1  General  
 
This clause defines the dimensions for accessing stationary ICT that can be placed in a built environment, but 
does not define the dimensions of the built environment in general.  
 
The scope includes stationary ICT, of which floors and circulation spaces ar e "an integral part", and where 
there are external reach ranges relevant for operating the stationary ICT.  
 
Clauses 9.3.3 to 9.3.5 specify mandatory limits for the maximum and minimum height of operable parts and 
displays. Based on dimensions shown in Figu re 53 of KS ISO 21542, it is recommended that the possible 
height range is reduced to:  
 
a) minimum and maximum heights of operable parts: 800 mm and 1 100 mm respectively,  and 26 © KEBS:2021: – All rights reserved   
 
b) minimum and maximum heights of displays: 1 200 mm and 1 400 mm  respectively.  
9.3.2  Forward or side  reach  
 
Stationary ICT shall comply with either clause 9.3.3 or clause 9.3.4.  
 
NOTE 1: This does not preclude conforming to both clauses.  
 
NOTE 2: Physical access to stationary ICT is dependent on the dimensions of both the ICT and the environment in which 
it is installed  and operated.  Clause  9.3 does  not apply  to the accessibility  of the physical  environment  external  to the ICT. 
 
9.3.3  Forward  reach  
 
9.3.3.1  Unobstructed high forward  reach  
 
Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part 
shall not be located higher than 1 220 mm above the fl oor of the access space. (See Figure 2).  
 
9.3.3.2  Unobstructed low forward  reach  
 
Where no part of the  stationary ICT obstructs the forward reach, at least one of each type of operable part 
shall not be located lower than 380 mm above the floor of the access space. (See Figure 2).  
 
 
 
 
 
 
 
 
 
 
 
 
Figure 2 ― Unobstructed forward reach  
 
9.3.3.3  Obstructed forward  reach  
 
9.3.3.3.1  Clear  space  
 
Where an obstruction is an integral part of the stationary ICT and hinders the access to any type of operable 
part, the ICT shall provide a clear space which extends beneath the obstructing element for a distance not 
less than the required reach depth over the  obstruction.  
 
NOTE:     Ensuring that there will be unhindered "access to any type of operable part" guarantees that a user will be     
able to access at least one of each type of operable  part. 
 
9.3.3.3.2  Obstructed (< 510 mm) forward  reach  
 
Where the stationary ICT has an obstruction which is an integral part of the ICT and which is less than 510 
mm the forward reach to at least one of each type of operable part shall not be higher than 1 220 mm above 
the floor contact of the ICT. (See Figure 3  (a)). 
 
9.3.3.3.3  Obstructed (< 635 mm) forward  reach  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  27  
 
 
Where the stationary ICT has an obstruction which is an integral part of the ICT and which is not less than 510 
mm but is less than 635 mm maximum, the forward reach to at least one of eac h type of operable part shall be 
no higher than 1 120 mm above the floor contact of the ICT. (See Figure 3 (b)).  
 
 
 
 
 
 
 
 
 
 
 
 
Figure 3a) and 3b) ― Obstructed forward reach  
 
9.3.3.4  Knee and toe clearance  width  
 
Where the space under an obstacle that is an integral part of the stationary ICT is part of access space, the 
clearance shall be at least 760 mm wide.  
 
9.3.3.5  Toe clearance  
 
Where an obstacle is an integral part of the stationary ICT, a space under the obstacle that is less than 230 
mm above the floor is considered toe clearance and shall:  
 
a) extend 635 mm maximum under the whole  obstacle;  
b) provide a space at least 430 mm deep and 230 mm above the floor under the obstacle;  and 
c) extend not more than 150 mm beyond any obstruction at 230 mm above the floor. (See Figure  4) 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figure 4 ― Toe clearance  
 
9.3.3.6  Knee  clearance  
 
Where an obstacle is an integral part of the stationary ICT, the space under the obstacle that is between 230 
mm and 685 mm above the floor is considered knee clearance and shall:  
 
a) extend not more than 635 mm under the obstacle at a height of 230 mm above the  floor;  
b) extend at least 280 mm under the obstacle at a height of 230 mm above the  floor;  
c) extend at least 205 mm under the obstacle at a height of 685 mm above the floor;  and 28 © KEBS:2021: – All rights reserved   
 
d) be permitted to be reduced in depth at a rate of 25 mm for each 150 mm in height. (See Figure  5.) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figure 5 ― Knee clearance  
 
9.3.4  Side  reach  
 
9.3.4.1  Unobstructed high side  reach  
 
Where the side reach is unobstructed or obstructed by an element that is an integral part of the stationary ICT 
and which is less than 255 mm at least one of each type of operable part shall be within a high side reach 
which is less than or equal to 1 220 mm above the floor of the access space. (See Figure 6).  
 
9.3.4.2  Unobstructed low side  reach  
 
Where the side reach is unobstructed or obstructed by an element that is an integral part of the stationary ICT 
and which is less than 255 mm at least one of each type of operable part shall be within a low side reach 
which is greater than or equal to 380 mm above the floor of the access space. (See Figure  6). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figure 6 ― Unobstructed side reach  
 
9.3.4.3  Obstructed side  reach  
 
9.3.4.3.1  Obstructed (≤ 255 mm) side  reach  
 
Where stationary ICT has an obstruction which is an integral part of the ICT, the height of the obstruction shall 
be less than 865 mm Where the depth of the obstruction is less than or equal to 255 mm the high side reach 
to at least one of each type of operable part shall not be higher than 1 220 mm above the floor of the access 
space. (See Figur e 7 (a)). 
 
9.3.4.3.2  Obstructed (≤ 610 mm) side  reach  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  29  
 
 
Where stationary ICT has an obstruction which is an integral part of the ICT, the height of the obstruction shall 
be less than 865 mm Where the depth of the obstruction is greater than 255 mm with a maximum depth of 
610 mm the high side reach to at least one of each type of operable part shall not be higher than 1 170 mm 
above the floor of the access space. (See Figure 7  (b)). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figure 7a) and 7b) ― Obstructed high side reach  
 
9.3.5  Clear floor or ground  space  
 
9.3.5.1  Change in  level  
 
Where stationary ICT has a floor within it, then any change of floor level within it or entering it shall be ramped 
with a slope not steeper than 1:48.  
 
Exceptions:  
 
a) If the change in floor level is less than or equal to 6.4 mm the change may be vertical as shown in Figure 
8. 
 
b) If the change in floor level is less than or equal to 13 mm the change may have a slope not steeper than 
1:2 as shown in Figure  9. 
 
 
 
 
 
 
Figure 8 ― Vertical change in level  
 
 
 
 
 
 
 
 
Figure 9 ― Bevelled change in level  
 
 
9.3.5.2  Level ground  space  30 © KEBS:2021: – All rights reserved   
 
Where stationary ICT has an operating area within it, it shall provide a clear floor area that has the minimum 
dimensions of 760 mm by 1 220 mm from which to operate the ICT. (See Figure 10).  
 
 
 
 
 
 
 
 
 
 
Figure 10 ― Level ground space  
 
9.3.5.3  Approach  
 
9.3.5.3.1  General  
 
Where stationary ICT has an access space inside it, at least one full side of the space shall be unobstructed.  
 
9.3.5.3.2  Forward  approach  
 
Where the operating area is inside an alcove within the stationary ICT, the alcove is deeper than 610 mm, and 
where a forward approach is necessary, the dimensio n of the access space shall be a minimum of 915 mm 
wide. (See Figure 11).  
 
 
 
 
 
 
 
 
 
 
 
Figure 11 ― Manoeuvring clearance in an Alcove, Forward Approach  
 
9.3.5.3.3  Parallel  approach  
 
Where the operating area is inside an alcove within the stationary ICT, the alcove is deeper than 380 mm, and 
where a parallel approach is possible, the dimension of the access space shall be a minimum of 1 525 mm 
wide. (See Figure 12).  
 
 
 
 
Figure 12 ― Manoeuvring clearance in an alcove, Parallel Approach  
DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  31  
  
9.3.6  Visibility  
 
Where stationary ICT provides one or more display screens, at least one of each type of display screen shall 
be positioned such that the information on the screen is legible from a point located 1 015 mm above the 
centre of the floor of the operating area.  
 
NOTE:  The intent of this requirement is that the information on the screen can be read by users with normal vision 
and appropriate language skills, when seated in a  wheelchair.  
 
9.3.7  Installation  instructions  
 
Installation instructions shall be made availabl e for all stationary ICT. These instructions shall give guidance 
on how to install the ICT in a manner that takes into account applicable requirements for accessibility of the 
built environment as they apply to the installation of the ICT. Where there are no such requirements the 
instructions shall require that the dimensions of the installed ICT comply with clauses 9.3.3 to  9.3.6.  
 
9.4 Mechanically operable  parts  
 
9.4.1  Numeric  keys  
 
Where provided, physical numeric keys arranged in a rectangular keypad layout shall  have the number five 
key tactilely distinct from the other keys of the keypad.  
 
NOTE:  Recommendation ITU -T E.161 describes the 12 -key telephone keypad layout and provides further details of 
the form of tactile  markers.  
 
9.4.2  Operation of mechanical  parts  
 
9.4.2.1  Mean s of operation of mechanical  parts  
 
Where a control requires grasping, pinching, or twisting of the wrist to operate it, an accessible alternative 
means of operation that does not require these actions shall be  provided.  
 
9.4.2.2  Force of operation of mechanical  parts  
 
Where a control requires a force greater than 22.2 N to operate it, an accessible alternative means of 
operation that requires a force less than 22.2 N shall be provided.  
 
NOTE: KS ISO 21542, recommends a value between 2.5 and 5 Newtons.  
 
9.4.3  Keys, tickets and fare  cards  
 
Where ICT provides keys, tickets or fare cards, and their orientation is important for further use, they shall 
have an orientation that is tactilely discernible and with text in a familiar language .  
 
NOTE:  ETSI ETS 300 767, Human F actors (HF); Requirements for relay services defines suitable tactile indications 
for plastic  cards.  
 
9.5 Tactile indication of speech  mode  
 
Where ICT is designed for shared use and speech output is available, a tactile indication of the means to 
initiate the speech mode of operation shall be provided.  
 
NOTE: The tactile indication could include Braille instructions.  32 © KEBS:2021: – All rights reserved   
 10 Web  
10.1 General  
 
Requirements in clause 10 apply to web pages (as defined in clause 3) including:  
 
a) Conformance with W3C Web Content Accessibility Guidelines (WCAG 2.0) Level AA is equivalent to 
conforming with clauses 10.2.1, 10.2.2, 10.2.3.1 to 10.2.3.3, 10.2.4.1 to 10.2.4.5, 10.3.1.1, 10.3.1.2, 
10.3.2, 10.3.3, 10.3.4, 10.4, 10.5.1.1, 10.5.1.2 and the conformance requirements of clause 10.7 of 
this standard.  
b) Conformance with W3C Web Content Accessibility Guidelines (WCAG 2.1) Level A A is equivalent to 
conforming with all of clauses 10.2 to 10.5 and the conformance requirements of clause 10.7 of this 
standard.  
c) Requirements for non -web documents and non -web software are given in clauses 11 and 12 
respectively.  
NOTE 1: When evaluating we bsites they are evaluated as individual web pages. Web applications, including mobile web 
applications, are covered under the definition of web page which is quite broad and covers all web content types.  
 
NOTE 2: WCAG 2.0 is identical to ISO/IEC 40500:2012 : "Information technology - W3C Web Content Accessibility 
Guidelines (WCAG) 2.0"  
 
The requirements in clauses 10.2 to 10.5 are written using the concept of complying with success criteria 
(defined in clause 3). A web page satisfies a WCAG success criterion  when the success criterion does not 
evaluate to false when applied to the web page. This implies that if the success criterion puts conditions on a 
specific feature and that specific feature does not occur in the web page, then the web page satisfies the 
success criterion.  
 
NOTE 3: For example, a web page that does not contain pre -recorded audio content in synchronized media will 
automatically comply with WCAG success criterion 1.2.2 (captions - pre-recorded) and, in consequence, will also conform 
to 10.2. 2.2. 
 
In addition to Level AA success criteria, the Web Content Accessibility Guidelines also include success criteria 
for Level AAA. These are listed in 10.6 of this standard. Web authors and procurement accessibility specialists 
should consider whether a ny of the WCAG Level AAA success criteria offer suggestions that may be 
applicable and relevant to their project, as well as potentially beneficial to some users.  
 
NOTE 4: The W3C states that "It is not recommended that Level AAA conformance be required as  a general policy for 
entire sites because it is not possible to comply with all Level AAA Success Criteria for some content".  
 
10.2 Perceivable  
 
10.2.1  Text alternatives  
 
10.2.1.1  Non-text content  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 1.1.1, Non -text content.  
 
10.2.2  Time -based  media  
 
10.2.2.1  Audio -only and video -only (pre-recorded)  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion, 1.2.1, Audio -only and Video -only 
(Pre-recorded).  
 
10.2.2.2  Captions  (pre-recorded)  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  33  
  
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion, 1.2.2, Captions (Pre -recorded).  
 
10.2.2.3  Audio description or media alternative  (pre-recorded)  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.2.3, Audio Descri ption or Media 
Alternative (Pre -recorded).  
 
10.2.2.4  Captions  (live)  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.2.4, Captions (Live).  
 
10.2.2.5  Audio description  (pre-recorded)  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.2.5 Audio Description (Pre - 
recorded).  
 
10.2.3  Adaptable  
 
10.2.3.1  Info and  relationships  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.3.1, Info and Relationships.  
 
10.2.3.2  Meaningful  sequence  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.3.2, Meaningful Sequence.  
 
10.2.3.3  Sensory  characteristics  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.3.3, Sensory Characteristics.  
 
10.2.3.4  Orientation  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.3.4, Orientation.  
 
10.2.3.5  Identify input  purpose  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.3.5, Identify Input Purpose.  
 
10.2.4  Distinguishable  
 
10.2.4.1  Use of  colour  
 
Where ICT is a web page, it shall comply  with WCAG 2.1, Success Criterion 1.4.1 Use of Colour.  
 
10.2.4.2  Audio  control  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.4.2 Audio Control.  
 
10.2.4.3  Contrast  (minimum)  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.4.3 Contrast (Minimum).  34 © KEBS:2021: – All rights reserved   
 10.2.4.4  Resize  text 
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.4.4 Resize text.  
 
10.2.4.5  Images of  text 
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 1.4.5 Images of Text.  
 
10.2.4.6  Reflow  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 1.4.10 Reflow.  
 
10.2.4.7  Non-text contrast  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 1.4.11 Non -text Contrast.  
 
10.2.4.8  Text spacing  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 1.4.12 Text spacing.  
 
10.2.4.9  Content on hover or  focus  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 1.4.13 Content on Hover or 
Focus.  
 
10.3 Operable  
 
10.3.1  Keyboard  accessible  
 
10.3.1.1  Keyboard  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.1.1 Keyboard.  
 
10.3.1.2  No keyboard  trap 
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.1.2 No Keyboard Trap.  
 
10.3.1.3  Character key  shortcuts  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.  
 
10.3.2  Enough  time 
 
10.3.2.1  Timing  adjustable  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable.  
 
10.3.2.2  Pause, stop,  hide 
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.2.2 Pause, Stop, Hide.  
 
10.3.3  Seizures and physical  reactions  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  35  
  
10.3.3.1  Three flashes or below  threshold  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.3.1, Three Flashes or Below 
Threshold.  
 
10.3.4  Navigable  
 
10.3.4.1  Bypass  blocks  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.4.1 Bypass Blocks.  
 
10.3.4.2  Page  titled  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.4.2 Page Titled.  
 
10.3.4.3  Focus  Order  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.4.3 Focus Order.  
 
10.3.4.4  Link purpose (in  context)  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.4.4 Link Purpose (In Context).  
 
10.3.4.5  Multiple  ways  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.4.5 Multiple Ways . 
 
10.3.4.6  Headings and  labels  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.4.6 Headings and Labels.  
 
10.3.4.7  Focus  visible  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.4.7 Focus Visible.  
 
10.3.5  Input  modalities  
 
10.3.5.1  Pointer  gestures  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.5.1 Pointer Gestures.  
 
10.3.5.2  Pointer  cancellation  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.5.2 Pointer Cancellation.  
 
10.3.5.3  Label in  name  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 2.5.3 Label in Name.  
 
10.3.5.4  Motion  actuation  36 © KEBS:2021: – All rights reserved   
 Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 2.5.4, Motion Actuation.  
 
10.4 Understandable  
 
10.4.1  Readable  
 
10.4.1.1  Language of  page  
 
Where ICT is a web page, it shall comply with WCAG 2.1 Success Criterion 3.1.1, Language of Page.  
 
10.4.1.2  Language of  parts  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.1.2, Language of Parts.  
 
10.4.2  Predictable  
 
10.4.2.1  On focus  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.2.1 On Focus.  
 
10.4.2.2  On input  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.2.2 On Input.  
 
10.4.2.3  Consistent  navigation  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.2.3 Consistent Navigation.  
 
10.4.2.4  Consistent  identification  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.2.4 Consistent Identification.  
 
10.4.3  Input  assistance  
 
10.4.3.1  Error  identification  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.3.1 Error Identification.  
 
10.4.3.2  Label s or instructions  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.3.2 Labels or Instructions.  
 
10.4.3.3  Error  suggestion  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.3.3 Error Suggestion.  
 
10.4.3.4  Error prevention (legal, financial,  data)  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 3.3.4 Error Prevention (Legal, 
Financial, Data).  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  37  
  
10.5 Robust  
 
10.5.1  Compatible  
 
10.5.1.1  Parsing  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 4.1.1 Parsing.  
 
10.5.1.2  Name, role,  value  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 4.1.2 Name, Role, Value.  
 
10.5.1.3  Status  messages  
 
Where ICT is a web page, it shall comply with WCAG 2.1, Success Criterion 4.1.3 Status Messages.  
 
10.6 WCAG 2.1, AAA Success  Criteria  
 
In addition to the Level AA success criteria, included in clauses 10.2 to 10.5, the Web Content Accessibility 
Guidelines include success criteria for Level AAA. These are listed in Table 2. Web author s and procurement 
accessibility specialists should consider the WCAG 2.1 Level AAA success criteria that, when it is possible to 
apply them, may provide access beyond that required in this standard.  
 
NOTE: The W3C states that "It is not recommended that Level AAA conformance be required as a general policy for  
entire sites because it is not possible to comply with all Level AAA Success Criteria for some  content"  38 © KEBS:2021: – All rights reserved   
 Table 2 ― WCAG 2.1 Level AAA Success Criteria  
 
No. Guideline  Success 
Criterion 
Number  Success Criteria Name  
1 Time -based media  1.2.6  Sign Language (Prerecorded)  
2 Time -based media  1.2.7  Extended Audio Description (Prerecorded)  
3 Time -based media  1.2.8  Media Alternative (Prerecorded)  
4 Time -based media  1.2.9  Audio -only (Live)  
5 Adaptable  1.3.6  Identify Purpose  
6 Distinguishable  1.4.6  Contrast (Enhanced)  
7 Distinguishable  1.4.7  Low or No Background Audio  
8 Distinguishable  1.4.8  Visual Presentation  
9 Distinguishable  1.4.9  Images of Text (No Exception)  
10 Keyboard Accessible  2.1.3  Keyboard (No Exception)  
11 Enough time  2.2.3  No Timing  
12 Enough time  2.2.4  Interruptions  
13 Enough time  2.2.5  Re-authenticating  
14 Enough time  2.2.6  Timeouts  
15 Seizures and physical reactions  2.3.2  Three Flashes  
16 Seizures and physical reactions  2.3.3  Animation form Interactions  
17 Navigable  2.4.8  Location  
18 Navigable  2.4.9  Link Purpose (Link Only)  
19 Navigable  2.4.10  Section Headings  
20 Input  modalities  2.5.5  Target Size  
21 Input modalities  2.5.6  Concurrent Input Mechanisms  
22 Readable  3.1.3  Unusual Words  
23 Readable  3.1.4  Abbreviations  
24 Readable  3.1.5  Reading Level  
25 Readable  3.1.6  Pronunciation  
26 Predictable  3.2.5  Change on Request  
27 Input assistance  3.3.5  Help 
28 Input assistance  3.3.6  Error Prevention (All)  
 
 
10.7 WCAG conformance  requirements  
 
Where ICT is a web page, it shall comply with all the following five WCAG 2.1 conformance requirements at 
Level AA.  
 
a) conformance  level;  
b) full pages;  
c) complete  processes;  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  39  
  
d) only accessibility -supported ways of using technologies;  and 
e) non-interference.  
NOTE 1: A Web page that meets all the requirements given in 10.2 to 10.5, or where a Level AA conforming alternate 
version (a s defined in WCAG 2.1) is provided, will meet conformance requirement (a) above.  
 
NOTE 2: According to W3C: "WCAG 2.1 extends Web Content Accessibility Guidelines 2.0 which was published as a 
W3C Recommendation December 2008. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0, and therefore 
to policies that reference WCAG  2.0" 
 
NOTE 3: Conformance requirement (e) above states that all content on the page, including content that is not otherwise 
relied upon to meet conformance, meets clauses 10.2.4 .2, 10.3.1.2, 10.3.2.2 and 10.3.3.1.  
 
11 Non-web documents  
11.1 General  
 
11.1.1  Requirements in this clause 11 apply  to: 
 
a) documents that are not web  pages;  
b) documents that are not embedded in web pages;  and 
c) documents that are provided with web pages but are neither embedded nor rendered together with 
the web page from which they are provided (i.e. clause 11 applies to downloadable  documents).  
11.1.2  Clause 10 provides requirements for documents that are in web pages or that are embedded in web 
pages and that are used in the  rendering or that are intended to be rendered together with the web page in 
which they are  embedded.  
 
NOTE 1: Some examples of non -web documents are letters, spreadsheets, emails, books, pictures, presentations, and 
movies that have an associated user agent such as a document reader, editor or media player.  
 
NOTE 2: A single document may be composed of mul tiple files such as the video content and closed caption text. This  
fact is not usually apparent to the end -user consuming the  document/content.  
 
NOTE 3: Documents require a user agent in order for the content to be presented to users. The requirements fo r user 
agents can be found in clause 12.  
 
NOTE 4: The requirements for content that is part of software, can be found in clause 12.  
 
NOTE 5: Requirements in this clause also apply to documents that are protected using mechanisms such as digital 
signatures,  encryption, password protection, and watermarks when they are presented to the user.  
 
11.2 Perceivable  
 
11.2.1  Text alternatives  
 
11.2.1.1  Non-text content  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.1.1, Non -text 
Content.  
 
NOTE:  CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is  accurate.  
 
11.2.2  Time -based  media  
 
11.2.2.1  Audio -only and video -only (pre-recorded)  40 © KEBS:2021: – All rights reserved   
 Where ICT is a non -web document, it shall comply with WCAG 2.1, Success Criterion 1.2.1, Audio -only and 
Video -only (Pre -recorded).  
 
NOTE: The alternative can be provided directly in t he document - or provided in an alternate version that meets the 
success criterion.  
 
11.2.2.2  Captions  (pre-recorded)  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.2.2 Captions (Pre - 
recorded).  
 
NOTE:  Per the definition in WCAG  2.1,  to meet this success criterion,  the captions have to provide "synchronized  
visual and / or text alternative for both speech and non -speech audio information needed to understand the media content" 
where non -speech information includes "sou nd effects, music, laughter, speaker identification and  location".  
 
11.2.2.3  Audio description or media alternative  (pre-recorded)  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.2.3, Audio 
Description or Media Alternative ( Pre-recorded).  
 
NOTE 1: The WCAG 2.1 definition of "audio description" says that "audio description" is "Also called 'video description' 
and 'descriptive  narration'".  
 
NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.  
 
11.2.2.4  Caption s (live)  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.2.4, Captions 
(Live).  
 
NOTE:   The WCAG 2.1 definition of "captions" notes that "in some countries, captions are called subtitles". They are   
also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2.1, to meet this success 
criterion, whether called captions or subtitles, they would have to provide "synchronized visual and / or text alternative fo r 
both speech and non -speech audio information needed to understand the media content" where non -speech information 
includes "sound effects, music, laughter, speaker identification and  location".  
 
11.2.2.5  Audio description  (pre-recorded)  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.2.5, Audio 
Description (Pre -recorded).  
 
NOTE 1: The WCAG 2.1 definition of "audio description" says that audio description is "Also called 'video description' and 
'descriptive narration'".  
 
NOTE 2: Secondary or altern ate audio tracks are commonly used for this purpose.  
 
11.2.3  Adaptable  
 
11.2.3.1  Info and  relationships  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.3.1, Info and 
Relationships.  
 
NOTE: Where documents contain non -standard structure types (roles), it is best practice to map them to a standard 
structure type as a fall -back solution for the reader.  
 
11.2.3.2  Meaningful  sequence  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  41  
 If any audio in a document plays automatically for more than 3 seconds, either a mechanism is available to pause 
or stop the audio, or a mechanism is available to control audio volume independently from the overall system 
volume  level.   
Where ICT is a non -web document, it shall comp ly with the WCAG 2.1, Success Criterion 1.3.2, Meaningful 
Sequence.  
 
11.2.3.3  Sensory  characteristics  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.3.3, Sensory 
Characteristics.  
 
11.2.3.4  Orientation  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.3.4, Orientation.  
 
11.2.3.5  Identify input  purpose  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.3.5, Identify Input 
Purpose.  
 
11.2.4  Distinguishable  
 
11.2.4.1  Use of  colour  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.4.1, Use of 
Colour.  
 
11.2.4.2  Audio  control  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 3.  
 
Table 3 ― Document success criterion: Audio control  
 
NOTE 1: Since any part of a document that does not meet this success criterion can interfere with a user's ability 
to use the whole document, all content in the document (whether or not it is used to meet other success 
criteria) shall meet this success criterion.  
NOTE 2: This success criterion is identical to the WCAG 2.1, Success Criterion 1.4.2, Audio Control replacing "on a 
Web page" with "in a document", "any content" with "any part of a document", "whole page" with "whole 
document", "on the Web page" with "in the document", removing "See Conformance Requirement 
10.7.(e): Non -Interference" and adding Note 1.  
 
 
11.2.4.3  Contrast  (minimum)  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.4.3, Contrast 
(Minimum).  
 
11.2.4.4  Resize  text 
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.4.4, Resize Text.  
 
NOTE 1: Content for which there are software players, viewers or editors with a 200 % zoom feature would automatically 
meet this success criterion when used with such players, unless the content will not work with zoom.  
 
NOTE 2: This success criterion is about the ability to allow users to enlarge the text on screen at least up to 200 % without  
needing to use assistive technologies. This me ans that the application provides some means for enlarging the text 200 %  42 © KEBS:2021: – All rights reserved   
 (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that 
meet this  requirement.  
 
NOTE 3: It is recommended to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). Thi s 
applies in particular to embedded fonts.  
 
11.2.4.5  Images of  text 
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 1.4.5, Images of 
Text.  
 
11.2.4.6  Reflow  
 
Where ICT is a non -web document, it shall comply with the success criterion given  in Table 4.  
 
Table 4 ― Document success criterion: Reflow  
 
Content can be presented without loss of information or functionality, and without requiring scrolling in two 
dimensions for:  
 Vertical scrolling content at a width equivalent to 320 CSS  pixels.  
 Horizontal scrolling content at a height equivalent to 256 CSS  pixels.  
Except for parts of the content which require two -dimensional layout for usage or meaning.  
NOTE 1: 320 CSS pixels is equivalent to a starting viewport width of 1 280 CSS pixels wide at 400 % zoom. For  
documents which are designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is 
equivalent to a starting viewport height of 1 024 pixels at 400 % zoom.  
NOTE 2: Examples of content which require two -dimensional layout are images, maps, diagrams, video, games, 
presentations, data tables, and interfaces where it is necessary to keep toolbars in view while 
manipulating content.  
NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow rep lacing the original 
WCAG 2.1 notes with notes 1 and 2, above.  
 
 
11.2.4.7  Non-text contrast  
 
Where ICT is a non -web document, it shall comply with WCAG 2.1, Success Criterion 1.4.11, Non -text 
Contrast.  
 
11.2.4.8  Text spacing  
 
Where ICT is a non -web document that does not have a fixed size content layout area that is essential to the 
information being conveyed, it shall comply with WCAG 2.1, Success Criterion 1.4.12, Text spacing.  
 
11.2.4.9  Content on hover or  focus  
 
Where ICT is a non -web document, it shall comply with WCAG 2.1, Su ccess Criterion 1.4.13, Content on 
Hover or Focus.  
 
11.3 Operable  
 
11.3.1  Keyboard  accessible  
 
11.3.1.1  Keyboard  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 2.1.1, Keyboard.  
 
11.3.1.2  No keyboard  trap DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  43  
 For each time limit that is set by the document, at least one of the following is true:  
 Turn off: The user is allowed to turn off the time limit before encountering it;  or 
 Adjust:  The user is allowed  to adjust  the time limit before  encountering  it over a wide range  that is at least 
ten times the length of the default setting;  or 
 Extend:  The user is warned  before  time expires  and given  at least  20 seconds  to extend  the time limit with 
a simple action (for example, "press the space bar"), and the user is a llowed to extend the time limit at 
least ten times;  or 
 Real -time Exception:  The time limit is a required  part of a real-time event  (for example,  an auction),  and 
no alternative to the time limit is possible;  or 
 Essential  Exception:  The time limit is essential  and extending  it would  invalidate  the activity;  or 
 20 Hour Exception: The time limit is longer than 20  hours.   
Where ICT is a non -web document, it shall comply with the success criterion in Table 5.  
 
Table 5: Document success criterion: No keyboard trap  
 
If keyboard focus can be moved to a component of the document using a keyboard interface, then focus can be  
moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or 
tab keys or other standard exit methods, the user is advised of the method for moving focus away.  
NOTE 1: Since any part of a document that does not meet this suc cess criterion can interfere with a user's ability  
to use the whole document, it is necessary for all content in the document (whether or not it is used to 
meet other success criteria) to meet this success criterion.  
NOTE 2: Standard exit methods may vary  by platform. For example, on many desktop platforms, the Escape key 
is a standard method for exiting.  
NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 2.1.2 No Keyboard Trap replacing 
"page" and "Web page" with "document", re moving "See Conformance Requirement 10.7.(e): Non - 
Interference" and with the addition of note 2 above and with note 1 above re -drafted to avoid the use of  
the word "must".  
 
 
11.3.1.3  Character key  shortcuts  
 
Where ICT is a non -web document, it shall comply with WCAG 2.1, Success Criterion 2.1.4, Character Key 
Shortcuts.  
 
11.3.2  Enough  time 
 
11.3.2.1  Timing  adjustable  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 6.  
 
Table 6 ― Document success criterion: Timing adjustable  
 
NOTE 1: This success criterion helps ensure that users can complete tasks without unexpected changes in 
content or context that are a result of a time limit. This success criterion should be considered in 
conjunction with WCAG 2.1 Success Criterion 3.2.1, which puts limits on changes of content or context 
as a result of user action.  
NOTE 2: This success criterion is identical to the WCAG  2.1, Success Criterion 2.2.1 Timing Adjustable replacing 
"the content" with "documents" and with the words "WCAG 2.1" added before the word "Success 
Criterion" in note 1 above.  
 
 
11.3.2.2  Pause, stop,  hide 
 
Where ICT is a non -web document, it shall comply with the  success criterion given in Table 7.  Table 7: Document success criterion: Pause, stop, hide  
44 © KEBS:2021: – All rights reserved   
  
For moving, blinking, scrolling, or auto -updating information, all of the following are true:  
 Moving,  blinking,  scrolling:  For any moving,  blinking  or scrolling  information  that (1) starts  automatically,  
(2) lasts more than five seconds, and (3) is present ed in parallel with other content, there is a mechanism 
for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where 
it is essential; and  
 Auto -updating:  For any auto-updating  information  that (1) starts  automatically  and (2) is presented  in 
parallel  with other  content,  there  is a mechanism  for the user to pause,  stop,  or hide it or to control  the 
frequency of the update unless the auto -updating is part of an activity where it is essential.  
NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.1 Guideline 2.3.  
NOTE 2: Since any part of a document that does not meet this success criterion can interfere with a user's ability to use the  whole 
document, it is necessary for all c ontent in the document (whether it is used to meet other success criteria or not) to meet this 
success criterion.  
NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or  present 
informat ion that is generated or received between the initiation of the pause and resuming presentation, as this may not be 
technically possible, and in many situations could be misleading to do so.  
 
NOTE 4: An animation that occurs as part of a preload phase or s imilar situation can be considered essential if interaction cannot 
occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was 
frozen or broken.  
NOTE 5: This success criterion is identica l to the WCAG 2.1 Success Criterion 2.2.2 Pause, Stop, Hide replacing "page" and "Web 
page" with "document", removing "See Conformance Requirement 10.7.(e): Non -Interference" in note 2 of the success criterion, 
with the words "WCAG 2.1" added before the wo rd "Guideline" in note 1 above and with note 2 above re -drafted to avoid the use of 
the word  "must".  
 
 
11.3.3  Seizures and physical  reactions  
 
11.3.3.1  Three flashes or below  threshold  
 
Where ICT is a non -web document, it shall  comply with the success criterion given in Table  8. 
 
Table 8: Document success criterion: Three flashes or below  threshold  
 
Documents do not contain anything that flashes more than three times in any one second period, or the flash is 
below the general flash and red flash thresholds.  
NOTE 1: Since any part of a document that does not meet this success criterion can interfere with a user's ability to use the  whole 
document, it is necessary for all content in the document (whether it is used to meet other  success criteria or not) to meet this 
success criterion.  
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.3.1 Three Flashes or Below Threshold replacin g 
"Web pages" with "documents", "the whole page" with "the whole document ", "the Web page" with "the document" and removing 
"See Conformance Requirement 10.7.(e): Non -Interference" and with note 1 above re -drafted to avoid the use of the word "must".  
 
 
11.3.4  Navigable  
 
11.3.4.1  Document  titled  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 9.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  45  
  
 
 
Table 9: Document success criterion: Document titled  
 
Documents have titles that describe topic or purpose.  
NOTE 1: The name of a document (e.g. document, media file) is a sufficient  title if it describes the topic or purpose.  
 
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.4.2 Page Titled replacing "Web pages" with 
"documents" and with the addition of note 1  above.  
 
 
11.3.4.2  Focus  order  
 
Where ICT is a non-web document, it shall comply with the success criterion given in Table 10.  
 
Table 10: Document success criterion: Focus order  
 
If a document can be navigated sequentially and the navigation sequences affect meaning or operation, focusable 
components r eceive focus in an order that preserves meaning and operability.  
NOTE:  This success criterion is identical to the WCAG 2.1 Success Criterion 2.4.3 Focus Order replacing "Web page" with 
"document".  
 
 
11.3.4.3  Link purpose (in  context)  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 2.4.4, Link Purpose 
(In Context).  
 
11.3.4.4  Headings and  labels  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 2.4.6, Headings and 
Labels.  
 
11.3.4.5  Focus  visible  
 
Where I CT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 2.4.7, Focus Visible.  
 
11.3.5  Input  modalities  
 
11.3.5.1  Pointer  gestures  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 11.  
 
Table 11: Document success criterion: Pointer gestures  
 
All functionality that uses multipoint or path -based gestures for operation can be operated with a single pointer  
without a path -based gesture, unless a multipoint or path -based gesture is essential.  
NOTE 1: This requi rement applies to documents that interpret pointer actions (i.e. this does not apply to actions that are required to 
operate the user agent or assistive  technology).  
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointe r Gestures replacing the original  WCAG  
2.1 note with note 1 above.  
 
 
11.3.5.2  Pointer  cancellation  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 12.  Table 12: Document success criterion: Pointer  cancellation  
46 © KEBS:2021: – All rights reserved   
  
For functionality that can be operated using a single pointer, at least one of the following is true:  
 No Down -Event: The down -event of the pointer is not used to execute any part of the  function;  
 Abort  or Undo:  Completion  of the function  is on the up-event,  and a mechanism  is available  to abort  the 
function before completion or to undo the function after  completion;  
 Up Reversal: The up -event reverses any outcome of the preceding  down -event;  
 Essential: Completing the function on the down -event is  essential.  
NOTE 1: Functions that emulate a keyboard o r numeric keypad key press are considered essential.  
NOTE 2: This requirement applies to a document that interprets pointer actions (i.e. this does not apply to actions that are required 
to operate the user agent or assistive  technology).  
NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original 
WCAG 2.1 note with notes 1 and 2  above.  
 
 
11.3.5.3  Label in  name  
 
Where ICT is a non -web document, it shall comply with WCAG 2.1, Success Criterion 2.5.3, Label in Name.  
 
11.3.5.4  Motion  actuation  
 
Where ICT is a non -web document, it shall comply with WCAG 2.1, Success Criterion 2.5.4, Motion Actuation.  
 
11.4 Understandable  
 
11.4.1  Readable  
 
11.4.1.1  Language of  document  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 13.  
 
Table 13: Document success criterion: Language of document  
 
The default human language of each document can be programmatically determined.  
NOTE:  This success criterion is identical to the WCAG 2.1, Success Criterion 3.1.1, Language of Page replacing "web page" 
with "document".  
 
 
11.4.1.2  Language of  parts  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 14.  
 
Table 14: Document success criterion: Language of parts  
 
The human language of each passage or phrase in the document can be programmatically determined except for 
proper names, technical terms, words of indeterminate language, and words or phrases that have become part of 
the vernacular of the immediately surro unding text.  
NOTE 1: There are some document technologies where there is no assistive technology supported method for marking the 
language for the different passages or phrases in the document, and it would not be possible to meet this success criterion w ith 
those  technologies.  
NOTE 2: Inheritance is one common method. For example a document provides the language that it is using and it can be assumed  
that all of the text or user interface elements within that document will be using the same language unles s it is indicated.  
 
NOTE 3: This success criterion is identical to the WCAG 2.1, Success Criterion 3.1.2, Language of Parts replacing 
"content" with "document" and with the addition of notes 1 and 2 above.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  47  
  
11.4.2  Predictable  
 
11.4.2.1  On focus  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 3.2.1, On Focus.  
 
NOTE: Some compound documents and their user agents are designed to provide significantly different viewing and 
editing functionality depending upon wh at portion of the compound document is being interacted with (e.g. a presentation 
that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon 
whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a 
mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a 
menu choice or special keyboard gesture), any resulting change of context would no t be subject to this success criterion 
because it was not caused by a change of focus.  
 
11.4.2.2  On input  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 3.2.2, On Input.  
 
11.4.3  Input  assistance  
 
11.4.3.1  Error  identification  
 
Where ICT is a  non-web document, it shall comply with the WCAG 2.1, Success Criterion 3.3.1, Error 
Identification.  
 
11.4.3.2  Labels or  instructions  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 3.3.2, Labels or 
Instructions.  
 
11.4.3.3  Error  suggestion  
 
Where ICT is a non -web document, it shall comply with the WCAG 2.1, Success Criterion 3.3.3, Error 
Suggestion.  
 
11.4.3.4  Error prevention (legal, financial,  data)  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Tabl e 15.  
 
Table 15: Document success criterion: Error prevention (legal, financial, data)  
 
For documents that cause legal commitments or financial transactions for the user to occur, that modify or delete 
user-controllable data in data storage systems, or tha t submit user test responses, at least one of the following is 
true: 
1) Reversible: Submissions are  reversible.  
2) Checked:  Data  entered  by the user is checked  for input  errors  and the user is provided  an opportunity  to correct 
them.  
3) Confirmed:  A mechanism  is available  for reviewing,  confirming,  and correcting  information  before  finalizing  the 
submission.  
NOTE:  This success criterion is identical to the WCAG 2.1, Success Criterion 3.3.4, Error Prevention (Legal, Financial, Data) 
replacing "web pages" with  "documents".  
 
 
11.5 Robust  
 
11.5.1  Compatible  48 © KEBS:2021: – All rights reserved   
 11.5.1.1  Parsing  
 
Where ICT is a non -web document, it shall comply with the success criterion given in Table 16.  
 
 
 
Table 16: Document success criterion: Parsing  
 
For documents that use markup languages, in such  a way that the markup is separately exposed and available to 
assistive technologies and accessibility features of software or to a user -selectable user agent, elements have  
complete start and end tags, elements are nested according to their specifications , elements do not contain 
duplicate attributes, and any IDs are unique, except where the specifications allow these features.  
NOTE 1: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket 
or a mismatc hed attribute value quotation mark are not complete.  
NOTE 2: Markup is not always available to assistive technology or to user selectable user agents such as browsers. In such ca ses, 
conformance  to this [requirement] would  have  no impact  on accessibility  as it can for web content  where  it is exposed.  
NOTE 3: Examples of markup that is separately exposed and available to assistive technologies and to user agents include but are 
not limited  to: documents  encoded  in HTML,  ODF,  and OOXML.  In these  examples,  the markup  can be parsed  entirely  in two ways:  
a) by assistive technologies which may directly open the  document,  
b) by assistive technologies using DOM APIs of user agents for these document  formats.  
NOTE 4: This success criterion is identical to the WCAG 2.1 Success Criterion 4.1.1 Parsing replacing "In content implemented 
using markup languages" with "For documents that use markup languages, in such a way that the markup is separately exposed 
and available to assistive technologies and accessibility features of software or to a user -selectable user agent" with the addition of 
notes 2 and 3  above.  
11.5.1.2  Name, role,  value  
 
Where ICT is a non -web document, it shall comply with the success criterion in given Table 17.  
 
Table 17: Document success criterion: Name, role,  value  
 
For all user interface components (including but not limited to: form elements, links and components generated by 
scripts), the name and role can be programmatically determined; states, properties, and values that can be set by  
the user can be prog rammatically set; and notification of changes to these items is available to user agents, 
including assistive technologies.  
NOTE 1: This success criterion is primarily for software developers who develop or use custom user interface components. 
Standard user interface components on most accessibility -supported platforms already meet this success criterion when used 
according to  specification.  
NOTE 2: For document formats that support interoperability with assistive technology, standard user interface com ponents often 
meet  this success  criterion  when  used  according  to the general  design  and accessibility  guidance  for the document  format.  
NOTE 3: This success criterion is identical to the WCAG 2.1, Success Criterion 4.1.2, Name, Role, Value replacing the original 
WCAG 2.1 note with: "This success criterion is primarily for software developers who develop or use custom user interface 
components. For example, standard user interface components on most accessibility -supported platforms already meet this 
succe ss criterion when used according to specification." and with the addition of note 2  above.  
 
 
11.5.1.3  Status  messages  
 
Where ICT is a non -web document, it shall comply with WCAG 2.1, Success Criterion 4.1.3, Status 
Messages.  
 
11.6 Caption  positioning  
 
Where ICT is a non-web document that contains synchronized media with captions, the captions should not 
obscure relevant information in the synchronized media.  © KEBS 2021 – All rights reserved  49 DKS 2952 -1: 2021   
  
11.7 Audio description  timing  
 
Where ICT is a non -web document that contains synchronized media with audio description, the audio 
description should not interfere with relevant audio information in the synchronized media.  
 
12 Software  
12.1 General  
 
This clause provides requirements for:  
 
a) platform  software;  
b) software that provides a user interface including content that is in the  software;  
c) authoring  tools;  
d) software that operates as assistive technology;  and 
e) mobile  applications.  
NOTE 1: User agents are examples of software that provide a user interface. They retrieve, render and facilitate end user 
interaction with authored content. User agents play a necessary role in the accessibility of authored content rendered in 
the user interface. UAAG 2.0 provides additional advice for those who are creating user agents and want to increase 
functionality when rendering authored content in an accessible  way. 
 
NOTE 2: The requirements for Web content, including software that is Web content, can be found i n clause 10. 
NOTE 3: The requirements for documents, that may be presented by user agents, can be found in clause 11.  
NOTE 4: Although the accessibility of command line interfaces is not dealt with in this standard, accessibility may be 
achieved by context  specific requirements, some of which may be found in clauses 6 or 12.  
 
Requirements in clauses 12.2 to 12.6 apply to software:  
 
a) that is not a web  page;  
b) not embedded in web pages nor used in the rendering or functioning of the  page.  
Clause 10 provides requirements for software that is in web pages or that is embedded in web pages and that 
is used in the rendering or that is intended to be rendered together with the web page in which it is embedded.  
 
Some requirements in clauses 12.2 to 12.6 have different versions for open or closed functionality. In those 
cases, the corresponding clause will be divided into two subclauses.  
 
NOTE 5: Software that provides a user interface includes its own content. Some examples of content in software include: 
the controls and text displayed in a menu bar of a graphical user interface application, images that appear in a toolbar, 
prompts spoken in an auditory user interface, other user interaction controls, and other text, graphics or material that is n ot 
loaded fro m outside the  software.  
 
12.2 Perceivable  
 
12.2.1  Text alternatives  
 
12.2.1.1  Non-text content  
 
12.2.1.1.1  Non-text content (open  functionality)  50 © KEBS:2021: – All rights reserved   
 Where ICT is non -web software that provides a user interface and that supports access to assistive 
technologies for screen reading, it shall comply with WCAG 2.1, Success Criterion 1.1.1, Non -text Content.  
 
NOTE: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is 
accurate.  
 
12.2.1.1.2  Non-text content (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to assistive technologies for 
screen reading, it shall meet requirement given in 6.1.3.6 (Speech output for non -text content).  
 
12.2.2  Time -based  media  
 
12.2.2.1  Audio -only and v ideo-only (pre-recorded)  
 
12.2.2.1.1  Audio -only and video -only (pre -recorded - open  functionality)  
 
Where ICT is non -web software that provides a user interface and that supports access to assistive 
technologies for screen reading and where pre -recorded auditory information is not needed to enable the use 
of closed functions of ICT, it shall comply with the WCAG 2.1, Success Criterion 1.2.1, Audio -only and Video - 
only (Pre -recorded).  
 
NOTE: The alternative can be provided directly in the software - or provided in  an alternate version that meets the 
success  criterion.  
 
12.2.2.1.2  Audio -only and video -only (pre -recor ded - closed functionality) 
12.2.2.1.2.1  Pre-recorded audio -only (closed  functionality)  
Where ICT is non -web software that provides a user interface which is closed to assistive technologies for 
screen reading and where pre -recorded auditory information is  needed to enable the use of closed functions 
of ICT, the functionality of software that provides a user interface shall meet the requirement given in 6.1.5 
(Visual output for auditory  information).  
 
12.2.2.1.2.2 Pre -recorded video -only (closed functionali ty) 
 
Where ICT is non -web software that provides a user interface which is closed to assistive technologies for 
screen reading, it shall meet requirement given in 6.1.3.7 (Speech output for video information)  
 
12.2.2.2  Captions  (pre-recorded)  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 1.2.2, Captions (Pre -recorded).  
 
NOTE:  . Per the definition in WCAG 2.1, to meet this success criterion,  the captions have to provide "synchronized  
visual and / or text alternative for both speech and non -speech audio information needed to understand the media content" 
where non -speech information includes "sound effects, music, laughter, speaker identification and  location".  
 
12.2.2.3  Audio description or media alternat ive (pre-recorded)  
 
12.2.2.3.1  Audio description or media alternative (pre -recorded - open  functionality)  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  51  
  
Where ICT is non -web software that provides a user interface and that supports access to assistive 
technologies for screen reading, it shall comply with the WCAG 2.1, Success Criterion 1.2.3, Audio 
Description or Media Alternative  (Pre-recorded).  
 
NOTE 1: The WCAG 2.1 definition of "audio description" says that "audio description" is "also called 'video description' 
and 'descriptive  narration'".  
 
NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.  
 
12.2.2.3.2  Audio description or media alternative (pre -recorded - closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to as sistive technologies for 
screen reading, it shall meet the requirement given in clause 6.1.3.7 (Speech output for video information).  
 
12.2.2.4  Captions  (live)  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success  
Criterion 1.2.4, Captions (Live).  
 
NOTE:  Per the definition in WCAG 2.1, to meet this success criterion, the captions   have to provide "synchronized   
visual and / or text alternative for both speech and non -speech audio information needed to understand  the media content" 
where non -speech information includes "sound effects, music, laughter, speaker identification and  location".  
 
12.2.2.5  Audio description  (pre-recorded)  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 1.2.5, Audio Description (Pre -recorded).  
 
NOTE 1: The WCAG 2.1 definition of "audio description" says that audio description is "Also called 'video description' and 
'descriptive narration'".  
 
NOTE 2: Secondary or alternate audio trac ks are commonly used for this purpose.  
 
12.2.3  Adaptable  
 
12.2.3.1  Info and  relationships  
 
12.2.3.1.1  Info and relationships (open  functionality)  
 
Where ICT is non -web software that provides a user interface and that supports access to assistive 
technologies for screen reading, it shall comply with the WCAG 2.1, Success Criterion 1.3.1, Info and 
Relationships.  
 
NOTE:     In software, programmatic determinability is best achieved through the use of accessibility services provided    
by platform software to enable interoperability bet ween software and assistive technologies and accessibility features of 
software. (see 12.6 Interoperability with assistive  technology).  
 
12.2.3.1.2  Info and relationships (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is cl osed to assistive technologies for 
screen reading and where information is displayed on the screen, the ICT should provide auditory information 
that allows the user to correlate the audio with the information displayed on the screen.  
 
NOTE 1An audio altern ative that is both complete and complementary includes all visual information such as focus or 
highlighting, so that the audio can be correlated with information that is visible on the screen at any point in time.  52 © KEBS:2021: – All rights reserved   
 NOTE: Examples of auditory information that allows the user to correlate the audio with the information displayed on the 
screen include stru cture and relationships conveyed through presentation.  
 
12.2.3.2  Meaningful  sequence  
 
12.2.3.2.1  Meaningful sequence (open  functionality)  
 
Where ICT is non -web software that provides a user interface and that supports access to assistive 
technologies for screen reading, it shall comply with the WCAG 2.1, Success Criterion 1.3.2, Meaningful 
Sequence.  
 
12.2.3.2.2  Meaningful sequence (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to assistive technologies for 
screen reading and where information is displayed on the screen, the ICT should provide auditory information 
that allows the user to correlate the audio with the information displayed on the screen.  
 
NOTE 1An audio alternative that is both complete and complementary includes all v isual information such as focus or 
highlighting, so that the audio can be correlated with information that is visible on the screen at any point in time.  
 
NOTE : Examples of auditory information that allows the user to correlate the audio with the informat ion displayed on the 
screen include structure and relationships conveyed through presentation.  
 
12.2.3.3  Sensory  characteristics  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 1.3.3, Sensory Chara cteristics.  
 
12.2.3.4  Orientation  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 1.3.4, Orientation.  
 
12.2.3.5  Identify input  purpose  
 
12.2.3.5.1  Identify input purpose (open  functionality)  
 
Where ICT is non -web software that provides a user interface and supports access to assistive technologies 
for screen reading, it shall comply with the WCAG 2.1, Success Criterion 1.3.5, Identify Input Purpose.  
 
12.2.3.5.2  Identify input purpose (closed  functionality ) 
 
Where ICT is non -web software that provides a user interface and is closed to assistive technologies, in at 
least one mode of operation the ICT shall present to the user, in an audio form, the purpose of each input field 
collecting information about the  user when the input field serves a purpose identified in the WCAG 2.1, Input 
Purposes for User Interface Components section.  
 
12.2.4  Distinguishable  
 
12.2.4.1  Use of  colour  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 1.4.1, Use of Colour.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  53  
  
12.2.4.2  Audio  control  
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion given 
in Table 18.  
 
Table 18: Software success criterion: Audio control  
 
If any audio in a software plays automatically for more than 3 seconds, either a mechanism is available to pause or  
stop the audio, or a mechanism is available to control audio volume independently from the overall system volume 
level.  
NOTE 1: Since any par t of a software that does not meet this success criterion can interfere with a user's ability to use the whole 
software,  all content  in the software  (whether  or not it is used  to meet  other  success  criteria)  shall meet  this success  criterion  
. 
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.2 Audio Control replacing "on a Web page" with 
"in a software", "any content" with "any part of a software ", "whole page" with "whole software", "on the Web page" with "in the 
software", removing "See Conformance Requirement 10.7(e): Non -Interference" and adding note 1.  
 
 
12.2.4.3  Contrast  (minimum)  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 1.4.3, Contrast (Minimum).  
 
12.2.4.4  Resize  text 
 
12.2.4.4.1  Resize text (open  functionality)  
 
Where ICT is non -web software that provides a user interface and that supports access to enlargement 
features of platform or assistive technology, it shall comply with the WCAG 2.1, Success Criterion 1.4.4, 
Resize Text.  
 
NOTE 1: Content for which there are software players, viewers or editors with a 200 % zoom feature would automatically 
meet this success criterion when used wit h such players, unless the content will not work with zoom.  
 
NOTE 2: This success criterion is about the ability to allow users to enlarge the text on screen at least up to 200 % without  
needing to use assistive technologies. This means that the applicatio n provides some means for enlarging the text 200 % 
(zoom or otherwise) without loss of content or functionality or that the application works with the platform features that 
meet this  requirement.  
 
12.2.4.4.2  Resize text (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is not able to access the enlargement 
features of platform or assistive technology, it shall meet the requirement given in 6.1.4 (Functionality closed 
to text  enlargement).  
 
NOTE:    Because the text rendering support in a closed environment may be more limited than the support found in    
user agents for the Web, meeting the requirements of this clause in a closed environment may place a much heavier 
burden on the content  author.  
 
12.2.4.5  Images of  text 
 
12.2.4.5.1  Images of text  (open  functionality)  
 
Where ICT is non -web software that provides a user interface and that supports access to assistive 
technologies for screen reading, it shall comply with the WCAG 2.1, Success Criterion 1.4.5, Images of Text.  54 © KEBS:2021: – All rights reserved   
 12.2.4.5.2  Images of text (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to assistive technologies for 
screen reading, it shall meet the requirement given in 6.1.3.6 (Speech output for non -text content).  
 
12.2.4.6  Reflow  
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion given 
in Table  19. 
 
Table 19: Software success criterion: Reflow  
 
Content can be presented without loss of information or functionality, and without requiring scrolling in two 
dimensions for:  
 Vertical scrolling content at a width equivalent to 320 CSS  pixels;  
 Horizonta l scrolling content at a height equivalent to 256 CSS  pixels;  
Except for parts of the content which require two -dimensional layout for usage or meaning.  
NOTE 1: 320 CSS pixels is equivalent to a starting viewport width of 1 280 CSS pixels wide at 400 % zoom. For non -web software 
which are designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is equivalent to a starting viewport height of 1 
024 px at 400 % zoom.  
NOTE 2: Examples of content which require two -dimensional layout are images, maps, diagrams, video, games, presentations, data 
tables, and interfaces where it is necessary to keep toolbars in view while manipulating  content.  
NOTE 3: This success criterion is identical to the WCAG 2.1, Success Criterion 1.4.10, Reflow replacing the original WCAG 2.1 
notes with notes 1 and 2,  above.  
 
 
12.2.4.7  Non-text contrast  
 
Where ICT is non -web software that provides a user interface, it shall comply with WCAG 2.1, Success 
Criterion 1.4.11, Non - text Contrast.  
 
12.2.4.8  Text spacing  
 
Where ICT is non -web software that provides a user interface and that does not have a fixed size content 
layout area that is essential to the information being conveyed, it shall comply with WCAG 2.1, Su ccess 
Criterion 1.4.12, Text spacing.  
 
12.2.4.9  Content on hover or  focus  
 
Where ICT is a non -web software that provides a user interface, it shall comply with WCAG 2.1, Success 
Criterion 1.4.13, Content on hover or focus.  
 
12.3 Operable  
 
12.3.1  Keyboard  accessible  
 
12.3.1.1  Keyboard  
 
12.3.1.1.1  Keyboard (open  functionality)  
 
Where ICT is non -web software that provides a user interface and that supports access to keyboards or a 
keyboard interface, it shall comply with the WCAG 2.1, Success Criterion 2.1.1, Keyboard.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  55  
  
NOTE: This does not imply that software is required to directly support a keyboard or "keyboard interface". Nor does it 
imply that software is required to provide a soft keyboard. Underlying platform software may provide device independent 
input services to applicati ons that enable operation via a keyboard. Software that supports operation via such platform 
device independent services would be operable by a keyboard and would comply.  
 
12.3.1.1.2  Keyboard (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to keyboards or keyboard 
interface, it shall meet the requirement given in 6.1.6.1 (Operation without keyboard interface: Closed 
functionality).  
 
12.3.1.2  No keyboard  trap 
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion given 
in Table 20.  
 
Table 20: Software success criterion: No keyboard trap  
 
If keyboard focus can be moved to a component of the software using a keyboard interface, then focus can be  
moved away from that component u sing only a keyboard interface, and, if it requires more than unmodified arrow or 
tab keys or other standard exit methods, the user is advised of the method for moving focus away.  
NOTE 1: Since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole 
software, it is necessary for all content in the software (whether or not it is used to meet other success criteria) to meet this success 
criterion.  
NOTE 2: Standard exit methods may vary by p latform. For example, on many desktop platforms, the Escape key is a standard 
method for  exiting.  
NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 2.1.2 No Keyboard Trap replacing "content", "page" 
and "Web page" with "software", removing "See Conformance Requirement 10.7 (e) : Non - Interference" and with the addition of 
note 2 above and with note 1 above  re-drafted to avoid the use of the word "must".  
 
 
12.3.1.4  Character key  shortcuts  
 
12.3.1.4.1  Character key shortcuts (open  functionality)  
 
Where ICT is non -web software that provides a user interface, it shall comply with WCAG 2.1, Success 
Criterion 2.1.4, Character Key Shortcuts.  
 
12.3.1.4.2  Character key shortcuts (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to keyboards or keyboard 
interface, it shall meet requirement 6.1.6.1 (Operation without keyboard interface: Closed fun ctionality).  
 
12.3.2  Enough  time 
 
12.3.2.1  Timing  adjustable  
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion given 
in Table 21.  56 © KEBS:2021: – All rights reserved   
 Table 21: Software success criterion: Timing adjustable  
 
For each time limit that is set by the software, at least one of the following is true:  
 Turn off: The user is allowed to turn off the time limit before encountering it;  or 
 Adjust:  The user is allowed  to adjust  the time limit before  encountering  it over a wide range  that is at least 
ten times the length of the default setting;  or 
 Extend:  The user is warned  before  time expires  and given  at least  20 seconds  to extend  the time limit with 
a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at 
least ten times;  or 
 Real -time Exception:  The time limit is a required  part of a real-time event  (for example,  an auction),  and 
no alternative to the time limit is possible;  or 
 Essential  Exception:  The time limit is essential  and extending  it would  invalidate  the activity;  or 
 20 Hour Exception: The time limit is longer than 20  hours.  
NOTE 1: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that 
are a result of a time limit. This success criterion should be considered in conjunction with WCAG 2.1 Success Criterion 3.2. 1, which 
puts limits on changes of content or context as a result of user action.  
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable replacing "the content" with 
"software" and with the words "WCAG 2.1" added before the word "Success Criterion" in note 1  above.  
 
 
12.3.2.2  Pause, stop,  hide 
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion in 
given Table 22.  
 
Table 22: Software success criterion: Pause, stop, hide  
 
For moving, blinking, scrolling, or auto -updating information, all of the following are true:  
 
a) Moving, blinking, scrolling: For any moving, blinking or scrolling information  that 
i) starts  automatically,  
 
ii) lasts more than five seconds,  and 
 
iii) is presented in parallel with other content, there is a mechanism for the user to pause, stop, 
or hide it unless t he movement, blinking, or scrolling is part of an activity where it is essential; 
and 
 
b) Auto -updating: For any auto -updating information  that 
i) starts automatically  and 
ii) is presented in parallel with other content, there is a mechanism for the user to pause, stop, 
or hide it or to controlthe frequency of the update unless the auto -updating is part of an activity 
where it is  essential.  
NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.1 Guideline 2. 3. 
NOTE 2: This success criteria is applicable to all content in the software (whether or not there is an alternate accessible mode of 
operation of the software) since any part of a software that does not meet this success criterion can interfere with a user's  ability to 
use the whole software (including a user interface element that enables the us er to activate the alternate accessible mode of 
operation).  
NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or  present 
information that is generated or received between the initiat ion of the pause and resuming presentation, as this may not be 
technically possible, and in many situations could be misleading to do so.  
NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot 
occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was 
frozen or broken.  
NOTE 5: This is to be applied to all content. Any content, whether informative or decorat ive, that is updated automatically, blinks, or 
moves may create an accessibility  barrier.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  57  
 Software does not contain anything that flashes more than three times in any one second per iod, or the flash is 
below the general flash and red flash thresholds.   
NOTE 6: This success criterion is identical to the WCAG 2.1 Success Criterion 2.2.2 Pause, Stop, Hide replacing "page" and "Web 
page" with "software", removing "See Conformance Requirement 10.7.(e) : Non -Interference" in note 2 of the success criterion, with 
the words "WCAG 2.1" added befo re the word "Guideline" in note 1 above, with note 2 above re -drafted to avoid the use of the word 
"must" and with the addition of note 5 above.  
 
 
12.3.3  Seizures and physical  reactions  
 
12.3.3.1  Three flashes or below  threshold  
 
Where ICT is non -web software that  provides a user interface, it shall comply with the success criterion given 
in Table 23.  
 
Table 23: Software success criterion: Three flashes or below threshold  
 
NOTE 1: This success criteria is applicable to all content in the software (whether or not there is an alternate accessible m ode of 
operation of the software) since any part of a software that does not meet this success criterion can interfere with a user's ability to 
use the whole software (including a user interface element that enables the user to activate the alternate accessible mode of  
operation).  
NOTE 2: This success criteri on is identical to the WCAG 2.1 Success Criterion 2.3.1 Three Flashes or Below Threshold replacing 
"Web pages" with "software", "the whole page" with "the whole software", "the Web page" with "the software" and removing "See  
Conformance Requirement 10.7(e) : Non -Interference" and with note 1 above re -drafted to avoid the use of the word "must".  
 
 
12.3.4  Navigable  
 
12.3.4.1  Focus  order  
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion in 
given Table 24.  
 
Table 24: Software success criterion: Focus order  
 
If software can be navigated sequentially and the navigation sequences affect meaning or operation, focusable 
components receive focus in an order that preserves meaning and operability.  
NOTE:  This success criterion is identical to the WCAG 2.1 Success Criterion 2.4.3 Focus order replacing "Web page" with 
"software".  
 
 
12.3.4.2  Link purpose (in  context)  
 
Where ICT is non -web software that provides a user interface, it shall comply with WCAG 2.1, Success 
Criterion 2.4.4, Link Purpose (In Context).  
 
12.3.4.3  Headings and  labels  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 2.4.6, Headings and Labels.  
 
In software, headings and labels are used to describe se ctions of content and controls respectively. In some 
cases, it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label 
or a heading, the requirement is the same: that if they are present, they describe the topi c or purpose of the 
item(s) they are associated  with. 58 © KEBS:2021: – All rights reserved   
 12.3.4.4  Focus  visible  
 
Where ICT is non -web software  that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 2.4.7, Focus Visible.  
 
12.3.5  Input  modalities  
 
12.3.5.1  Pointer  gestures  
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion given  
in Table 25.  
 
Table 25: Software success criterion: Pointer gestures  
 
All functionality that uses multipoint or path -based gestures for operation can be operated with a single pointer 
without a path -based gesture, unless a multipoint or path -based gesture  is essential.  
NOTE 1: This requirement applies to non -web software that interprets pointer actions (i.e. this does not apply to actions that are 
required to operate the user agent or assistive  technology).  
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original  WCAG  
2.1 note with note 1 above.  
 
 
12.3.5.2  Pointer  cancellation  
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion in 
Table 26.  
 
Table 26: Software success criterion: Pointer cancellation  
 
For functionality that can be operated using a single pointer, at least one of the following is true:  
 No Down -Event: The down -event of the pointer is not used to execute any part of the  function.  
 Abort  or Undo:  Completion  of the function  is on the up-event,  and a mechanism  is available  to abort  the 
function before completion or to undo the function after  completion.  
 Up Reversal: The up -event reverses any outcome of the preceding  down -event.  
 Essential: Completing the function on the down -event is  essential.  
NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.  
NOTE 2: This requirement applies to non -web software that interprets pointer actions (i.e. this does not apply to actions that are 
required to operate the user agent or assistive  technology).  
NOTE 3: This success criterion is identical to the WCAG 2.1, Success Criterion 2.5.2, Pointer Cancellation replacing the orig inal 
WCAG 2.1 note with notes  1 and 2  above.  
 
 
12.3.5.3  Label in  name  
 
12.3.5.3.1  Label in name (open  functionality)  
 
Where ICT is non -web software that provides a user interface, it shall comply with WCAG 2.1, Success 
Criterion 2.5.3, Label in Name.  
 
12.3.5.3.2  Label in name (closed  functionality)  
 
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for 
screen reading, it should meet requirement 6.1.3.3 (Auditory output correlation).  
 
12.3.5.4  Motion  actuation  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  59  
  
Where ICT is non -web software that provide s a user interface, it shall comply with WCAG 2.1, Success 
Criterion 2.5.4, Motion Actuation.  
 
12.4 Understandable  
 
12.4.1  Readable  
 
12.4.1.1  Language of  software  
 
12.4.1.1.1  Language of software (open  functionality)  
 
Where ICT is non -web software that provides a user interface and that  supports access to assistive 
technologies for screen reading, it shall comply with the success criterion given in Table 27.  
 
Table 27: Software success criterion: Language of software  
 
The default human language of software can be programmatically determi ned. 
NOTE 1: Where software platforms provide a "locale / language" setting, applications that use that setting and render their i nterface 
in that "locale / language" would comply with this success criterion. Applications that do not use the platform "locale / language" 
setting but instead use an accessibility -supported method for exposing the human language of the software would also comply with 
this success criterion.  
Applications implemented in technologies where assistive technologies cannot determine the hu man language and that do not 
support the platform "locale / language" setting may not be able to meet this success criterion in that locale / language.  
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 3.1.1 Language of page , replacing "each web page" 
with "software" and with the addition of note 1  above.  
 
 
12.4.1.1.2  Language of software (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to assistive technologies for 
screen reading, it shall meet requirement 6.1.3.14 (Spoken languages).  
 
12.4.2  Predictable  
 
12.4.2.1  On focus  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 3.2.1, On Focus.  
 
NOTE: Some compound documents and their user agents are designed to provide significantly different viewing and 
editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation 
that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon 
whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a 
mechanism other than putting focus on that portion of the compound document with which they mean  to interact (e.g. by a 
menu choice or special keyboard gesture), any resulting change of context would not be subject to this success criterion 
because it was not caused by a change of focus.  
 
12.4.2.2  On input  
 
Where ICT is non -web software that provides a user i nterface, it shall comply with the WCAG 2.1, Success 
Criterion 3.2.2, On Input.  
 
12.4.3  Input  assistance  
 
12.4.3.1  Error  identification  60 © KEBS:2021: – All rights reserved   
 12.4.3.1.1  Error identification (open  functionality)  
 
Where ICT is non -web software that provides a user interface and that supports access to assistive 
technologies for screen reading, it shall comply with the WCAG 2.1, Success Criterion 3. 3.1, Error 
Identification.  
 
12.4.3.1.2  Error Identification (closed  functionality)  
 
Where ICT is non -web software that provides a user interface which is closed to assistive technologies for 
screen reading, it shall meet requirement 6.1.3.15 (Non -visual error identification).  
 
12.4.3.2  Labels or  instructions  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 3.3.2, Labels or Instructions.  
 
12.4.3.3  Error  suggestion  
 
Where ICT is non -web software that provides a user interface, it shall comply with the WCAG 2.1, Success 
Criterion 3.3.3, Error Suggestion.  
 
12.4.3.4  Error prevention (legal, financial,  data)  
 
Where ICT is non -web software that provides a user interface, it shall comply with the success criterion given 
in Tabl e 28.  
 
Table 28: Software success criterion: Error prevention (legal, financial, data)  
 
For software that cause legal commitments or financial transactions for the user to occur, that modify or delete user - 
controllable data in data storage systems, or that submit user test responses, at least one of the following is true:  
1) Reversible: Submissions are  reversible.  
2) Checked:  Data  entered  by the user is checked  for input  errors  and the user is provided  an opportunity  to correct 
them.  
3) Confirmed:  A mechanism  is available  for reviewing,  confirming,  and correcting  information  before  finalizing  the 
submission.  
NOTE:  This success criterion is identical to the WCAG 2.1 Success Criterion 3.3.4, Error Prevention (Legal, Financial, Data) 
replacing "web pages" with  "software".  
 
 
12.5 Robust  
 
12.5.1  Compatible  
 
12.5.1.1  Parsing  
 
Where ICT is non -web software that provides a user interface and that supports access to any assistive 
technologies, it shall comply with the success criterion given in Table 29.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  61  
  
Table 29: Software success criterion: Parsing  
 
For software that uses markup languages, in such a way that the markup is separately exposed and available to 
assistive technologies and accessibility features of software or to a user -selectable user agent, elements ha ve 
complete start and end tags, elements are nested according to their specifications, elements do not contain 
duplicate attributes, and any IDs are unique, except where the specifications allow these features.  
NOTE 1: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched 
attribute value quotation mark are not  complete.  
NOTE 2: Markup is not always available to assistive technology or to user selectable user agents such as browsers. In  such cases, 
conformance  to this [requirement] would  have  no impact  on accessibility  as it can for web content  where  it is exposed.  
NOTE 3: Examples of markup that is separately exposed and available to assistive technologies and to user agents include but are 
not limited  to: documents  encoded  in HTML,  ODF, and  OOXML.  In these  examples,  the markup  can be parsed  entirely  in two ways:  
a) by assistive technologies which may directly open the  document,  
b) by assistive technologies using DOM APIs of user agents for  these document  formats.  
NOTE 4: Examples of markup used internally for persistence of the software user interface that are never exposed to assistive  
technology include but are not limited to: XUL, and FXML. In these examples assistive technology only interacts with the user 
interface of generated software.  
NOTE 5: This success criterion is identical to the WCAG 2.1 Success Criterion 4.1.1 Parsing replacing "In content implemented  
using markup languages" with "For software that uses markup languages, i n such a way that the markup is separately exposed and 
available to assistive technologies and accessibility features of software or to a user -selectable user agent" with the addition of 
notes 2, 3 and 4  above.  
 
 
12.5.1.2  Name, role,  value  
 
Where ICT is non -web software that provides a user interface and that supports access to any assistive 
technologies, it shall comply with the success criterion in Table 30.  
 
Table 30: Software success criterion: Name, role, value  
 
For all user interface components (including b ut not limited to: form elements, links and components generated by 
scripts), the name and role can be programmatically determined; states, properties, and values that can be set by 
the user can be programmatically set; and notification of changes to these  items is available to user agents, 
including assistive technologies.  
NOTE 1: This success criterion is primarily for software developers who develop or use custom user interface components. 
Standard user interface components on most accessibility -supported platforms already meet this success criterion when used 
according to  specification.  
NOTE 2: For conforming to this success criterion, it is recommended for software user interfaces to use the accessibility ser vices 
provided by plat form software. These accessibility services enable interoperability between software user interfaces and both 
assistive technologies and accessibility features of software in standardized ways. Most platform accessibility services go b eyond 
programmatic ex posure of name and role, and programmatic setting of states, properties and values (and notification of same), and 
specify additional information that could or should be exposed and / or set (for instance, a list of the available actions fo r a given 
user i nterface component, and a means to programmatically execute one of the listed  actions).  
 
NOTE 3: This success criterion is identical to the WCAG 2.1, Success Criterion 4.1.2, Name, Role, Value replacing the origina l 
WCAG 2.1 note with: "This success criterion is primarily for software developers who develop or use custom user interface 
components. Standard user interface components on most accessibility - supported platforms already meet this success criterion 
when used according to specification." and  the addition of note 2 above.  
 
 
12.5.1.3  Status  messages  
 
Where ICT is non -web software, it shall comply with WCAG 2.1, Success Criterion 4.1.3, Status Messages.  
 
12.6 Interoperability with assistive  technology  
 
12.6.1  Closed  functionality  62 © KEBS:2021: – All rights reserved   
 Where the closed functionality of software complies with clause 6.1 (closed functionality) it shall not be 
required to comply with clause 12.6.2.1 to clause 12.6.2.17.  
 
12.6.2  Accessibility  services  
 
12.6.2.1  Platform accessibility service support for software that provides a user  interface  
 
Platform software shall provide a set of documented platform services that enable software that provides a 
user interface running on the platform software to interoperate with assistive technology.  
 
Where a user interface concept corresponding to one of t he clauses 12.6.2.5 to 12.6.2.17 is supported within 
the software environment, the platform software should support that requirement. For example, selection 
attributes from clause 12.6.2.14 (Modification of focus and selection attributes) may not exist in environments 
that do not allow selection, which is most commonly associated with copy and paste.  
 
NOTE 1: These define the minimum functionality of software providing user interfaces when using platform services.  
 
NOTE 2: In some platforms these services m ay be called accessibility services, but in some other platforms these services 
may be provided as part of the user interface services.  
 
NOTE 3: User interface services that provide accessibility support by default are considered to be part of the services  
provided to conform to this clause (e.g. the service for creating a new user interface element provides role, state, 
boundary, name and description).  
 
NOTE 4: To comply with this requirement the platform software can provide its own set of services or exp ose the services 
provided by its underlying platform layers, if those services conform to this requirement.  
 
NOTE 5: Within specific programming environments, the technical attributes associated with the user interface properties 
described in clauses 12.6. 2.5 to 12.6.2.17 may have different names than those used within the clauses.  
 
12.6.2.2  Platform accessibility service support for assistive  technologies  
 
Platform software shall provide a set of documented platform accessibility services that enable assistive 
technology to interoperate with software that provides a user interface running on the platform software.  
 
Where a user interface concept corresponding to one of the clauses 12.6.2.5 to 12.6.2.17 is supported within 
the software environment, the platform s oftware should support that requirement. For example, selection 
attributes from clause 12.6.2.14 (Modification of focus and selection attributes) may not exist in environments 
that do not allow selection, which is most commonly associated with copy and pas te. 
 
NOTE 1: These define the minimum functionality available to assistive technologies when using platform services.  
 
NOTE 2: The definition of platform in clause 3.23 applies to software that provides services to other software, including but 
not limited  to, operating systems, web browsers, virtual machines.  
 
NOTE 3: In some platforms these services may be called accessibility services, but in some other platforms these services 
may be provided as part of the user interface services.  
 
NOTE 4: Typically, t hese services belong to the same set of services that are described in clause 12.6.2.1.  
 
NOTE 5: To comply with this requirement the platform software can provide its own set of services or expose the services 
provided by its underlying platform layers, if  those services comply with this requirement.  
 
12.6.2.3  Use of accessibility  services  
 
Where the software provides a user interface it shall use the applicable documented platform accessibility 
services. If the documented platform accessibility services do not allow the software to meet the applicable 
requirements of clauses 12.6.2.5 to 12.6.2.17, then software that provides a user interface shall use other 
documented services to interoperate with assistive technology.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  63  
  
NOTE: The term "documen ted platform accessibility services" refers to the set of services provided by the platform 
according to clauses 12.6.2.1 and 12.6.2.2.  
 
It is recommended to develop software using toolkits that automatically implement the underlying platform 
accessibility  services.  
 
12.6.2.4  Assistive  technology  
 
Where the ICT is assistive technology, it shall use the documented platform accessibility services.  
 
NOTE 1: The term "documented platform accessibility services" refers to the set of services provided by the platform 
according to clauses 12.6.2.1 and 12.6.2.2.  
 
NOTE 2: Assistive technology can also use other documented accessibility services.  
 
12.6.2.5  Object  information  
 
Where the software provides a user interface, it shall, by using the services as described in clause 12.6.2.3,  
make the user interface elements' role, state(s), boundary, name, and description programmatically 
determinable by assistive technologies.  
 
12.6.2.6  Row, column, and  headers  
 
Where the software provides a user interface, it shall, by using the services as described in clause 12.6.2.3, 
make the row and column of each cell in a data table, including headers of the row and column if present, 
programmatically determinable by assistive technologies.  
 
12.6.2.7  Values  
 
Where the software provides a user interface, it shall , by using the services as described in clause 12.6.2.3, 
make the current value of a user interface element and any minimum or maximum values of the range, if the 
user interface element conveys information about a range of values, programmatically determin able by 
assistive technologies.  
 
12.6.2.8  Label  relationships  
 
Where the software provides a user interface, it shall expose the relationship that a user interface element has 
as a label for another element, or of being labelled by another element, using the services as described in 
clause 12.6.2.3, so that this information is programmatically determinable by assistive technologies.  
 
12.6.2.9  Parent -child  relationships  
 
Where the software provides a user interface, it shall, by using the services as described in clause  12.6.2.3, 
make the relationship between a user interface element and any parent or children elements programmatically 
determinable by assistive technologies.  
 
12.6.2.10  Text 
 
Where the software provides a user interface it shall, by using the services as described in clause 12.6.2.3, 
make the text contents, text attributes, and the boundary of text rendered to the screen programmatically 
determinable by assistive technologies.  
 
12.6.2.11  List of available  actions  64 © KEBS:2021: – All rights reserved   
 Where the software provides a user interface it shall, by using the services as described in clause 12.6.2.3, 
make a list of available actions that can be execu ted on a user interface element, programmatically 
determinable by assistive technologies.  
 
12.6.2.12  Execution of available  actions  
 
Where permitted by security requirements, software that provides a user interface shall, by using the services 
as described in clause  12.6.2.3, allow the programmatic execution of the actions exposed according to clause  
12.6.2.11 by assistive technologies.  
 
NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from 
interfering with the ICT product. Examples of systems under strict security requirements are systems dealing with 
intelligence activities, cryptologic activities related to national security, command and control of military forces.  
 
NOTE 2: Assistive technologies may be re quired to maintain the same level of security as the standard input mechanisms 
supported by the platform.  
 
12.6.2.13  Tracking of focus and selection  attributes  
 
Where software provides a user interface it shall, by using the services as described in clause 12.6.2.3,  make 
information and mechanisms necessary to track focus, text insertion point, and selection attributes of user 
interface elements programmatically determinable by assistive technologies.  
 
12.6.2.14  Modification of focus and selection  attributes  
 
Where permitted b y security requirements, software that provides a user interface shall, by using the services 
as described in clause 12.6.2.3, allow assistive technologies to programmatically modify focus, text insertion 
point, and selection attributes of user interface e lements where the user can modify these items.  
 
NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from 
interfering with the ICT product and so this requirement would not apply. Examples of systems un der strict security 
requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command 
and control of military forces.  
 
NOTE 2: Assistive technologies may be required to maintain the same level of se curity as the standard input mechanisms 
supported by the platform.  
 
12.6.2.15  Change  notification  
 
Where software provides a user interface it shall, by using the services as described in clause 12.6.2.3, notify 
assistive technologies about changes in those programmatically determinable attributes of user interface 
elements that are referenced in requirements 12.6.2.5 to 12.6.2.11 and 12.6.2.13.  
 
12.6.2.16  Modifications of states and  properties  
 
Where permitted by security requirements, software that provides a user in terface shall, by using the services 
as described in clause 12.6.2.3, allow assistive technologies to programmatically modify states and properties 
of user interface elements, where the user can modify these items.  
 
NOTE 1: In some cases the security requi rements imposed on a software product may forbid external software from 
interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security 
requirements are systems dealing with intelligence activities, crypt ologic activities related to national security, command 
and control of military forces.  
 
NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms 
supported by the platform.  
 
12.6.2.17  Modifications of val ues and  text DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  65  
  
Where permitted by security requirements, software that provides a user interface shall, by using the services 
as described in clause 12.6.2.3, allow assistive technologies to modify values and text of user interface 
elemen ts using the input methods of the platform, where a user can modify these items without the use of 
assistive technology.  
 
NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from 
interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security 
requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command 
and control of military forces.  
 
NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms 
supported by the platform.  
 
12.7 Documented accessibility  usage  
 
12.7.1  User control of accessibility  features  
 
Where software is a platform, it shal l provide sufficient modes of operation for user control over those platform 
accessibility features documented as intended for users.  
 
12.7.2  No disruption of accessibility  features  
 
Where software provides a user interface it shall not disrupt those documented a ccessibility features that are 
defined in platform documentation except when requested to do so by the user during the operation of the 
software.  
 
12.8 User  preferences  
 
Where softw are is not designed to be isolated from its platform, and provides a user interface, that user 
interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, 
contrast, font type, font size, and focus curs or except where they are overridden by the user.  
 
NOTE 1: Software that is isolated from its underlying platform has no access to user settings in the platform and thus 
cannot adhere to them.  
 
NOTE 2: For web content, the underlying platform is the user ag ent. 
 
NOTE 3: This does not preclude the software from having additional values for a setting as long as there is one mode 
where the application will follow the system settings even if more restricted.  
 
12.9 Authoring  tools  
 
12.9.1  General  (informative)  
 
For those cre ating web content authoring tools, ATAG 2.0 provides information that can be of interest to those 
who want to go beyond these requirements.  
 
NOTE: This is applicable both to standalone and to web based authoring tools.  
 
12.9.2  Content  technology  
 
Authoring tools shall comply with clauses 12.9.3 to 12.9.6 to the extent that information required for 
accessibility is supported by the format used for the output of the authoring tool.  
 
12.9.3  Accessible content  creation  66 © KEBS:2021: – All rights reserved   
 Authoring tools shall enable and guide the production of content that complies with clause 10 (Web content) or 
clause 11 (Non -Web content) as applicable.  
 
NOTE:     Authoring tools may rely on additional tools where conformance with specific requirements is not achievable    
by a single tool. For example, a video editing tool may enable the creation of video files for distribution via broadcast 
television a nd the web, but authoring of caption files for multiple formats may be provided by a different  tool. 
 
12.9.4  Preservation of accessibility information in  transformations  
 
If the authoring tool provides restructuring transformations or re -coding transformations, then accessibility 
information shall be preserved in the output if equivalent mechanisms exist in the content technology of the 
output.  
 
NOTE 1: Restructuring transformations are transformations in which the content technology stays the same, but the 
struc tural features of the content are changed (e.g. linearizing tables, splitting a document into pages).  
 
NOTE 2: Re -coding transformations are transformations in which the technology used to encode the content is changed.  
 
12.9.5  Repair  assistance  
 
If the accessibility checking functionality of an authoring tool can detect that content does not meet a 
requirement of clause 10 (Web) or clause 11 (Non -web documents) as applicable, then the authoring tool 
shall provide repair  suggestion(s).  
 
NOTE:  This does not preclude automated and semi -automated repair which is possible (and encouraged) for many   
types of content accessibility  problems.  
 
12.9.6  Templates  
 
When an authoring tool provides templates, at least one template that supports the creation  of content that 
complies with the requirements of clause 10 (Web) or clause 11 (Non -web documents) as applicable shall be 
available and identified as such.  
 
13 Documentation and support  services  
13.1 Product  documentation  
 
13.1.1  Accessibility and compatibility  features  
 
Product documentation provided with the ICT whether separately or integrated within the ICT shall;list and 
explain how to use the accessibility and compatibility features of the ICT.  
 
NOTE 1: Accessibility and compatibility features include accessibility  features that are built -in and accessibility features 
that provide compatibility with assistive  technology.  
 
NOTE 2: It is recommended to use WebSchemas/Accessibility 2.0 to provide meta data on the accessibility of the ICT. 
NOTE 3: The accessibility stat ement and help pages are both examples of the provision of product information.  
13.1.2  Accessible  documentation  
 
Product documentation provided with the ICT shall:  
 
a) be easily identifiable and accessible. Where online resources are available, the URLs shall be provided; 
and 
 
b) be made available in at least one of the following electronic  formats:  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  67  
  
i) a web format that conforms to the requirements of clause 10;  or 
ii) a non -web format that conforms to the requirements of clause  11. 
NOTE 1: This does not  preclude the possibility of also providing the product documentation in other formats (electronic, 
printed or audio) that are not accessible.  
 
NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some spe cific type 
of users (e.g. Braille documents for blind people or easy -to-read information for persons with limited cognitive, language 
and learning  abilities).  
 
NOTE 3: Where documentation is incorporated into the ICT, the documentation falls under the req uirements for 
accessibility in this standard.  
 
NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.  
 
13.2 Support  services  
 
13.2.1  General  
 
ICT support services include, but are not limited to help desks, call centres, technical support, relay services 
and training services.  
 
13.2.2  Information on accessibility and compatibility  features  
 
ICT support services shall provide information on the accessibility and compatibility features that are 
mentioned in the product doc umentation.  
 
NOTE:    Accessibility and compatibility features include accessibility features that are built -in and accessibility features 
that provide compatibility with assistive  technology.  
 
13.2.3  Effective  communication  
 
ICT support services shall be easily identifiable and accessible. Where online support services are available, 
the URLs shall be provided and user friendly;  
 
ICT support services shall accommodate the communication needs of persons with disabilities either  directly 
or through a referral  point.  
 
13.2.4  Accessible  documentation  
 
Documentation provided by support services shall be made available in at least one of the following electronic 
formats:  
 
a) a Web format that conforms to clause 10;  or 
b) a non -web format that conforms to clause  11. 
NOTE 1: This does not preclude the possibility of also providing the documentation in other formats (electronic or printed) 
that are not accessible.  
 
NOTE 2: It also does not preclude the possibility of providing alternate formats th at meet the needs of some specific type 
of users (e.g. Braille documents for blind people or easy -to-read information for persons with limited cognitive, language 
and learning  abilities).  
 
NOTE 3: Where the support documentation is incorporated into the ICT, the documentation falls under the requirements 
for accessibility in this  standard.  
 
NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.  68 © KEBS:2021: – All rights reserved   
 14 ICT providing relay or emergency service  access  
14.1 Relay services  requirements  
 
14.1.1  General  
 
Relay services enable users of different modes of communication e.g. text, sign, speech, to interact remotely 
through ICT with two -way communication by providing conversion between the modes of communication, 
normally by a human operator.  
 
It is recommended to meet the applicable relay service requirements of ETSI ES 202 9 75. 
 
14.1.2  Text relay  services  
 
Where ICT is intended to provide a text relay service, the text relay service shall enable text users and speech 
users to interact by providing conversion between the two modes of communication.  
 
14.1.3  Sign relay  services  
 
Where ICT is intended to provide a sign relay service, the sign relay service shall enable sign language users 
and speech users to interact by providing conversion between the two modes of communication.  
 
NOTE: Sign relay services are also sometimes referred to as sign  language relay services or video relay services.  
 
14.1.4  Lip-reading relay  services  
 
Where ICT is intended to provide a lip -reading relay service, the lip -reading service shall enable lip -readers 
and voice telephone users to interact by providing conversion betw een the two modes of communication.  
 
14.1.5  Captioned telephony  services  
 
Where ICT is intended to provide a captioned telephony service, the captioned telephony service shall assist a 
deaf or hard of hearing user in a spoken dialogue by providing text captions t ranslating the incoming part of 
the conversation.  
 
14.1.6  Speech to speech relay  services  
 
Where ICT is intended to provide a speech to speech relay service, the speech to speech relay service shall 
enable telephone users who are speech impaired, have limited cog nitive, language and learning abilities, as 
well as any other user, to communicate by providing assistance between them.  
 
14.2 Access to relay  services  
 
Where ICT systems support two -way communication, and the system is specified for use with relay services, 
access to those relay services shall not be prevented for outgoing and incoming calls involving: voice, RTT, or 
video, either individually or in combi nations supported by both the relay service and the ICT system.  
 
NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access by persons with 
disabilities.  
 
NOTE 2: The system may be specified as needing to work with r elay services by, for example: procurers, regulators, or 
product specifications.  
 
14.3 Access to emergency  services  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  69  
  
14.3.1  Two-way communication  
 
Where ICT systems support two -way communication, and the system is specified for use with emergency 
services, access to those emergency services shall not be prevented for outgoing and incoming calls 
involving: voice, RTT, or video, either individually or in combinations supported by both the emergency service 
and the ICT  system.  
 
14.3.2  Lighting  communication  
 
Where ICT systems support the use of lighting system in addition to the two -way communication specified in 
14.3.1, and the ICT system is specified for use with emergency services, access to the emergency services 
shall be available through both the light ing system and the two -way communication system.  
 
NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access to the emergency 
service by persons with disabilities.  
 
NOTE 2: The system may be specified as needing to w ork with emergency services by, for example: 
procurers, regulators, or product specifications.  
 
15 Conformance  
15.1 Conformance to this standard is achieved by meeting all the applicable requirements, these are clauses 
containing the word "shall". Those clauses co ntaining the word "should" are recommendations and are not 
mandatory for  conformance.  
 
15.2 All clauses except those in clause 13 are self -scoping. This means they are introduced with the phrase 
'Where ICT <pre condition>'. A requirement is met when the pre-condition is true/provided and the 
corresponding test (in part 2 of this standard) is  passed.  
 
15.3 When one of the pre -conditions is false/not provided the requirement is not applicable/achieved. 
Consequently, the result of the tests in part 2 of this stan dard can be: not applicable, pass, fail, or (in 
exceptional circumstances) not  testable.  
 
15.4 ICT is of ten comprised of an assembly of two or more items of ICT. In some cases, two or more 
interoperable items of ICT may together meet more requirements of the standard when one item complements 
the functionality of the other and the sum together meets more of the accessibility requirements. However, 
combining two items of ICT, both of which fail to meet any particular requirement, will not lead to a combined 
ICT system that meets that  requirement.  
 
NOTE 1: Conformance with the accessibility requirements could b e affected by subsequent implementation or 
maintenance.  
 
NOTE 2: Sampling is frequently required on complex ICT when there are too many instances of the object to be tested. 
This standard cannot recommend specific ICT evaluation sampling techniques as thes e are context specific.  70 © KEBS:2021: – All rights reserved   
 Annex A  
(Informative)  
 
Relationship between requirements and functional performance 
principles  
 
 
A.1 Relationships between clauses 6 to 14 and the functional performance  principles  
 
Table A.2 shows which of the requirements set out in clauses 6 to 14 support each of the functional 
performance principles set out in clause 5.2.  
 
To allow Table A.2 to fit the page, the abbreviations shown in Table A.1 have been used in the column 
headers of Table A.2.  
 
Table A.1 ― Key to the column header designations used in Table A.2  
 
Clause 
number  Column header 
abbreviation  Functional performance principle  
5.2.1  WV Usage without vision  
5.2.2  LV Usage with limited vision  
5.2.3  WPC  Usage without perception of colour  
5.2.4  WH Usage without hearing  
5.2.5  LH Usage with limited hearing  
5.2.6  WVC  Usage without vocal capability  
5.2.7  LMS Usage with limited manipulation or strength  
5.2.8  LR Usage with limited reach  
5.2.9  PS Usage with photosensitive seizures  
5.2.10  LC Usage with limited cognition  
5.2.11  Pv Privacy  
 
 
The following abbreviations have been used to represent the relationship between  the requirements in clauses 
6 to 14 and the functional performance principles:  
 
a) P = Primary relationship. The requirement supports the functional performance  statement.  
b) S = Secondary relationship. The requirement provides partial support for the functiona l performance 
statement because some users may use the feature in specific  situations.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  71  
  
Table A.2: Requirements in clauses 6 to 14 supporting the accessibility needs expressed in the 
functional performance principles  
 
Requirements  5.2.1  
WV 5.2.2  
LV 5.2.3  
WPC  5.2.4  
WH 5.2.5  
LH 5.2.6  
WVC  5.2.7  
LMS  5.2.8  
LR 5.2.9  
PS 5.2.10  
LC 5.2.11  
Pv 
6.1.2.1 Closed functionality  P P P P P P P P P P P 
6.1.2.2 Assistive technology  - - - - - - - - - - S 
6.1.3.1 Audio output of visual 
information  P S - - - - - - - S - 
6.1.3.2 Auditory output delivery 
including speech  P S - - - - - - - S - 
6.1.3.3 Auditory output 
correlation  - P - - - - - - - S - 
6.1.3.4 Speech output user 
control  P S - - - - - - - S - 
6.1.3.5 Speech output 
automatic interruption  P S - - - - - - - S - 
6.1.3.6 Speech output for non - 
text content  P S - - - - - - - S - 
6.1.3.7 Speech output for video 
information  P S - - - - - - - S - 
6.1.3.8 Masked entry  P S - - - - - - - S P 
6.1.3.9 Private access to 
personal data  P S - - - - - - - S P 
6.1.3.10 Non -interfering audio 
output  P S - - - - - - - S - 
6.1.3.11 Private listening 
volume  P S - - S - - - - S S 
6.1.3.12 Speaker volume  P S - - S - - - - S - 
6.1.3.13 Volume reset  P S - - S - - - - S - 
6.1.3.14 Spoken languages  P S - - - - - - - S - 
6.1.3.15 Non -visual error 
identification  P S - - - - - - - S - 
6.1.3.16 Receipts, tickets, and 
transactional outputs  P S - - - - - - - - - 
6.1.4 Functionality closed to 
text enlargement  - P - - - - - - - - - 
6.1.5 Visual output for auditory 
information  - - - P P - - - - S - 
6.1.6.1 Operation without  
keyboard interface (closed 
functionality)   
P  
P  
-  
-  
-  
S  
P  
-  
-  
-  
- 
6.1.6.2 Operation without  
keyboard interface (Input 
focus)   
P  
P  
-  
-  
-  
S  
P  
-  
-  
-  
- 
6.1.7 Access without speech  - - - - - P - - - - - 
6.2 Activation of accessibility 
features  P P P P P - P - - - - 72 © KEBS:2021: – All rights reserved   
  
6.3 Biometrics  P P - P - P P P - - P 
6.4 Preservation of 
accessibility information during 
conversion   
P  
P  
-  
P  
P  
-  
-  
-  
-  
S  
- 
6.5.1 Means of operation  - - - - - - P - - - - 
6.5.2 Operable part 
discernibility  P S - - - - - - - - - 
6.6.1 Tactile or auditory status  P P - P - - - - - S - 
6.6.2 Visual status  - - - P P - P P - S - 
6.7 Key repeat  - - - - - - P - - S - 
6.8 Double -strike key 
acceptance  - - - - - - P P - S - 
6.9 Simultaneous user actions  - - - - - - P P - S - 
7.1 Audio bandwidth for 
speech   
-  
-  
-  
-  
P  
-  
-  
-  
-  
-  
- 
7.2.1.1 RTT communication  - - - P S S - - - - - 
7.2.1.2 Concurrent voice and 
text - - - P P S - - - - - 
7.2.2.1 Visually distinguishable 
display  - - - P S S - - - - - 
7.2.2.2 Programmatically 
determinable send and receive 
direction   
-  
-  
-  
P  
S  
S  
-  
-  
-  
-  
- 
7.2.2.3 Speaker identification  - - - P P S - - - - - 
7.2.2.4 Visual indicator of 
Audio with RTT  - - - P P S - - - - - 
7.2.3 Interoperability  - - - P S S - - - - - 
7.2.4 RTT responsiveness  - - - P S S - - - - - 
7.3 Caller ID  P P - - - - - - - S - 
7.4 Alternatives to voice - based 
services  - - - P P P - - - - - 
7.5.2 Resolution  - - - P P S - - - - - 
7.5.3 Frame rate  - - - P P S - - - - - 
7.5.4 Synchronization between 
audio and video  - - - P P S - - - - - 
7.5.5 Visual indicator of audio 
with video  - - - P P S - - - - - 
7.5.6 Speaker identification 
with video (sign language) 
communication   
-  
-  
-  
P  
P  
S  
-  
-  
-  
-  
- 
7.6 Alternatives to video - 
based services  P S - P P P - - - - - 
8.1.1 Captioning playback  - - - P P - - - - S - 
8.1.2 Captioning 
synchronization  - - - P P - - - - S - DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  73  
  
8.1.3 Preservation of 
captioning  - - - P P - - - - S - 
8.1.4 Captions characteristics  - S S P P - - - - S - 
8.1.5 Spoken subtitles  P P S - - - - - - S - 
8.2.1 Audio description 
playback  P P - - - - - - - S - 
8.2.2 Audio description 
synchronization  P P - - - - - - - S - 
8.2.3 Preservation of audio 
description  P P - - - - - - - S - 
8.3 User controls for captions 
and audio description  P P - P P - - - - S - 
9.1.2 Standard connections  P P - - P - P P - P - 
9.1.3 Colour  - S P - - - - - - S - 
9.2.1.1 Speech volume range  - - - - P - - - - - - 
9.2.1.2 Incremental volume 
control  - - - - P - - - - - - 
9.2.2.1 Fixed -line devices  - - - - P - - - - - - 
9.2.2.2 Wireless 
communication devices  - - - - P - - - - - - 
9.3 Stationary ICT, General  - - - - - - - P - - - 
9.3.2 Forward or side reach  - - - - - - - P - - - 
9.3.3.1 Unobstructed high 
forward reach  - - - - - - - P - - - 
9.3.3.2 Unobstructed low 
forward reach  - - - - - - - P - - - 
9.3.3.3.1 Obstructed forward 
reach - Clear space  - - - - - - - P - - - 
9.3.3.3.2 Obstructed (<510 
mm) forward reach  - - - - - - - P - - - 
9.3.3.3.3 Obstructed (<635 
mm) forward reach  - - - - - - - P - - - 
9.3.3.4 Knee and toe clearance 
width  - - - - - - - P - - - 
9.3.3.5 Toe clearance  - - - - - - - P - - - 
9.3.3.6 Knee clearance  - - - - - - - P - - - 
9.3.4.1 Unobstructed high side 
reach  - - - - - - - P - - - 
9.3.4.2 Unobstructed low side 
reach  - - - - - - - P - - - 
9.3.4.3.1 Obstructed (≤ 255 
mm) side reach  - - - - - - - P - - - 
9.3.4.3.2 Obstructed (≤ 610 
mm) side reach  - - - - - - - P - - - 
9.3.5.1 Change in level  - - - - - - - P - - - 74 © KEBS:2021: – All rights reserved   
  
9.3.5.2 Level ground space  - - - - - - - P - - - 
9.3.5.3.1 Approach - General  - - - - - - - P - - - 
9.3.5.3.2 Forward approach  - - - - - - - P - - - 
9.3.5.3.3 Parallel approach  - - - - - - - P - - - 
9.3.6 Visibility  - - - - - - - P - - - 
9.3.7 Installation instructions  - - - - - - - P - - - 
9.4.1 Numeric keys  P S - - - - - - - - - 
9.4.2.1 Means of operation of 
mechanical parts  - - - - - - P - - - - 
9.4.2.2 Force of operation of 
mechanical parts  - - - - - - P - - - - 
9.4.3 Keys, tickets and fare 
cards  P S - - - - - - - - - 
9.5 Tactile indication of speech 
mode  P - - - - - - - - - - 
10.2.1.1 Non -text content  P P - P S - - - - S S 
10.2.2.1 Audio -only and video - 
only (pre -recorded)  P P - P P - - - - S - 
10.2.2.2 Captions (pre - 
recorded)  - - - P P - - - - S - 
10.2.2.3 Audio description or 
media alternative (pre - 
recorded)   
P  
S  
-  
-  
-  
-  
-  
-  
-  
S  
- 
10.2.2.4 Captions (live)  - - - P P - - - - S - 
10.2.2.5 Audio description (pre - 
recorded)  P S - - - - - - - S - 
10.2.3.1 Info and relationships  P S - - - - - - - S - 
10.2.3.2 Meaningful sequence  P S - - - - - - - S - 
10.2.3.3 Sensory 
characteristics  P P P P P - - - - S - 
10.2.3.4 Orientation  - - - - - - P P - S - 
10.2.3.5 Identify input purpose  - P - - - - - - - - - 
10.2.4.1 Use of colour  P P P - - - - - - S - 
10.2.4.2 Audio control  P - - - P - - - - S - 
10.2.4.3 Contrast (minimum)  - P P - - - - - - S - 
10.2.4.4 Resize text  - P - - - - - - - - - 
10.2.4.5 Images of text  - P P - - - - - - S - 
10.2.4.6 Reflow  - P - - - - - - - - - 
10.2.4.7 Non -text contrast  - P P -  - - - - S - 
10.2.4.8 Text spacing  - P - - - - - - - P - 
10.2.4.9 Content on hover or 
focus  - P - - - - - - - P - 
10.3.1.1 Keyboard  P P - - - S P - - - - 
10.3.1.2 No keyboard trap  P P - - - S P - - - - DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  75  
  
10.3.1.3 Character key 
shortcuts  - - - - - - P P - S - 
10.3.2.1 Timing adjustable  P P - P P - P - - P - 
10.3.2.2 Pause, stop, hide  P P - P P - P - - P - 
10.3.3.1 Three flashes or 
below threshold  - - - - - - - - P - - 
10.3.4.1 Bypass blocks  P P - - - S P - - P - 
10.3.4.2 Page titled  P P - - - - P - - P - 
10.3.4.3 Focus order  P P - - - - P - - P - 
10.3.4.4 Link purpose (in 
context)  P P - - - S P - - P - 
10.3.4.5 Multiple ways  P P - - - S P - - P - 
10.3.4.6 Headings and labels  P P - S - S P - - P - 
10.3.4.7 Focus visible  P P - - - S P - - P - 
10.3.5.1 Pointer gestures  - - - - - - P P - P - 
10.3.5.2 Pointer cancellation  - P - - - - P P - P - 
10.3.5.3 Label in name  - - - - - - P P - S - 
10.3.5.4 Motion actuation  S S - - - - P P - S - 
10.4.1.1 Language of page  P S - S S - - - - S - 
10.4.1.2 Language of parts  P S - S S - - - - S - 
10.4.2.1 On focus  P P - - - - P - - P - 
10.4.2.2 On Input  P P - - - - P - - P - 
10.4.2.3 Consistent navigation  P P - - - - - - - P - 
10.4.2.4 Consistent 
identification  S P - - - - - - - P - 
10.4.3.1 Error identification  P P P - - - - - - P - 
10.4.3.2 Labels or instructions  P P - - - S S - - P - 
10.4.3.3 Error suggestion  P P - - - S S - - P - 
10.4.3.4 Error prevention 
(legal, financial, data)  P P - - - - S - - P - 
10.5.1.1 Parsing  P S - - - - - - - - - 
10.5.1.2 Name, role, value  P P - - - - S - - - - 
10.5.1.3 Status messages  P P P P P S P P P P - 
10.7 WCAG Conformance 
requirements  P P P P P S P P P P S 
11.2.1.1 Non -text content  P P - P S - - - - S S 
11.2.2.1 Audio -only and video - 
only (pre -recorded)  P P - P P - - - - S - 
11.2.2.2 Captions (pre - 
recorded)  - - - P P - - - - S - 
11.2.2.3 Audio description or 
media alternative  
(pre-recorded)   
P  
S  
-  
-  
-  
-  
-  
-  
-  
S  
- 76 © KEBS:2021: – All rights reserved   
  
11.2.2.4  Captions (live)  - - - P P - - - - S - 
11.2.2.5 Audio description (pre - 
recorded)  P S - - - - - - - S - 
11.2.3.1 Info and relationships  P S - - - - - - - S - 
11.2.3.2 Meaningful sequence  P S - - - - - - - S - 
11.2.3.3 Sensory 
characteristics  P P P P P - - - - S - 
11.2.3.4 Orientation  - - - - - - P P - S - 
11.2.3.5 Identify input purpose  - P - - - - - - - - - 
11.2.4.1 Use of colour  P P P - - - - - - S - 
11.2.4.2 Audio control  P - - - P - - - - S - 
11.2.4.3 Contrast (minimum)  - P P - - - - - - S - 
11.2.4.4 Resize text  - P - - - - - - - - - 
11.2.4.5 Images of text  - P P - - - - - - S - 
11.2.4.6 Reflow  - P - - - - - - - - - 
11.2.4.7 Non -text contrast  - P P -  - - - - S - 
11.2.4.8 Text spacing  - P - - - - - - - P - 
11.2.4.9 Content on hover or 
focus  - P - - - - - - - P - 
11.3.1.1 Keyboard  P P - - - S P - - - - 
11.3.1.2 No keyboard trap  P P - - - S P - - - - 
11.3.1.3 Character key 
shortcuts  - - - - - - P P - S - 
11.3.2.1 Timing adjustable  P P - P P - P - - P - 
11.3.2.2 Pause, stop, hide  P P - P P - P - - P - 
11.3.3.1 Three flashes or 
below threshold  - - - - - - - - P - - 
11.3.4.1 Document titled  P P - - - - P - - P - 
11.3.4.2 Focus order  P P - - - - P - - P - 
11.3.4.3 Link purpose (in 
context)  P P - - - S P - - P - 
11.3.4.4 Headings and labels  P P - S - S P - - P - 
11.3.4.5 Focus visible  P P - - - S P - - P - 
11.3.5.1 Pointer gestures  - - - - - - P P - P - 
11.3.5.2 Pointer cancellation  - P - - - - P P - P - 
11.3.5.3 Label in name  - - - - - - P P - S - 
11.3.5.4 Motion actuation  S S - - - - P P - S - 
11.4.1.1 Language of 
document  P S - S S - - - - S - 
11.4.1.2 Language of parts  P S - S S - - - - S - 
11.4.2.1 On focus  P P - - - - P - - P - 
11.4.2.2 On input  P P - - - - P - - P - DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  77  
  
11.4.3.1 Error identification  P P P - - - - - - P - 
11.4.3.2 Labels or instructions  P P - - - S S - - P - 
11.4.3.3 Error suggestion  P P - - - S S - - P - 
11.4.3.4 Error prevention 
(legal, financial, data)  P P - - - - S - - P - 
11.5.1.1 Parsing  P S - - - - - - - - - 
11.5.1.2 Name, role, value  P P - - - - S - - - - 
11.5.1.3 Status messages  P P P P P P P P P P - 
11.6 Caption positioning  - - - P P - - - - S - 
11.7 Audio description timing  P S - - - - - - - S - 
12.2.1.1.1 Non -text content 
(open functionality)  P P - P S - - - - S S 
12.1.1.1.2 Non -text content 
(closed functionality  P P - P S - - - - S S 
12.2.2.1.1 Audio -only and 
video -only (pre -recorded - 
open functionality)   
P  
P  
-  
P  
P  
-  
-  
-  
-  
S  
- 
12.2.2.1.2.1 Pre -recorded 
audio -only (closed  
functionality)   
-  
-  
-  
P  
P  
-  
-  
-  
-  
S  
- 
12.2.2.1.2.2 Pre -recorded 
video -only (closed  functionality)   
P  
S  
-  
-  
-  
-  
-  
-  
-  
S  
- 
12.2.2.2 Captions (pre - 
recorded)  - - - P P - - - - S - 
12.2.2.3.1 Audio description or 
media alternative  
(pre-recorded - open 
functionality)   
 
P  
 
S  
 
-  
 
-  
 
-  
 
-  
 
-  
 
-  
 
-  
 
S  
 
- 
12.2.2.3.2 Audio description or 
media alternative  
(pre-recorded - closed 
functionality)   
 
P  
 
S  
 
-  
 
-  
 
-  
 
-  
 
-  
 
-  
 
-  
 
S  
 
- 
12.2.2.4 Captions (live)  - - - P P - - - - S - 
12.2.2.5 Audio description (pre- 
recorded)  P S - - - - - - - S - 
12.2.3.1.1 Info and 
relationships (open 
functionality)   
P  
S  
-  
-  
-  
-  
-  
-  
-  
S  
- 
12.2.3.1.2 Info and 
relationships (closed 
functionality)   
P  
S  
-  
-  
-  
-  
-  
-  
-  
S  
- 
12.2.3.2.1 Meaningful 
sequence (open functionality)  P S - - - - - - - S - 
12.2.3.2.2 Meaningful 
sequence (closed functionality)   
P  
S  
-  
-  
-  
-  
-  
-  
-  
S  
- 
12.2.3.3 Sensory 
characteristics  P P P P P - - - - S - 78 © KEBS:2021: – All rights reserved   
  
12.2.3.4 Orientation  - - - - - - P P - S - 
12.2.3.5.1 Identify input 
purpose (open functionality)  - P - - - - - - - - - 
12.2.3.5.2 Identify input 
purpose (closed functionality)  - P - - - - - - - - - 
12.2.4.1 Use of colour  P P P - - - - - - S - 
12.2.4.2 Audio control  P - - - P - - - - S - 
12.2.4.3 Contrast (minimum)  - P P - - - - - - S - 
12.2.4.4.1 Resize text (open 
functionality)  - P - - - - - - - - - 
12.2.4.4.2 Resize text (closed 
functionality)  - P - - - - - - - - - 
12.2.4.5.1 Images of text 
(open functionality)  - P P - - - - - - S - 
12.2.4.5.2 Images of text 
(closed functionality)  - - - - - - - - - - - 
12.2.4.6 Reflow  - P - - - - - - - - - 
12.2.4.7 Non -text contrast  - P P -  - - - - S - 
12.2.4.8 Text spacing  - P - - - - - - - P - 
12.2.4.9 Content on hover or 
focus  - P - - - - - - - P - 
12.3.1.1.1 Keyboard (open 
functionality)  P P - - - S P - - - - 
12.3.1.1.2 Keyboard (closed 
functionality)  P P - - - S P - - - - 
12.3.1.2 No keyboard trap  P P - - - S P - - - - 
12.3.1.4.1 Character key 
shortcuts (open functionality)  - - - - - - P P - S - 
12.3.1.4.2 Character key 
shortcuts (closed functionality)   
-  
-  
-  
-  
-  
-  
P  
P  
-  
S  
- 
12.3.2.1 Timing adjustable  P P - P P - P - - P - 
12.3.2.2 Pause, stop, hide  P P - P P - P - - P - 
12.3.3.1 Three flashes or 
below threshold  - - - - - - - - P - - 
12.3.4.1 Focus order  P P - - - - P - - P - 
12.3.4.2 Link purpose (in 
context)  P P - - - S P - - P - 
12.3.4.3 Headings and labels  P P - S - S P - - P - 
12.3.4.4 Focus visible  P P - - - S P - - P - 
12.3.5.1 Pointer gestures  - - - - - - P P - P - 
12.3.5.2 Pointer cancellation  - P - - - - P P - P - 
12.3.5.3.1 Label in name (open 
functionality)  - - - - - - P P - S - 
12.3.5.3.2 Label in name 
(closed functionality)  - - - - - - P P - S - DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  79  
  
12.3.5.4 Motion actuation  S S - - - - P P - S - 
12.4.1.1.1 Language of 
software (open functionality)  P S - S S - - - - S - 
12.4.1.1.2 Language of 
software (closed functionality)  P S - S S - - - - S - 
12.4.2.1 On focus  P P - - - - P - - P - 
12.4.2.2 On input  P P - - - - P - - P - 
12.4.3.1.1 Error identification 
(open functionality)  P P P - - - - - - P - 
12.4.3.1.2 Error Identification 
(closed functionality)  P P P - - - - - - P - 
12.4.3.2 Labels or instructions  P P - - - S S - - P - 
12.4.3.3 Error suggestion  P P - - - S S - - P - 
12.4.3.4 Error prevention 
(legal, financial, data)  P P - - - - S - - P - 
12.5.1.1 Parsing  P S - - - - - - - - - 
12.5.1.2 Name, role, value  P P - - - - S - - - - 
12.5.1.3 Status messages  P P P P P P P P P P - 
12.6.2.1 Platform accessibility 
service support for software 
that provides a user interface   
P  
P  
-  
-  
-  
-  
P  
-  
-  
S  
- 
12.6.2.2 Platform accessibility 
service support for assistive 
technologies   
P  
P  
-  
-  
-  
-  
P  
-  
-  
S  
- 
12.6.2.3 Use of accessibility 
services  P P - - - - P - - S - 
12.6.2.4 Assistive technology  P P - - - - P - - S - 
12.6.2.5 Object information  P P - - - - P - - S - 
12.6.2.6 Row, column, and 
headers  P P - - - - P - - S - 
12.6.2.7 Values  P P - - - - P - - S - 
12.6.2.8 Label relationships  P P - - - - P - - S - 
12.6.2.9 Parent -child 
relationships  P P - - - - P - - S - 
12.6.2.10 Text  P P - - - - P - - S - 
12.6.2.11 List of available 
actions  P P - - - - P - - S - 
12.6.2.12 Execution of 
available actions  P P - - - - P - - S - 
12.6.2.13 Tracking of focus 
and selection attributes  P P - - - - P - - S - 
12.6.2.14 Modification of 
focus and selection attributes  P P - - - - P - - S - 
12.6.2.15 Change notification  P P - - - - P - - S - 80 © KEBS:2021: – All rights reserved   
  
12.6.2.16 Modifications of 
states and properties  P P - - - - P - - S - 
12.6.2.17 Modifications of 
values and text  P P - - - - P - - S - 
12.7.1 User control of 
accessibility features  P P P P P - P - - - - 
12.7.2 No disruption of 
accessibility features  P P P P P - P - - - - 
12.8 User preferences  - P P - - - - - - S - 
12.9.2 Content technology  P P P P P S P P P P S 
12.9.3 Accessible content 
creation  P P P P P S P P P P S 
12.9.4 Preservation of 
accessibility information in 
transformations   
P  
P  
P  
P  
P  
S  
P  
P  
P  
P  
S 
12.9.5 Repair assistance  P P P P P S P P P P S 
12.9.6 Templates  P P P P P S P P P P S 
13.1.1 Accessibility and 
compatibility features  P P P P P - P - - S - 
13.1.2 Accessible 
documentation  P P P P P S P P P P S 
13.2.2 Information on 
accessibility and compatibility 
features   
P  
P  
P  
P  
P  
-  
P  
-  
-  
S  
- 
13.2.3 Effective communication  - - - P P P - - - S - 
13.2.4 Accessible 
documentation  P P P P P S P P P P S 
14.1.2 Text relay services  - - - P P P - - - S - 
14.1.3 Sign relay services  - - - P P P - - - - - 
14.1.4 Lip -reading relay 
services  - - - P P P - - - - - 
14.1.5 Captioned telephony 
services  - - - P P P - - - - - 
14.1.6 Speech to speech relay 
services  - - - - - - - - - P - 
14.2 Access to relay services  - - - P P P - - - S - 
14.3 Access to emergency 
services  - - - P P P - - - S - 
 
 
A.2 Interpretation of Table  A.2 
 
A.2.1  General  
 
Table A.2 illustrates the impact a specific accessibility issue might have on different users. It does this by 
mapping the requirements in the standard with the functional performance principles in clause 5. A 
requirement can be Primary (P) or Secondary (S).  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  81  
 
A.2.2.1  Step  1 
 
For requirement 6.1.3.11, which relates to the possibility of changing the volume when  the user is listening in 
a private headset, the table can be read like  this: 
The requirement for private listening volume has a "P" for primary support in the column "WV", which stands 
for "without vision".  
This means that private listening volume supports the functional performance principles for users who cannot 
see. In other words, the possibility for the user to control the volume when listening via a private headset is 
necessary for blind users.  
 
A.2.1.2  Step  2 
 
The third column shows that, for users with low vision, the possibility to control the volume when listening via a 
private headset is not as necessary as for blind users, it has an S for Secondary, where the first column had a 
P for Primary   
The technical requirements are listed in a vertical column and the functional performance principles 
horizontally.  
 
 
The table indicates which functional performance principles, and corresponding user needs, are covered by 
each requirement.  
 
A.2.2  Example  
 
 
Secondary support means that some users in this group may use the accessibility feature in specific 
situations.  
 
A.2.1.3  Step  3 
 
In this way it is possible to assess the impact on functional performance principles if a particular requirement 
is not  met. 
82 © KEBS:2021: – All rights reserved   
  
 
 
 
The fourth column considers users who are color blind; the requirement on private listening volume is not 
marked at all. Of course, the possibility of changing the volume when listening in private headset is nice to 
have for all users, no matter their ability to distinguish between colors, but the listening volume does not 
compensate for the colo r blindness.  
 
A.2.1.4  Step  4 
 
The table can also be read the other way around:  
 
Since blind users cannot see the screen, they need an alternative way to use the interface. If this alternative is 
audio via private headset, blind users need the possibility to change the volume.  
Some users who can see, but not well, need or prefer to use audio as an alternative way to use the interface. 
If this alternative is audio via private headset, some low vision users will benefit from the possib ility to change 
the volume.  DKS 2952 -1: 2021  
© KEBS 2021 – All rights reserved  83  
  
Bibliography  
 
 
 
[1] ETSI/CEN/CENELEC TR 101 550: "Documents relevant to EN 301 549 "Accessibility requirements 
suitable for public procurement of ICT products and services in  Europe"".  
 
[2] ETSI/CEN/CENELEC TR 101 551: "Guidelines on the use of accessibility award criteria suitable for 
public procurement of ICT products and services in  Europe".  
 
[3] ETSI TR 102 612: "Human Factors (HF); European accessibility requirements for public procurement 
of products and services in the ICT domain (European Commission Mandate M 376, Phase  1)". 
 
[4] ETSI TS 126 114: Universal Mobile Telecommunications System (UMTS); LTE; 5G; IP Multimedia 
Subsystem (IMS); Multime dia telephony; Media handling and interaction (3GPP TS  26.114).  
 
[5] ETSI TS 122 173: Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile 
Telecommunications System (UMTS); LTE; IP Multimedia Core Network Subsystem (IMS) Multimedia 
Telephony Service and supplementary services; Stage 1 (3GPP TS  22.173).  
 
[6] ETSI TS 134 229: Universal Mobile Telecommunications System (UMTS); LTE; Internet Protocol (IP) 
multimedia call control protocol based on Session Initiation Protocol (SIP) and Session De scription 
Protocol (SDP); User Equipment (UE) conformance specification (3GPP TS  34.229).  
 
[7] ISO/IEC 17007, Conformity assessment - Guidance for drafting normative documents suitable for use 
for conformity  assessment".  
 
[8] ISO 9241 -11: "Ergonomics of human -system interaction - Part 11: Usability: Definitions and  concepts".  
 
[9] ISO 9241 -110:2006: "Ergonomics of human -system interaction - Part 110: Dialogue  principles".  
 
[10] ISO 9241 -171:2008: "Ergonomics of human -system interaction - Part 171: Guidance on software 
accessibility".  
 
[11] ISO/IEC 13066 -1:2011: "Information technology - Interoperability with assistive technology (AT) - Part 
1: Requirements and recommendations for  interoperability".  
 
[12] Recommendation ITU -T E.161 (2001): Arrangement of digits, letters and symbols  on telephones and 
other devices that can be used for gaining access to a telephone  network.  
 
[13] Recommendation ITU -T G.722 (1988): "7 kHz audio -coding within 64  kbit/s".  
 
[14] Recommendation ITU -T G.722.2 (2003): "Wideband coding of speech at around 16 kbit/s usi ng 
Adaptive Multi -Rate Wideband  (AMR -WB)"  
 
[15] ETSI/CEN/CENELEC EN 301 549 (V2.1.2) (August 2018): "Accessibility requirements for ICT  
products and  services".  
 
[16] ETSI/CEN/CENELEC TR 101 552: "Guidance for the application of conformity assessment to 
accessibility requirements for public procurement of ICT products and services in  Europe".  
 
[17] ISO/IEC TS 20071 -25:2017: "Information technology - User interface component accessibility - Part 
25: Guidance on the audio presentation of text in videos, includin g captions, subtitles and other on - 
screen  text".  
 
[18] ISO/IEC Guide 71:2014: "Guide for addressing accessibility in  standards".  
 
[19] Recommendation ITU -T T.140 (1988): "Protocol for multimedia application text  conversation".  84 © KEBS:2021: – All rights reserved   
 [20] Recommendation ITU -T F.703 (2000): "Multimedia conversational  services".  
 
[21] The Authoring Tool Accessibility Guidelines (ATAG)  2.0 
 
 
 
 
 
 
 
  
   
 KS 2952 -1: 2021  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
© KEBS 2021 – All rights reserved  