LETTER OF INTEREST
6 |ACCESSIBILITY PROCUREMENT PILOT ON BEHALF OF
7 |TREASURY BOARD OF CANADA SECRETARIAT
8 | 9 | 10 | ## 1. PURPOSE 11 | 12 | The purpose of this Letter of Interest (LOI) is to notify industry of GC’s intention to: 13 | - issue a Call for Proposals (CFP) in relation to the Treasury Board of Canada Secretariat’s Open by Default Pilot Portal; 14 | - to provide advance notice of the challenges for which GC intends to seek proposals; and 15 | - to provide industry the opportunity to give written feedback on the requirement and procurement strategy. 16 | 17 | GC is looking to partner more closely with leading innovators in GC and abroad to help address accessibility issues specifically relating to documents on the Open by Default Pilot Portal, which is housed on the open government website, Open.canada.ca (“Open Government website”). 18 | 19 | ## 2. BACKGROUND 20 | 21 | The Government of Canada (“GC”) is committed to advancing openness and transparency. Governments today face barriers to being completely open to all Canadians. About 14% of Canadians report having a disability that limits day-to-day activities. With an aging population, this percentage will likely increase. Many Canadians also live with invisible disabilities. Others may not wish to report having one. GC faces a clear imperative to be inclusive. For a multitude of reasons we must work to remove barriers to persons with disabilities in this country. 22 | 23 | The accelerating pace of digital change means that new tools are being introduced. Most do so without consideration for accessibility, others are focus on enhancing it. Accessibility issues can be both varied and complex. Emerging approaches show promise in helping to reduce barriers. GC is committed to raising the bar on accessibility to be an international leader for equality and human rights. 24 | 25 | 26 | ### 2.1 EXISTING WEB STANDARDS, GUIDANCE, AND RESOURCES 27 | 28 | The GC Open Government committments rely on open standards, of which the following shoul be considered for this project. 29 | 30 | These are the guidelines currently required for GC websites: 31 | - GC Standard on Web Accessibility – A Government of Canada standard for websites and web applications - https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=23601 32 | - GC Guidance on Implementing the Standard on Web Accessibility – Assists departments by providing tools, solutions and guidance - https://www.canada.ca/en/treasury-board-secretariat/services/government-communications/guidance-implementing-standard-web-accessibility.html 33 | - World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0 - the international 2008 standard for web accessibility. Governments around the world have adopted WCAG 2.0 AA as the goal for most web sites. https://www.w3.org/WAI/intro/wcag 34 | - GC’s Web Experience Toolkit - http://wet-boew.github.io/wet-boew/ 35 | - Other relevant policies to GC’s Web presence - https://www.tbs-sct.gc.ca/pol/index-eng.aspx 36 | 1. Directive on the Management of Communications 37 | 2. Directive on Official Languages for Communications and Services 38 | 3. Standard on Web Interoperability 39 | 4. Standard on Web Usability 40 | 5. Standard on Optimizing Websites and Applications for Mobile Devices 41 | 6. Policy on Government Security 42 | 43 | Like all digital medium itself, change is inevitable. GC takes inspiration from internationally recognized standards that support an improved user experience for all users. 44 | 45 | Where possible, the project should take into consideration the best practices outlined in these open standards: 46 | - W3C WCAG 2.0 AAA - these guidelines were designed to be aspirational. Where possible see if it is possible to leverage these guidelines. 47 | - W3C Authoring Tool Accessibility Guidelines (ATAG) 2.0 - This 2015 guideline is in two parts. Part A asks that the authoring experience meets WCAG 2.0 guidelines. Part B supports the production of more accessible web content through better software. 48 | - W3C WCAG 2.1 W3C Working Draft - Although still a Working Draft, this revision of the Web Content Accessibility Guidelines 2.0, is working to provide better access for a broader range of people. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0, and therefore to policies that reference WCAG 2.0 - https://www.w3.org/TR/WCAG21/ 49 | - European Union EN 301 549 – A European Union initiative for public procurement for improving accessibility of information and communications technology (ICT) products and services. Specifies the functional accessibility requirements applicable to ICT products and services. Each accessibility requirement includes a description of the test procedures and evaluation methodology - http://mandate376.standards.eu/standard 50 | 51 | 52 | ## 3. REQUIREMENT 53 | 54 | - Any Solution proposed must be open source software (OSS) solution. 55 | - Unless specified otherwise, all written communications will be in an electronic and accessible format. Acceptable formats include .txt, .odf, .doc(x) and .epub. If properly tagged for accessibility .pdf will be accepted. 56 | - Responses must be in either English or French, at the preference of the Respondent. 57 | 58 | ### 3.1 TBS - OPEN BY DEFAULT PILOT PORTAL (CHALLENGE 1) 59 | 60 | The Challenge for which Solutions will be sought on behalf of TBS is described in Attachment 3, Statement of Work for Open by Default Pilot Portal Challenge. Please note Attachment 3 is a draft document and is subject to change. 61 | 62 | ## 4. PROCESS 63 | 64 | ### General 65 | - All communications will be available in French and English and will be provided in an accessible format. 66 | - All formal communications and ammendments will be made through the Buy and Sell website - https://buyandsell.gc.ca/ 67 | 68 | ### LOI Process 69 | - GC issues a LOI to get express interest in the pilot. 70 | - Industry submits letters - See Attachment 2 for more detail. 71 | - Submissions should be sent directly to the Contracting Authority on or before December 12, 2017 at 14h00 EST. 72 | - GC reserves the right to request additional information for clarification after submission. 73 | - No payment will be made for costs incurred in this phase. 74 | - GC is under no obligation enter into any agreement or to accept any suggestions from industry. 75 | - This industry consultation process is not a solicitation and a contract will not result from this request. 76 | - More information is availabe in Attachment 2 - Industry Engagement Questions 77 | 78 | ### Planned CFP Process 79 | - GC issues CFP with input received from Industry. 80 | - CFP will include assessment criteria that are both mandatory and point-rated. 81 | - Proposals which meet all mandatory criteria and the minimum point-rated criteria score will be placed in a pool of pre-qualified proposals, provided that the total evaluated price does not exceed the budget available for the requirements. 82 | - More details of the process are defined in Appendix 3. 83 | 84 | The proposed contract will include three 3 Phases. In Phase 1 each Contractor will be required to: 85 | - demonstrate a functional prototype of their Solution (defined as a minimum viable demonstration of capability). 86 | - The presentation to a panel anticipated to be held in Shawinigan, Quebec in mid-March 2018. Reasonable expenses for attending the panel presentation will be covered, see Appendix 3 Section 4.1.2 for details. 87 | - The maximum funding available for Phase 1 of any contract resulting from this CFP is $15,000.00, applicable Taxes excluded. The expenses associated with attending the panel are excluded from this cap. 88 | 89 | The maximum funding available for all phases of any contract resulting from this CFP is $320,000 for the Open by Default accessibility challenge, applicable taxes and travel and living expenses are excluded. 90 | 91 | ## 5. GOVERNMENT OF CANADA APPLICABLE POLICIES 92 | 93 | All Bidders responding to the resulting CFP must be in possession of a Procurement Business Number (PBN) which can be obtained through the Supplier Registration Information System - https://srisupplier.contractscanada.gc.ca 94 | 95 | All responses to CFPs require that the Legal Name of the business and PBN are clearly included. 96 | 97 | These policies apply: 98 | - The Code of Conduct for Procurement and Public Services - https://www.tpsgc-pwgsc.gc.ca/apropos-about/code-cond-eng.html 99 | - Procurement Canada’s Integrity Provisions - https://www.tpsgc-pwgsc.gc.ca/ci-if/ci-if-eng.html 100 | 101 | ## 6. LICENCING 102 | 103 | Solutions developed (not pre-existing) for either challenge must be licenced under the MIT Licence. Where Bidders or Contractors are leveraging existing open source projects, adopting the parent licence of the open source software project is preferred, where the licence is approved by the Open Source Institute (OSI). A list of OSI approved licences is available at - https://opensource.org/licenses/alphabetical 104 | 105 | Under any contract resulting from the CFP, the Contractor will be required to deposit the Solution’s source code in a public facing repository on the GitHub platform - https://github.com - under an open source license as specified above. 106 | 107 | The Contractor must create and maintain a public repository for the project on GitHub during the period of the Contract. All updates to the Solution source code must be deposited on GitHub, as well as, the final Solution source code. Before the final payment, the ownership of the code should be transferred to https://github.com/canada-ca - this will enable anyone to subscribe to notifications of changes while also allowing for conversations, issue tracking, and code reviews. 108 | 109 | Should accessibility issues be found "up-stream" in libaries used by the project, efforts should be made to ensure that: 110 | - a search is done to confirm that the community knows about the problem 111 | - patches supplied by the community are tested, if they resolve the pattern, then this should be added to the issue queue before the project is finalized. 112 | - if no patch is available, but one is generated on behalf of the contract, that should be submitted to the parent project 113 | - all of this should be documented for the GC 114 | 115 | ## 7. CONTRACTING AUTHORITY 116 | 117 | All enquiries and communication with the Government regarding GC’s requirement under this LOI must be directed in writing to the Public Services and Procurement Canada Contracting Authority as detailed below. Any clarification or information received from other Government officials will not be considered as an official response. 118 | 119 | Heather Wilson 120 | Supply Team Leader 121 | Public Services and Procurement Canada 122 | Telephone: 873-469-4791 123 | E-mail: TPSGC.paouvertpardefaut-apopenbydefault.PWGSC@tpsgc-pwgsc.gc.ca 124 | 125 | ------------------- 126 | 127 | # ATTACHMENT 1 128 | 129 | ## RULES OF ENGAGEMENT PARTICIPATION AGREEMENT 130 | 131 | An overriding principle of the industry consultation is that it be conducted with the utmost of fairness and equity between all parties. No one person or organization will receive nor be perceived to have received any unusual or unfair advantage over the others. 132 | 133 | ## TERMS AND CONDITIONS: 134 | 135 | The following terms and conditions apply to the Consultative Process. In order to encourage open dialogue, 136 | Participants agree to: 137 | 138 | a. Discuss their views concerning the requirement and to provide positive resolutions to the issues in question. Everyone will have equal opportunity to share their ideas and suggestions; 139 | 140 | b. NOT reveal or discuss any information to the MEDIA/NEWSPAPER regarding the requirement during this consultative process. Any Media questions will be directed to the PWGSC Media Relations Office at 819-956-2313; 141 | 142 | c. Throughout the entire Consultative Process, all questions from industry, exchanges of information and all the industry feedback must be provided in writing to the Contracting Authority. In accordance with and subject to the Access to Information Act, R.S., 1985, c. A-1, and any other legislative or legal requirement. All information which is provided by a Participant and which is clearly marked as “Proprietary” will not be released or disclosed; 143 | 144 | d. GC is not obligated to issue any CFP, or to negotiate any contract for the requirement; 145 | 146 | e. If GC does release a CFP, the terms and conditions of the CFP will be subject to GC's absolute discretion; 147 | 148 | f. The information gathered from the written responses will be summarized and provided to all Participants, with the exception of proprietary or confidential materials; 149 | 150 | g. GC will not reimburse any person or entity for any cost incurred in responding to the LOI; 151 | 152 | h. Participation in this Consultative Process will not be a mandatory requirement for any subsequent CFP. An entity will not be precluded from submitting an proposal under any subsequent CFP on account of they not being a Participant; 153 | 154 | i. At any point within this process, a Participant may provide notice to the Contracting Authority that they no longer wish to participate in the Consultative Process. 155 | 156 | j. Failure to agree to and sign the Rules of Engagement Participation Agreement will result in the exclusion from participation in the consultative process. This Rules of Engagement Participation Agreement must be signed by a duly authorized officer of the Participant in this respect; 157 | 158 | k. A dispute resolution process to manage impasses throughout this Consultative Process must be adhered to as follows: 159 | 160 | 161 | ## DISPUTE RESOLUTION PROCESS 162 | 163 | 1. By informal discussion and good faith negotiation, each of the parties must make all reasonable efforts to resolve any dispute, controversy or claim arising out of or in any way connected with this Consultative Process. 164 | 165 | 2. Any dispute between the Parties of any nature arising out of or in connection with this Consultative Process must be resolved by the following process: 166 | 167 | a. Any such dispute must first be referred to the Participant's Representative and the PWGSC Manager managing the Consultative Process. The parties will have 3 Business Days in which to resolve the dispute. 168 | 169 | b. In the event the representatives of the Parties specified in Article 2.a. above are unable to resolve the dispute, it will be referred to the Participant's Project Director and the PWGSC Seni or Direct or of the Division responsible to manage the Consultative Process. The parties will have 3 Business Days to resolve the dispute. 170 | 171 | c. In the event the representatives of the Parties specified in Article 2.b. above are unable to resolve the dispute, 172 | it will be referred to the Participant's legal Signing Authority and the PWGSC Director General, who will have 3 Business Days to resolve the dispute. 173 | 174 | d. In the event the representatives of the Parties specified in Article 2.c. above are unable to resolve the dispute, it will be referred to the Participant's legal Signing Authority and the PWGSC Assistant Deputy Minister, Acquisitions Branch who will have 10 Business Days to resolve the dispute. 175 | 176 | e. In the event the representatives of the Parties specified in Article 2.d. above are unable to resolve the dispute, the Contracting Authority will within 5 Business Days render a written decision which will include a detailed description of the dispute and the reasons supporting the Contracting Authority's decision. The Contracting Authority will deliver a signed copy thereof to the Participant. 177 | 178 | By signing this document, the individual represents that he/she has full authority to bind the company listed below and that the individual and the company agree to be bound by all the terms and conditions contained herein. 179 | 180 | 181 | Name of Company (Print): 182 | ____________________________ 183 | Name of individual (Print): 184 | ____________________________ 185 | Title or Position (Print): 186 | ____________________________ 187 | Telephone: 188 | ____________________________ 189 | E-mail: 190 | ____________________________ 191 | Signature: 192 | ____________________________ 193 | (I have the authority to bind the Company) 194 | Date: 195 | ___________________________ 196 | 197 | 198 | 199 | 200 | # ATTACHMENT 2 201 | 202 | ## INDUSTRY ENGAGEMENT QUESTIONS 203 | 204 | The questions contained in the sections below are intended to elicit feedback of interest to GC and provide guidance to industry in preparing written responses. It is not expected that all questions will elicit a response, neither should submissions be constrained by the questions. 205 | 206 | Respondents are encouraged to submit a response to the Industry Engagement Questions in an accessible, unrestricted electronic format (Text, Open Document Format or EPUB are preferabley) by the LOI closing date. 207 | 208 | ## 1. RESPONSE FORMAT 209 | 210 | The Respondent’s name, company, address, and contact information and the LOI number should be clearly visible in the response. 211 | 212 | The response is to be submitted by e-mail to the Contracting Authority. 213 | 214 | Only include general marketing material unless it provides specific information relevant to a response. If it is included the supporting text in the LOI should cross-reference the marketing material. 215 | 216 | Only written LOI presentations can be submitted and responses will not be returned. 217 | 218 | Please keep the length of your response to under 2500 words, plus the signed copy of the Rules of Engagement Participation Agreement (as per Attachment 1). These can be provided as a PDF file to allow for analog signatures. 219 | 220 | ## 2. RESPONSE PARAMETERS 221 | 222 | Respondents are reminded that this is an LOI and not a CFP and, in that regard, Respondents should feel free to provide their comments and concerns with their responses. 223 | 224 | GC reserves the right to seek clarifications from a Respondent for any information provided in response to this LOI, either by telephone, in writing or in person. 225 | 226 | ## 3. CONFIDENTIALITY 227 | 228 | Respondents are requested to clearly identify those portions of their response that are company confidential or proprietary in nature. The confidentiality of each Respondent’s response will be maintained. Items that are identified as proprietary will be treated as such except where GC determines that the enquiry is not of a proprietary nature. GC may edit the questions or may request that the respondent do so, so that the proprietary nature of the question is eliminated, and the enquiry can be answered with copies to all interested parties. 229 | 230 | ### SECTION 2: REQUIREMENT 231 | 232 | 1. Following the Planned CFP Process outlined above, GC is seeking feedback in the LOI as to whether: 233 | 234 | a. three weeks is enough time to develop a working prototype for the presentation. 235 | 236 | b. $15,000 is an appropriate amount to develop a working prototype as described above. 237 | 238 | c. the description of the working prototype is sufficiently clear to prepare the demonstration? 239 | 240 | 2. In your view, are there problems with what has been outlined in the Letter of Interest? 241 | 242 | 3. The Statement of Work in Attachment 3 provides a number of examples. We want to know if you consider them technically feasible? 243 | 244 | 3. Do you have concerns with any of the proposed deliverables in either of the Statements of Work? 245 | 246 | 4. Please provide any additional feedback that you think will help increase the impact of this LOI. 247 | 248 | 5. Tell us if you are potentially interested in bidding on the CFP when it is released. 249 | 250 | 251 | Common Footer: 252 | 253 | Accessibility Procurement Pilot 254 | Letter of Interest 255 | Public Services and Procurement Canada 256 | LOI # 24062-180181/A 257 | 258 | 259 | 260 | ------------------- 261 | 262 | 263 | # Attachment 3 264 | 265 | Statement of Work for Open by Default Pilot Portal Challenge 266 | 267 | ## 1. Introduction 268 | 269 | The Government of Canada has outlined commitments to advance openness and transparency through Action Plans on Open Government submitted to the Open Government Partnership since 2012. One of the core mandates expressed in these action plans is to advance openness through the open government website - https://open.canada.ca 270 | 271 | The Open Government website was initially launched as a pilot, data.gc.ca, in 2011. The pilot open data portal then expanded to include various information resources and to facilitate engagement on the open government initiative and associated activities. In keeping with GC’s initial strategy on open government, the current Open Government website’s architecture is built around the pillars of open data, open information and open dialogue, and its infrastructure is built on open source solutions: CKAN, Drupal 7 and Apache Solr. As GC continues to advance the open government initiative and to release a growing number of resources, it has become apparent that the accessibility of content needs to be improved. There is also a desire to do more in terms of engaging with users and visitors through the Open Government website. 272 | 273 | GC is committed to removing barriers to access for Government information and services. With that in mind, GC is mandated to ensure that all websites and web applications adhere to Web Content Accessibility Guidelines (WCAG) 2.0 AA. 274 | 275 | New resources of information are constantly being added to the Open Government website and the future vision is for it to become a hub of data, information and opportunities to participate and learn. Early research indicates that a majority of users are seeking data of one type or another, with a smaller but significant group looking for opportunities to participate or engage with government. 276 | 277 | As GC’s work on open government advances, there are opportunities to improve the user experience of its online tools, including improving access to digital publications and draft documents made available by the Government of Canada. 278 | 279 | ## 2. Background 280 | 281 | ### 2.1 The Open by Default Pilot Portal (http://pilot.open.canada.ca/open-by-default-pilot) 282 | 283 | The new Open by Default Pilot Portal (Pilot Portal) is the latest component of the Open Government website. This is an online beta site where non-sensitive federal working documents available to the public. This provides users with insight into what Government of Canada employees are working on. The Open by Default Pilot Portal leverages existing operational systems that power open.canada.ca. In the pilot these include CKAN, Drupal 8 and Apache Solr. It also leverages GCDocs, an internal records management tool. The technical architecture of the Open by Default Pilot Portal, mirrors that of the Open Government Portal. Instructions to build the environment will be provided as well as all source code for the architecture. Currently all code for this project is available on GitHub - https://github.com/open-data 284 | 285 | The Pilot Portal consolidates draft documents (“Digital Assets”) provided by pilot departments. The current departments are Natural Resources Canada, Canadian Heritage, Environment and Climate Change Canada, and the Treasury Board of Canada Secretariat. The Digital Assets in the pilot may not comply with web accessibility standards. 286 | 287 | Currently, the Pilot Portal contains approximately 550 Digital Assets. These are in common open formats such as .odf, .csv, .svg, .shp, but also standard Microsoft & Adobe file formats. The collection contains draft policies, internal draft documentation on systems, and presentations. It is expected that future Digital Assets holdings on the portal could be expanded to include audio and video formats. It is also expected that collection could include 100,000s of Digital Assets. 288 | 289 | ## 3. Challenge 290 | 291 | TBS has a requirement for an open source software solution (“Solution”) (existing or developmental but not proprietary) to enhance and improve the accessibility of both current and future Digital Assets housed on the Open by Default Pilot Portal. Proposed Solutions must also be compatible with the Open Government website’s existing digital infrastructure. 292 | 293 | The following illustrative list provides examples of accessibility issues Solutions may address in responding to the challenge. This list is non-exhaustive. All Solutions should assume bilingual content. These are examples of Solutions that may be addresed in the CFP. Ability of the system to: 294 | - automatically flag Digital Assets when they fail to meet WCAG 2.0 AA. This system should allow for marking WCAG 2.1 and/or EN 301 549 requirements when they become available. It is understood that the best automated tests presently catch about 25% of WCAG 2.0 AA errors. 295 | - ensure Digital Assets available through the Open by Default Pilot Portal should be able to be converted into a in a variety of formats such as EPUB3, and ODF; 296 | - provide for all Digital Assets an embed an accessibility compliance report against WGAC 2.0 AA standards as well as other web accessibility standards; 297 | - programmatically suggest alternative text for images (.gif, .png, .svg, and .jpg). 298 | - programmatically generate transcripts of voice audio recordings; 299 | - programmatically generate described video, transcripts, closed captioning for video content created in both official languages; 300 | - programmatically generate animated American Sign Language or Quebec Sign Language from spoken word audio or video; 301 | - programmatically assign and display Flesch-Kincaid (or similar) readability tests to determine approximate grade level for English content or Scolarius score for French content; 302 | - conform to ATAG 2.0 Part B where editors are encouraged to adopt best practices while generating content, such that it is easier to comply with WCAG 2.0 AA. Where possible also conform to WCAG 2.1 and/or EN 301 549. 303 | 304 | ## 4. Scope 305 | 306 | ### 4.1 Phase 1 307 | 308 | #### 4.1.1 Finalization of Draft Design and Implementation Plan 309 | 310 | Within 10 working days of the Contract being awarded, the Technical Authority will provide any comments electronically that it has regarding the draft design and implementation plan submitted by the Contractor as part of its bid. The Contractor must update its Design and Implementation Plan to reflect Technical Authority's comments and resubmit it electronically to Technical Authority for approval within 5 working days. 311 | 312 | The Design and Implementation Plan must specify the delivery dates for all deliverables identified in Phases 2 and 3. 313 | 314 | There will be at least 15 working days following the approval by the Technical Authority before the Contractor may be required to present. Contractors who are invited to present are expected to include a demonstration of a working prototype of the proposed Solution (i.e., a preliminary version of the Solution with basic functionality). 2 days prior to the presentation: 315 | - the code must be uploaded to the public GitHub repository and ready for the demonstration phase. 316 | - the presentation to include a Microsoft PowerPoint (.ppt) or Open Office Impress (.sxi) format and a demonstration of the prototype delivered to the Technical Authority. 317 | 318 | #### 4.1.2 Demonstration 319 | 320 | The Contractor must demonstrate the basic functionality of Solution including at a minimum an early stage functional prototype (defined as a minimum viable demonstration of capability) to the Technical Authority and representatives of GC, in person at a location to be determined by the Technical Authority. 321 | 322 | At a minimum the presentation must include: a functionality demonstration of the prototype of the Solution and an overview of the Contractor’s proposed design and implementation plan for Phase 2 and 3. The presentation should also include an overview of the Innovativeness, Scalability, Accessibility and Functionality of the proposed Solution. 323 | 324 | The prototype must demonstrate the ability to improve the accessibility of Digital Assets in relation to at least one of the accessibility issues proposed to be addressed in the Contractor’s draft Design and Implementation Plan. 325 | 326 | An independent panel will observe the presentation and convene to determine whether to move forward with Phases 2 and 3 of the Contract. 327 | 328 | The Contractor will be reimbursed its authorized travel and living expenses reasonably and properly incurred in the performance of the Work, at cost, without any allowance for profit and/or administrative overhead, in accordance with the meal, private vehicle and incidental expenses provided in Appendices B, C and D of the National Joint Council Travel Directive and with the other provisions of the directive referring to "travellers", rather than those referring to "employees". 329 | 330 | All travel must have the prior authorization of the Technical Authority. 331 | 332 | #### 4.1.3 Financial Proposal 333 | 334 | The Contractor must provide a Financial Proposal for Phases 2 and 3 of the Work in accordance with Annex B, Basis of Payment. The Financial Proposal for Phases 2 and 3 will be subject to negotiation with GC. Upon GC’s request, the Contractor must provide Price Support for the Financial Proposal for Phases 2 and 3, which may include; a current published price list indicating the percentage discount available to GC; or copies of paid invoices for the like quality and quantity of the goods, services or both sold to other customers; or price or rate certifications; or any other supporting documentation as requested by GC. 335 | 336 | The Financial Proposal for Phases 2 and 3 must include the following information, as applicable, for each element of the Work: 337 | 338 | a) Labour: For each individual and (or) labour category to be assigned to the Work, indicate: 339 | i) the hourly rate, inclusive of overhead and profit; and 340 | ii) the estimated number of hours. 341 | 342 | b) Materials and Supplies: Identify each category of materials and supplies required to complete the Work and provide the pricing basis. 343 | 344 | c) Subcontracts: Identify any proposed subcontractor and provide for each one the same price breakdown information as contained in this article. 345 | 346 | d) Other Direct Charges: Identify any other direct charges anticipated, such as long distance communications and rentals, and provide the pricing basis. 347 | 348 | e) Profit: Identify proposed profit, if any, and the basis on which it is computed and applied. 349 | 350 | f) Overhead: State the applicable overhead. 351 | 352 | g) Applicable Tax: Identify any Applicable Tax separately. 353 | 354 | Due date: Within 15 working days of Contract award 355 | 356 | ### 4.2 Phase 2 (Conditional) 357 | 358 | Following the evaluation process, GC intends to award a contract to the three top ranked bidders from the pool of pre-qualified proposals. 359 | 360 | #### 4.2.1 Development and Testing 361 | 362 | ##### 4.2.1.1 Test Plan 363 | 364 | The Contractor must provide a Test Plan to the Technical Authority following commencement of Phase 2. The test plan must demonstrably exercise all new functionality of the Solution. The Test Plan must be in the form of a MS Excel spreadsheet that documents each test case, and include, at a minimum: 365 | - A test case number; 366 | - Step-by-step instructions for testers to complete each test case; 367 | - Success criteria for each test case; 368 | - Description of the functionality the test case addresses; 369 | - Fields next to each test case for testers to compile testing notes/results; 370 | - Test data; and 371 | - Exit criteria. 372 | 373 | ##### 4.2.1.2 Baseline testing 374 | 375 | The Contractor must execute the test plan, in order to establish a performance baseline of the functionality of the Solution, and update and resubmit the Design and Implementation Plan to the Technical Authority for approval as necessary. 376 | 377 | ##### 4.2.1.3 Development and Debugging 378 | 379 | The Contractor must correct software defects identified during the baseline testing and update the Solution source code. The Contractor must provide a Defect Debugging Report to Technical Authority documenting the defects, and their corrections. 380 | 381 | ##### 4.2.1.4 Standards Compliance testing 382 | The Solution must comply with Government of Canada Standards for Web Accessibility and Web Security. GC will test the Solution for compliance with these standards. The Technical Authority will provide detailed feedback to the Contractor on any issues revealed by compliance testing. The Contractor must resolve the issues in the source code revealed by compliance testing and update the Solution source code. 383 | 384 | Evidence of user testing, debugging, testing for accessibility and security, and an 385 | updated Design and Implementation Plan (if applicable) must be provided to the Technical Authority for approval. 386 | 387 | ##### 4.2.1.5 Deliverable(s): 388 | 389 | 1. Test Plan, 390 | 1. Defect Debugging Report, 391 | 1. Evidence of baseline testing, debugging, and resolution of compliance testing issues, 392 | 1. Updated Design and Implementation Plan (if applicable), 393 | 1. Updated Source Code (if applicable). 394 | 395 | Due date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 396 | 397 | #### 4.2.2 Unit and Integration Testing 398 | 399 | ##### 4.2.2.1 Unit Testing 400 | 401 | The Contractor must perform unit testing and integration testing of the Solution with the Open Government website infrastructure and update the Design and Implementation Plan. The Contractor must perform all unit and integration testing in their own environment. 402 | 403 | Where possible, the Contractor is expected to build unit tests for all new code developed. The Contractor must resolve any issues revealed by the automated unit tests and update Solution source code. The Contractor must provide a report electronically to the Technical Authority detailing the results of all automated unit testing. 404 | 405 | ##### 4.2.2.2 Integration Testing 406 | 407 | The Contractor must perform integration testing on its own system, resolve any issues revealed through integration testing and update the Solution source code. GC will provide the Contractor with a free image of Oracle's VirtualBox with the Open by Default Portal configuration allowing the Contractor to configure their environment for integration testing. 408 | 409 | As a final test the Contractor must provide instructions and the updated source code for GC to install and test the code on an open.canada.ca development environment. The Contractor must provide a report to the Technical Authority detailing the results of their internal integration testing and the instructions for GC to install and test the source code in the development environment. 410 | 411 | In accordance with timelines to be established in the Design and Implementation Plan, The Technical Authority will provide detailed feedback to the Contractor on any issues revealed by its own integration testing. The Contractor must resolve the issues revealed and resubmit the updated source code to the Technical Authority for re-testing. 412 | 413 | ##### 4.2.2.3 Deliverable(s): 414 | 415 | 1. Automated Unit Testing Report, 416 | 1. Contractor’s Integrated Testing Results Report, 417 | 1. Installation and Testing Instructions, 418 | 1. Evidence of unit testing and integration testing; 419 | 1. Updated Design and Implementation Plan (if applicable), 420 | 1. Updated source code (if applicable) 421 | 422 | Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 423 | 424 | #### 4.2.3 Progress Review Meetings 425 | The Contractor must be attend weekly progress review meetings by teleconference and provide updates to the Technical Authority on progress towards completion of the deliverables. Progress review meetings shall be scheduled by the Technical Authority, and all pertinent details such as teleconferencing information shall be provided to the Contractor by the Technical Authority not less than 24 hours in advance. The Contractor must respond to inquiries pertaining to the completion of deliverables on an ad hoc basis. 426 | 427 | The Contractor must prepare a Record of Discussion for each progress review meeting to the Technical Authority electronically within 48 hours of the progress review meeting. 428 | 429 | ##### Deliverable - Record of Discussion 430 | 431 | Due Date: within 48 hours of the progress review meeting 432 | 433 | ### 4.3 Phase 3 (Optional): 434 | 435 | #### 4.3.1 Implementation Support 436 | 437 | The Contractor will provide technical support to GC, as the Solution is implemented on the production environment. The Contractor must make resources with the knowledge required to implement the Solution on GC’s production environment available via telephone and email to GC during the implementation of the Solution. 438 | 439 | #### Deliverable(s) 440 | 441 | Professional services in the form of technical support to GC during the implementation of the Solution. 442 | 443 | Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 444 | 445 | #### 4.3.2 Software Documentation 446 | 447 | The Contractor must prepare all Software Documentation for the Solution and provide it electronically to the Technical Authority. 448 | 449 | ##### Deliverable(s) 450 | 451 | Software Documentation, consisting of, at a minimum, a technical specification for the Solution documenting the system architecture, subsystem design, and required configuration. 452 | 453 | Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 454 | 455 | #### 4.3.3 Progress Review Meetings 456 | 457 | The Contractor must be attend weekly progress review meetings by teleconference and provide updates to the Technical Authority on progress towards completion of the deliverables. Progress review meetings will be scheduled by the Technical Authority, and all pertinent details such as teleconferencing information will be provided to the Contractor by the Technical Authority not less than 24 hours in advance. The Contractor must respond to inquiries pertaining to the completion of deliverables on an ad hoc basis. 458 | 459 | The Contractor will prepare a Record of Discussion for each progress review meeting provide it to the Technical Authority electronically within 48 hours of the progress review meeting. 460 | 461 | ##### Deliverable - Record of Discussion 462 | 463 | Due Date: within 48 hours of the progress review meeting. 464 | 465 | ## 5. Constraints and Operational Environment 466 | 467 | The Solution must be compatible with the Open Government website’s existing digital infrastructure. See Appendix 1 to Attachment 3 attached. 468 | 469 | ### 5.1 Existing Open Government Website Digital Infrastructure 470 | 471 | The Open Government pilot site operates using the following open source tools, in compliance with the listed policies relating to websites for GC. 472 | - CKAN (Data Catalogue) [Python] – Licensed under the Affero GNU GPL v3.0 License; 473 | - Apache Solr (Search Engine) - Licensed under the Apache License 2.0; 474 | - Drupal 8 (Content Management System) [PHP] - Licensed under the GPL v2 License; 475 | - PostgreSQL (Relational Database Management System - Licensed under the Postgresql License. 476 | 477 | The Open Government website is currently housed on a mix of cloud and on premise infrastructure. Solutions must be compatible with infrastructure hosted on the Microsoft (MS) Azure cloud in the Canada Central or Canada East availability regions. 478 | 479 | ### 5.3 Design and Implementation Plan 480 | 481 | Updates to the Design and Implementation Plan must be approved by the Technical Authority. 482 | 483 | ## 6. Review and Acceptance 484 | 485 | ### 6.1 Software Deliverables 486 | 487 | Final acceptance of the software Solution will occur when all discrepancies, errors or other deficiencies identified in writing by the Technical Authority have been resolved, either through documentation updates, program correction or other methods approved by the Technical Authority. 488 | 489 | ### 6.2 Reports and Documentation Deliverables 490 | 491 | Reports and documentation deliverables will be accepted when all discrepancies, errors or other deficiencies identified in writing by the Technical Authority have been corrected. 492 | 493 | The Contractor must provide drafts all Reports and Documentation deliverables to the Technical Authority for review 10 business days prior to the specified due date. The Technical Authority will provide comments to the Contractor 5 business days prior to the due date. 494 | 495 | All of the Technical Authority's comments to deliverables must either be incorporated in the succeeding version of the deliverable or the Contractor must demonstrate to the Technical Authority’s satisfaction why such comments should not be incorporated. 496 | 497 | If the Contractor requires additional guidance to produce an acceptable deliverable, the Contractor must arrange a meeting with the Technical Authority. 498 | 499 | 500 | ## Current Infrastructure 501 | The Open by Default pilot is built on an infrastructure as described by the diagram below. 502 | 503 | Image missing 504 | 505 | 506 | 507 | 508 | ## Footer 509 | 510 | Accessibility Procurement Pilot 511 | Attachment 3 512 | Public Services and Procurement Canada 513 | LOI # 24062-180181/ 514 | 515 | -------------------------------------------------------------------------------- /Accessibility-Procurement-Pilot.md: -------------------------------------------------------------------------------- 1 | Taken from https://buyandsell.gc.ca/procurement-data/tender-notice/PW-17-00804940 loi_no_24062-180181_e.pdf & attachment_3_e.pdf 2 | 3 | # Accessibility Procurement Pilot 4 | 5 | LETTER OF INTEREST 6 | ACCESSIBILITY PROCUREMENT PILOT ON BEHALF OF 7 | TREASURY BOARD OF CANADA SECRETARIAT 8 | AND 9 | THE PUBLIC SERVICE COMMISSION OF CANADA 10 | 11 | 12 | ## 1. PURPOSE 13 | 14 | The purpose of this Letter of Interest is to notify industry, academia and other stakeholders of Canada’s intention to issue a Call for Proposals (CFP) in relation to the Treasury Board of Canada Secretariat’s Open by Default Pilot Portal and the Public Service Commission of Canada’s online recruitment system; to provide advance notice of the challenges (see section 3.1 for details of both challenges) for which Canada intends to seek proposals; and to provide industry the opportunity to give written feedback on the requirement and procurement strategy. The Rules of Engagement Participation Agreement for this activity are enclosed as Attachment 1 and the Industry Engagement Questions are enclosed as Attachment 2. 15 | 16 | ## 2. BACKGROUND 17 | 18 | The Government of Canada (“Canada”) has made commitments to advance openness and transparency in government. Today, however, the government faces barriers to being completely open to all Canadians. About 14% of the population reports having a disability that limits day-to-day activities and this percentage is projected to grow. Many Canadians also live with invisible disabilities and/or disabilities they don’t wish to report. Canada faces a clear imperative: to be inclusive, and to benefit from the contributions of citizens seeking to participate, government must continue to be fully accessible to persons with disabilities, both within government and in society more broadly. 19 | 20 | The accelerating pace of digital change means that new tools are constantly being developed to enhance web accessibility. Accessibility issues can be both varied and complex, as can be the efforts to address these issues; however, emerging technologies show promise in helping to promote accessibility and thereby advance user experiences, support inclusion and provide consistency with international and national equality 21 | and human rights instruments. 22 | 23 | Canada is looking to partner more closely with leading innovators in Canada and abroad to help address accessibility issues specifically relating to: 24 | 25 | - Documents on the Open by Default Pilot Portal, which is housed on the open government website, Open.canada.ca (“Open Government website”) as described in Attachment 3; and 26 | - Searching for and applying to federal government jobs as described in Attachment 4. 27 | 28 | ### 2.1 EXISTING WEB STANDARDS, GUIDANCE, AND RESOURCES 29 | 30 | For information, Canada uses the following resources to guide our web accessibility activities: 31 | - Standard on Web Accessibility – Ensures the uniform application of a high level of web accessibility across Government of Canada websites and web applications. 32 | - Guidance on Implementing the Standard on Web Accessibility – Assists Government of Canada departments by providing tools, solutions and guidance to advance Web accessibility. 33 | - Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. 34 | - Authoring Tool Accessibility Guidelines (ATAG) 2.0 - Provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities and designed to enable, support, and promote the production of more accessible web content by all authors. 35 | 36 | Beyond the guidance listed above, the Canada takes inspiration from internationally recognized standards that support an improved user experience for users with accessibility requirements. The following should also be considered when creating web experiences and content: 37 | - EN 301 549 – Accessibility requirements suitable for public procurement of ICT products and services in Europe – Specifies the functional accessibility requirements applicable to ICT products and services, together with a description of the test procedures and evaluation methodology for each accessibility requirement in a form that is suitable for use in public procurement within Europe. 38 | - Web Content Accessibility Guidelines (WCAG) 2.1 W3C Working Draft 12 September 2017 - 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. 39 | 40 | ## 3. REQUIREMENT 41 | 42 | The Treasury Board of Canada Secretariat (TBS) and the Public Service Commission of Canada (PSC) have separate requirements for proposals to address the long standing barrier of accessibility in support of the Open by Default Pilot Portal and of job seekers searching for and applying to government jobs, respectively. The two challenges for which an open source software solution (“Solution”) (existing or developmental but not proprietary) will be sought are identified below. 43 | 44 | Under the CFP, Bidders will be required to demonstrate how their proposed Solutions respond to and address one or both of the challenges. 45 | 46 | ### 3.1 TBS - OPEN BY DEFAULT PILOT PORTAL (CHALLENGE 1) 47 | 48 | The Challenge for which Solutions will be sought on behalf of TBS is described in Attachment 3, Statement of Work for Open by Default Pilot Portal Challenge. Please note Attachment 3 is a draft document and is subject to change. 49 | 50 | ### 3.2 PSC – ACCESSIBILITY 10.0 RECRUITM ENT CHALLENGE (CHALLENGE 2) 51 | 52 | The Challenge for which Solutions will be sought on behalf of PSC is described in Attachment 4, Statement of Work for Accessibility 10.0 Recruitment Challenge. 53 | 54 | Please note Attachment 4 is a draft document and is subject to change. 55 | 56 | ## 4. ACQUISITION STRATEGY 57 | 58 | It is anticipated t hat a CFP in French and English versions will be posted electronically on the Government Electronic Tendering Service (GETS), namely the Buy and Sell website (https://buyandsell.gc.ca/). 59 | 60 | This requirement is subject to Canadian Free Trade Agreement (CFTA), Comprehensive Economic and Trade Agreement (CETA), North American Free Trade Agreement (NAFTA), and the World Trade Organization’s Agreement on Government Procurement (WTO-AGP). 61 | 62 | ### 4.1 CFP PROCESS 63 | 64 | Proposals submitted under the CFP will be a ssessed against criteria tabled in the mandatory and point-rated evaluation criteria (to be detailed in the resulting CFP solicitation document). Proposals which meet all mandatory criteria and the minimum point-rated criteria score will be placed in a pool of pre-qualified proposals for each of the challenges, provided that the total evaluated price does not exceed the budget available for the requirements. 65 | 66 | 67 | Following the evaluation process, Canada intends to award a contract to the three top ranked bidders from the pool of pre-qualified proposals for each of the challenges. The proposed contract will include three 3 Phases, Phases 2 and 3 will be optional. Under Phase 1 of the resulting contract, each contractor will be required to demonstrate a functional prototype of their Solution (defined as a minimum viable demonstration of capability) at a presentation to a panel anticipated to be held in Shawinigan, Quebec in mid-March 2018. The panel will observe the presentations and may recommend Contractor(s) to proceed to Phase 2. 68 | 69 | The Contractor will be reimbursed its authorized travel and living expenses reasonably and properly incurred in the performance of the Work, at cost, without any allowance for profit and/or administrative overhead, in accordance with the meal, private vehicle and incidental expenses provided in Appendices B, C and D of the National Joint Council Travel Directive and with the other provisions of the directive referring to "travellers", rather than those referring to "employees". 70 | 71 | All travel must have the prior authorization of the Technical Authority. 72 | 73 | The maximum funding available for Phase 1 of any contract resulting from this CFP is $15,000.00, applicable Taxes excluded. 74 | 75 | The maximum funding available for all phases of any contract resulting from this CFP is $320,000 for the Open by Default accessibility challenge and $115,000 for the Accessibility 10.0 Recruitment challenge, applicable taxes and travel and living expenses are excluded. 76 | 77 | ## 5. GOVERNMENT OF CANADA APPLICABLE POLICIES 78 | 79 | Suppliers interested in doing business with the federal government are encouraged to register in the Supplier Registration Information System (https://srisupplier.contractscanada.gc.ca) to be assigned a Procurement Business Number (PBN). Bidders responding to the resulting CFP must be in possession of a PBN. 80 | 81 | The Canadian Content Policy does not apply to this requirement. 82 | 83 | The Code of Conduct for Procurement and Public Services and Procurement Canada’s Integrity Provisions will apply. The Contractor will own Intellectual Property Rights in Foreground Information. 84 | 85 | ## 6. LICENCING 86 | 87 | Solutions developed (not pre-existing) for either challenge must be licenced under the MIT Licence. Where Bidders are leveraging existing open source projects, adopting the parent licence of the open source software project is acceptable, where the licence is approved by the Open Source Institute. A list of approved licences is available at the following link: Open Source Licences (https://opensource.org/licenses/alphabetical). 88 | 89 | Under any contract resulting from the CFP, the Contractor will be required to deposit the Solution’s source code in a public facing repository on the Git Hub platform (https://github.com) – under an open source license as specified above. 90 | 91 | ## 7. REVIEW OF THE LOI 92 | 93 | Canada reserves the right to request additional information for clarification during the review of the responses to this LOI. 94 | 95 | No payment will be made for costs incurred in the preparation and submission of a response to the LOI. Costs associated with preparing and submitting a response, as well as any costs incurred by the respondent associated with the evaluation of the LOI, are the sole responsibility of the respondent. 96 | 97 | ## 8. NO OBLIGATION 98 | 99 | The issuance of this LOI does not create an obligation for Canada to issue a subsequent solicitation and does not bind Canada legally or otherwise, to enter into any agreement or to accept any suggestions from industry. 100 | 101 | This industry consultation process is not a solicitation and a contract will not result from this request. 102 | 103 | Potential respondents are advised that any information submitted to Canada in response to this industry consultation process may be used by Canada in the development of a subsequent competitive CFP. However, Canada is not bound to accept any expression of interest or to consider it further in any associated documents such as a CFP. 104 | 105 | ## 9. CLOSING DATE 106 | 107 | Responses to this LOI shall be submitted directly to the Contracting Authority on or before December 12, 2017 at 14h00 EST. 108 | 109 | ## 10. CONTRACTING AUTHORITY 110 | 111 | All enquiries and communication with the Government regarding Canada’s requirement under this LOI must be directed in writing to the Public Services and Procurement Canada Contracting Authority as detailed below. Any clarification or information received from other Government officials will not be considered as an official response. 112 | 113 | Heather Wilson 114 | Supply Team Leader 115 | Public Services and Procurement Canada 116 | Telephone: 873-469-4791 117 | E-mail: TPSGC.paouvertpardefaut-apopenbydefault.PWGSC@tpsgc-pwgsc.gc.ca 118 | 119 | 120 | # ATTACHMENT 1 121 | 122 | ## RULES OF ENGAGEMENT PARTICIPATION AGREEMENT 123 | 124 | An overriding principle of the industry consultation is that it be conducted with the utmost of fairness and equity between all parties. No one person or organization will receive nor be perceived to have received any unusual or unfair advantage over the others. 125 | 126 | ## TERMS AND CONDITIONS: 127 | 128 | The following terms and conditions apply to the Consultative Process. In order to encourage open dialogue, Participants agree to: 129 | 130 | a. Discuss their views concerning the requirement and to provide positive resolutions to the issues in question. Everyone will have equal opportunity to share their ideas and suggestions; 131 | 132 | b. NOT reveal or discuss any information to the MEDIA/NEWSPAPER regarding the requirement during this consultative process. Any Media questions will be directed to the PWGSC Media Relations Office at 819-956-2313; 133 | 134 | c. Throughout the entire Consultative Process, all questions from industry, exchanges of information and all the industry feedback must be provided in writing to the Contracting Authority. In accordance with and subject to the Access to information Act, R.S., 1985, c. A-1, and any other legislative or legal requirement, all information which is provided by a Participant and which is clearly marked as “Proprietary” will not be released or disclosed; 135 | 136 | d. Canada is not obligated to issue any CFP, or to negotiate any contract for the requirement; 137 | 138 | e. If Canada does release a CFP, the terms and conditions of the CFP will be subject to Canada's absolute discretion; 139 | 140 | f. The information gathered from the written responses will be summarized and provided to all Participants, with the exception of proprietary or confidential materials; 141 | 142 | g. Canada will not reimburse any person or entity for any cost incurred in participating in this consultative process; 143 | 144 | h. Participation in this Consultative Process will not be a mandatory requirement for any subsequent CFP. An entity will not be precluded from submitting an proposal under any subsequent CFP on account of they not being a Participant; 145 | 146 | i. A Draft Statement of Work will be available to industry. 147 | 148 | j. At any point within this process, a Participant may provide notice to the Contracting Authority that they no longer wish to participate in the Consultative Process. 149 | 150 | k. Failure to agree to and sign the Rules of Engagement Participation Agreement will result in the exclusion from participation in the consultative process. This Rules of Engagement Participation Agreement must be signed by a duly authorized officer of the Participant in this respect; 151 | 152 | l. A dispute resolution process to manage impasses throughout this Consultative Process must be adhered to as follows: 153 | 154 | 155 | ## DISPUTE RESOLUTION PROCESS 156 | 157 | 1. By informal discussion and good faith negotiation, each of the parties must make all reasonable efforts to resolve any dispute, controversy or claim arising out of or in any way connected with this Consultative Process. 158 | 159 | 2. Any dispute between the Parties of any nature arising out of or in connection with this Consultative Process must be resolved by the following process: 160 | 161 | a. Any such dispute must first be referred to the Participant's Representative and the PWGSC Manager managing the Consultative Process. The parties will have 3 Business Days in which to resolve the dispute. 162 | 163 | b. In the event the representatives of the Parties specified in Article 2.a. above are unable to resolve the dispute, it will be referred to the Participant's Project Director and the PWGSC Seni or Direct or of the Division responsible to manage the Consultative Process. The parties will have 3 Business Days to resolve the dispute. 164 | 165 | c. In the event the representatives of the Parties specified in Article 2.b. above are unable to resolve the dispute, 166 | it will be referred to the Participant's President and the PWGSC Director General, who will have 3 Business Days to resolve the dispute. 167 | 168 | d. In the event the representatives of the Parties specified in Article 2.c. above are unable to resolve the dispute, it will be referred to the Participant's CEO and the PWGSC Assistant Deputy Minister, Acquisitions Branch who will have 10 Business Days to resolve the dispute. 169 | 170 | e. In the event the representatives of the Parties specified in Article 2.d. above are unable to resolve the dispute, the Contracting Authority will within 5 Business Days render a written decision which will include a detailed description of the dispute and the reasons supporting the Contracting Authority's decision. The Contracting Authority will deliver a signed copy thereof to the Participant. 171 | 172 | By signing this document, the individual represents that he/she has full authority to bind the company listed below and that the individual and the company agree to be bound by all the terms and conditions contained herein. 173 | 174 | 175 | Name of Company (Print): 176 | ____________________________ 177 | Name of individual (Print): 178 | ____________________________ 179 | Title or Position (Print): 180 | ____________________________ 181 | Telephone: 182 | ____________________________ 183 | E-mail: 184 | ____________________________ 185 | Signature: 186 | ____________________________ 187 | (I have the authority to bind the Company) 188 | Date: 189 | ___________________________ 190 | 191 | 192 | # ATTACHMENT 2 193 | 194 | ## INDUSTRY ENGAGEMENT QUESTIONS 195 | 196 | The questions contained in the Sections below are intended to elicit feedback of interest to Canada and provide guidance to industry in preparing written responses. It is not expected that all questions will elicit a response, neither should submissions be constrained by the questions. 197 | 198 | Respondents are encouraged to submit a response to the Industry Engagement Questions in electronic format (MS Word or Adobe PDF preferable as long as copy/paste or printing of text functions are not restricted in any way) by the LOI closing date. 199 | 200 | ## 1. RESPONSE FORMAT 201 | 202 | The Respondent’s name, company, address, and contact information and the LOI number should be clearly visible in the response. The response is to be submitted by e-mail to the Contracting Authority, at the following address : TPSGC.paouvertpardefaut-apopenbydefault.PWGSC@tpsgc-pwgsc.gc.ca. 203 | 204 | The inclusion of general marketing material is discouraged unless used to provide specific information relevant to a response. In this instance, it is requested that supporting text cross-reference the marketing material to the appropriate area of the LOI. 205 | 206 | Oral presentations will not be entertained. 207 | 208 | Responses will not be returned. 209 | 210 | The number of pages of your response is not limited. However, the expected length should not exceed 3 pages double sided standard letter business format. 211 | 212 | ## 2. LANGUAGE OF RESPONSE 213 | 214 | Responses may be in English or French, at the preference of the Respondent. 215 | 216 | ## 3. RESPONSE PARAMETERS 217 | 218 | Respondents are reminded that this is an LOI and not a CFP and, in that regard, Respondents should feel free to provide their comments and concerns with their responses. 219 | 220 | Canada reserves the right to seek clarifications from a Respondent for any information provided in response to this LOI, either by telephone, in writing or in person. 221 | 222 | ## 4. CONFIDENTIALITY 223 | 224 | Respondents are requested to clearly identify those portions of their response that are company confidential or proprietary in nature. The confidentiality of each Respondent’s response will be maintained. Items that are identified as proprietary will be treated as such except where Canada determines that the enquiry is not of a proprietary nature. Canada may edit the questions or may request that the respondent do so, so that the proprietary nature of the question is eliminated, and the enquiry can be answered with copies to all interested parties. 225 | 226 | ### SECTION 1: ADM INISTRATIVE REQUIREM ENT SUMMARY 227 | 228 | 1. Identify your Legal Name and Procurement Business Number. 229 | 2. As per Attachment 1, please provide a signed copy of the Rules of Engagement Participation Agreement. 230 | 231 | ### SECTION 2: REQUIREMENT 232 | 233 | 1. Currently, three weeks have been allotted between when the c ont rac t ors are invited to present and the date of presentation. At this time, the presentation is expected to include a demonstration of a working prototype of the proposed Solution (i.e., a preliminary version of the Solution with basic functionality). 234 | 235 | a. We are seeking feedback from potential bidders as to whether three weeks is enough time to develop a working prototype for the presentation. 236 | 237 | b. We are seeking feedback from potential bidders as to whether three weeks $15,000 is an appropriate amount to develop a working prototype as described above. 238 | 239 | c. We are seeking feedback from potential bidders as to whether the description of the working prototype is sufficiently clear to prepare the demonstration? 240 | 241 | 2. In your view, are the challenges presented in the Letter of Interest technically feasible? 242 | 243 | 3. Do you have concerns with any of the proposed deliverables in either of the Statements of Work? 244 | 245 | 4. Please provide any additional feedback that you have. 246 | 247 | 248 | 249 | Common Footer: 250 | 251 | Accessibility Procurement Pilot 252 | Letter of Interest 253 | Public Services and Procurement Canada 254 | LOI # 24062-180181/A 255 | 256 | 257 | 258 | 259 | 260 | # Attachment 3 261 | 262 | Statement of Work for Open by Default Pilot Portal Challenge 263 | 264 | ## 1. Introduction 265 | 266 | The Government of Canada has outlined commitments to advance openness and transparency through Action Plans on Open Government submitted to the Open Government Partnership since 2012. One of the core mandates expressed in these action plans is to advance openness through the open government website, open.canada.ca. 267 | 268 | The Open Government website was initially launched as a pilot, data.gc.ca, in 2011. The pilot open data portal then expanded to include various information resources and to facilitate engagement on the open government initiative and associated activities. In keeping with Canada’s initial strategy on open government, the Open Government website’s architecture is built around the pillars of open data, open information and open dialogue, and its infrastructure is built on open source solutions: CKAN, Drupal and Solr. As Canada continues to advance the open government initiative and to release a growing number of resources, it has become apparent that the accessibility of content needs to be improved. There is also a desire to do more in terms of engaging with users and visitors through the Open Government website. 269 | 270 | Canada is committed to removing barriers to access for Government information and services. With that in mind, Canada is mandated to ensure that all websites and web applications adhere to the AA level of the Web Content Accessibility Guidelines 2.0, developed by the World Wide Web Consortium. These requirements are more specifically spelled out for application to Canada in the Standard on Web Accessibility. 271 | 272 | New resources of information are constantly being added to the Open Government website and the future vision is for it to become a hub of data, information and opportunities to participate and learn. Early research indicates that a majority of users are seeking data of one type or another, with a smaller but significant group looking for opportunities to participate or engage with government. 273 | 274 | As Canada’s work on open government advances, there are opportunities to improve the user experience of its online tools, including improving access to digital publications and draft documents made available by the Government of Canada. 275 | 276 | ## 2. Background 277 | 278 | ### 2.1 The Open by Default Pilot Portal (http://pilot.open.canada.ca/open-by-default-pilot) 279 | 280 | The Open by Default Pilot Portal, launched in July 2017, is the newest component of the Open Government website. It is an online beta site where various types of non-sensitive federal-level documents in draft format (i.e. working documents) are made publicly available, providing users with insight into what Government of Canada employees are working on (e.g., presentations, speaking notes, infographics, annual reports, etc.). The Open by Default Pilot Portal leverages existing operational systems that are used to power open.canada.ca, including CKAN, Drupal and Solr. It also leverages GCDocs, an internal records management tool. The technical architecture of the Open by Default Pilot Portal, a separate, beta-stage instance within open.canada.ca, mirrors that of the Open Government Portal. All source code for the architecture is available on GitHub for reuse here : https://github.com/open-data. 281 | 282 | The Open by Default Portal consolidates draft documents (“Digital Assets”) provided by four pilot departments: Natural Resources Canada, Canadian Heritage, Environment and Climate Change Canada, and the Treasury Board of Canada Secretariat. However, additional partner departments will be on-boarded in the future .The Open by Default Pilot Portal includes Digital Assets that are works in progress which have not necessarily been created or formatted for compliance with web accessibility standards. 283 | 284 | Currently, the Open by Default Portal contains approximately 550 Digital Assets in common formats such as .doc, .docx, .xls, .xlsx, .ppt, .pptx, .pdf, and .png. The collection contains such Digital Assets as draft policies, internal draft documentation on systems, and presentations. It is expected that future Digital Assets holdings on the portal could be expanded to include audio and video formats. It is also expected that the volume on content could expand to include 100,000s of digital assets over the next few years, as departments are onboarded. 285 | 286 | ## 3. Challenge 287 | 288 | TBS has a requirement for an open source software solution (“Solution”) (existing or developmental but not proprietary) to enhance and improve the accessibility of both current and future Digital Assets housed on the Open by Default Pilot Portal. Proposed Solutions must also be compatible with the Open Government website’s existing digital infrastructure. 289 | 290 | The following illustrative list provides examples of accessibility issues Solutions may address in responding to the challenge. This list is non-exhaustive; Solutions may address any of these accessibility issues or may address accessibility issues not listed below. 291 | 292 | - Lack of ability within the system to automatically transform Digital Assets created in both official languages, into Digital Assets which conform to a minimum of WCAG 2.0 AA. Digital assets which additionally conform to WCAG 2.1 and/or EN 301 549 would be preferred. 293 | - Lack of ability within the system to programmatically generate conforming alternate versions of Digital Assets available through the Open by Default Pilot Portal in a variety of formats, and in both official languages, such as PDF/UA, EPUB3, and ODF; 294 | - Lack of ability within the system to programmatically generate alternate versions of Digital Assets 295 | available through the Open by Default Pilot Portal in a variety of braille formats such as .BRF and .BRL in both official languages; 296 | - Lack of ability within the system to generate and embed within Digital Assets an accessibility compliance report for Digital Assets in both official languages, against at a minimum WGAC 2.0 AA standards, compliance to other web accessibility standards would be preferred; 297 | - Lack of ability within the system to programmatically add system generated alt text / descriptive text in both official languages to images; 298 | - Lack of ability within the system to programmatically generate transcripts of English and French voice audio recordings ; 299 | - Lack of ability within the system to generate animated American Sign Language or Quebec Sign Language from spoken word audio or video; 300 | - Lack of ability within the system to programmatically generate described video, transcripts, closed captioning for video content created in both official languages; 301 | - The absence of the ability for the system to assign and display Flesch-Kincaid Reading grade level for English content or Scolarius score for French content; 302 | - The absence of the ability for the system to programmatically reduce the reading grade level of the content to a target of grade 8, in accordance with WCAG 2.0 AAA; and, 303 | - Lack of available document templates that force users to generate documents in a method that complies with, at a minimum WCAG 2.0 AA. Templates which additionally conform to WCAG 2.1 and/or EN 301 549 would be preferred. 304 | 305 | ## 4. Scope 306 | 307 | ### 4.1 Phase 1 308 | 309 | #### 4.1.1 Finalization of Draft Design and Implementation Plan 310 | 311 | Within 10 working days of the Contract being awarded, the Technical Authority will provide any comments electronically that it has regarding the draft design and implementation 312 | plan submitted by the Contractor as part of its bid. The Contractor must update its Design and Implementation Plan to reflect Technical Authority's comments and resubmit it electronically to Technical Authority for approval within 5 working days. 313 | 314 | The Design and Implementation Plan must specify the delivery dates for all deliverables identified in Phases 2 and 3. Canada’s Open Government Portal team will use a public facing version control repository hosting service - GitHub.com. This will enable anyone to subscribe to notifications of changes while also allowing for conversations, issue tracking, and code reviews. 315 | 316 | ##### 4.1.1.1 Deliverable(s) 317 | 318 | ###### 1. Finalized Design and Implementation Plan 319 | 320 | Due date: Within 15 working days of Contract award 321 | 322 | #### 4.1.2 Demonstration 323 | 324 | The Contractor must demonstrate the basic functionality of Solution including at a minimum an early stage functional prototype (defined as a minimum viable demonstration of capability) to the Technical Authority and representatives of Canada, in person at a location to be determined by the Technical Authority. 325 | 326 | At a minimum the presentation must include: a functionality demonstration of the prototype of the Solution and an overview of the Contractor’s proposed design and implementation plan for Phase 2 and 3. The presentation should also include an overview of the Innovati veness, Scalability, Accessibility and Functionality of the proposed Solution. 327 | 328 | The prototype must demonstrate the ability to improve the accessibility of Digital Assets in relation to at least one of the accessibility issues proposed to be addressed in the Contractor’s draft Design and Implementation Plan. 329 | 330 | An independent panel will observe the presentation and convene to determine whether to move forward with Phases 2 and 3 of the Contract. 331 | 332 | ##### 4.1.2.1 Deliverable(s) 333 | 334 | ###### 1. Presentation to include .ppt format and a demonstration of the prototype delivered to the Technical Authority. 335 | 336 | Due date: Within 15 working days of Contract award 337 | 338 | 339 | #### 4.1.3 Financial Proposal 340 | 341 | The Contractor must provide a Financial Proposal for Phases 2 and 3 of the Work in accordance with Annex B, Basis of Payment. The Financial Proposal for Phases 2 and 3 will be subject to negotiation with Canada. Upon Canada’s request, the Contractor must provide Price Support for the Financial Proposal for Phases 2 and 3, which may include; a current published price list indicating the percentage discount available to Canada; or copies of paid invoices for the like quality and quantity of the goods, services or both sold to other customers; or price or rate certifications; or any other supporting documentation as requested by Canada. 342 | 343 | The Financial Proposal for Phases 2 and 3 must include the following information, as applicable, for each element of the Work: 344 | 345 | a) Labour: For each individual and (or) labour category to be assigned to the Work, indicate: i) the hourly rate, inclusive of overhead and profit; and ii) the estimated number of hours. 346 | 347 | b) Materials and Supplies: Identify each category of materials and supplies required to complete the Work and provide the pricing basis. 348 | 349 | c) Subcontracts: Identify any proposed subcontractor and provide for each one the same price breakdown information as contained in this article. 350 | 351 | d) Other Direct Charges: Identify any other direct charges anticipated, such as long distance communications and rentals, and provide the pricing basis. 352 | 353 | e) Profit: Identify proposed profit, if any, and the basis on which it is computed and applied. 354 | 355 | f) Overhead: State the applicable overhead. 356 | 357 | g) Applicable Tax: Identify any Applicable Tax separately. 358 | 359 | ##### 4.1.3.1 Deliverable(s) 360 | 361 | ###### 1. Financial Proposal for Phases 2 and 3 of the challenge delivered to the Contracting Authority electronically in .pdf format. 362 | 363 | Due date: Within 15 working days of Contract award 364 | 365 | ### 4.2 Phase 2 (Optional) 366 | 367 | #### 4.2.1 Development and Testing 368 | 369 | ##### 4.2.1.1 Test Plan 370 | 371 | The Contractor must provide a Test Plan to the Technical Authority following commencement of Phase 2. The test plan must demonstrably exercise all new functionality of the Solution. The Test Plan must be in the form of a MS Excel spreadsheet that documents each test case, and include, at a minimum: 372 | 373 | a. A test case number; 374 | 375 | b. Step-by-step instructions for testers to complete each test case; 376 | 377 | c. Success criteria for each test case; 378 | 379 | d. Description of the functionality the test case addresses; 380 | 381 | e. Fields next to each test case for testers to compile testing notes/results; 382 | 383 | f. Test data; 384 | 385 | g. Exit criteria; and 386 | 387 | h. The test plan must be in a .pdf, .odf, or .docx document for addition to the Canadian Open Government CKAN. 388 | 389 | ##### 4.2.1.2 Baseline testing 390 | 391 | The Contractor must execute the test plan, in order to establish a performance baseline of the functionality of the Solution, and update and resubmit the Design and Implementation Plan to the Technical Authority for approval as necessary. 392 | 393 | ##### 4.2.1.3 Development and Debugging 394 | 395 | The Contractor must correct software defects identified during the baseline testing and update the Solution source code. The Contractor must provide a Defect Debugging Report to Technical Authority documenting the defects, and their corrections. 396 | 397 | ##### 4.2.1.4 Standards Compliance testing 398 | The Solution must comply with Government of Canada Standards for Web Accessibility and Web Security. Canada will test the Solution for compliance with these standards. The Technical Authority will provide detailed feedback to the Contractor on any issues revealed by compliance testing. The Contractor must resolve the issues in the source code revealed by compliance testing and update the Solution source code. 399 | 400 | Evidence of user testing, debugging, testing for accessibility and security, and an updated Design and Implementation Plan (if applicable) must be provided to the Technical Authority for approval. 401 | 402 | ##### 4.2.1.5 Deliverable(s): 403 | 404 | 1. Test Plan, 405 | 406 | 2. Defect Debugging Report, 407 | 408 | 3. Evidence of baseline testing, debugging, and resolution of compliance testing issues, 409 | 410 | 4. Updated Design and Implementation Plan (if applicable), 411 | 412 | 5. Updated Source Code (if applicable). 413 | 414 | Due date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 415 | 416 | #### 4.2.2 Unit and Integration Testing 417 | 418 | ##### 4.2.2.1 Unit Testing 419 | 420 | The Contractor must perform unit testing and integration testing of the Solution with the Open Government website infrastructure and update the Design and Implementation Plan. The Contractor must perform all unit and integration testing in their own environment. 421 | 422 | The Contractor must conduct automated unit tests for all python based software modules. The Contractor must resolve any issues revealed by the automated unit tests and update Solution source code. The Contractor must provide a report electronically in .pdf format to the Technical Authority detailing the results of all automated unit testing. 423 | 424 | ##### 4.2.2.2 Integration Testing 425 | 426 | The Contractor must perform integration testing on its own system, resolve any issues revealed through integration testing and update the Solution source code. Canada will provide the Contractor with a downloadable virtualbox image of the Open by Default Portal configuration allowing the Contractor to configure their environment for integration testing. 427 | 428 | As a final test the Contractor must provide instructions and the updated source code for Canada to install and test the code on an open.canada.ca development environment. The Contractor must provide a report to the Technical Authority detailing the results of their internal integration testing and the instructions for Canada to install and test the source code in the development environment. 429 | 430 | In accordance with timelines to be established in the Design and Implementation Plan, The Technical Authority will provide detailed feedback to the Contractor on any issues revealed by its own integration testing. The Contractor must resolve the issues revealed and resubmit the updated source code to the Technical Authority for re-testing. 431 | 432 | ##### 4.2.2.3 Deliverable(s): 433 | 434 | 1. Automated Unit Testing Report, 435 | 436 | 2. Contractor’s Integrated Testing Results Report, 437 | 438 | 3. Installation and Testing Instructions, 439 | 440 | 4. Evidence of unit testing and integration testing; 441 | 442 | 5. Updated Design and Implementation Plan (if applicable), 443 | 444 | 6. Updated source code (if applicable) 445 | 446 | Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 447 | 448 | #### 4.2.3 Progress Review Meetings 449 | The Contractor must be attend weekly progress review meetings by teleconference and provide updates to the Technical Authority on progress towards completion of the deliverables. Progress review meetings shall be scheduled by the Technical Authority, and all pertinent details such as teleconferencing information shall be provided to the Contractor by the Technical Authority not less than 24 hours in advance. The Contractor must respond to inquiries pertaining to the completion of deliverables on an ad hoc basis. 450 | 451 | The Contractor must prepare a Record of Discussion for each progress review meeting in .doc, .odf, or .pdf format and provide it to the Technical Authority electronically within 48 hours of the progress review meeting. 452 | 453 | ##### 4.2.3.1 Deliverable(s) 454 | 455 | Record of Discussion 456 | 457 | Due Date: within 48 hours of the progress review meeting 458 | 459 | ### 4.3 Phase 3 (Optional): 460 | 461 | #### 4.3.1 Implementation Support 462 | 463 | The Contractor will provide technical support to Canada, as the Solution is implemented on the production environment. The Contractor must make resources with the knowledge required to implement the Solution on Canada’s production environment available via telephone and email to Canada during the implementation of the Solution. 464 | 465 | #### 4.3.1.1 Deliverable(s) 466 | 467 | Professional services in the form of technical support to Canada during the implementation of the Solution. 468 | 469 | Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 470 | 471 | #### 4.3.2 Software Documentation 472 | 473 | The Contractor must prepare all Software Documentation for the Solution and provide it electronically to the Technical Authority in .pdf format. 474 | 475 | ##### 4.3.2.1 Deliverable(s) 476 | 477 | Software Documentation, consisting of, at a minimum, a technical specification for the Solution documenting the system architecture, subsystem design, and required configuration, in .pdf format. 478 | 479 | Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan. 480 | 481 | #### 4.3.3 Progress Review Meetings 482 | 483 | The Contractor must be attend weekly progress review meetings by teleconference and provide updates to the Technical Authority on progress towards completion of the deliverables. Progress review meetings will be scheduled by the Technical Authority, and all pertinent details such as teleconferencing information will be provided to the Contractor by the Technical Authority not less than 24 hours in advance. The Contractor must respond to inquiries pertaining to the completion of deliverables on an ad hoc basis. 484 | 485 | The Contractor will prepare a Record of Discussion for each progress review meeting in .doc, .odf, or .pdf format and provide it to the Technical Authority electronically within 48 hours of the progress review meeting. 486 | 487 | ##### 4.3.3.1 Deliverable(s) 488 | 489 | Record of Discussion 490 | 491 | Due Date: within 48 hours of the progress review meeting. 492 | 493 | ## 5. Constraints and Operational Environment 494 | 495 | The Solution must be compatible with the Open Government website’s existing digital infrastructure. See Appendix 1 to Attachment 3 attached. 496 | 497 | ### 5.1 Existing Open Government Website Digital Infrastructure 498 | 499 | The Open Government website operates using the following open source tools, in compliance with the listed policies relating to websites for Canada. 500 | - CKAN (Data Catalogue) – Licensed under the Affero GNU GPL v3.0 License; 501 | - Solr (Search Engine) 502 | - Licensed under the Apache License 2.0; 503 | - Drupal (Content Management System) - Licensed under the GPL v2 License; 504 | - PostgreSQL (Relational Database Management System - Licensed under the Postgresql License. 505 | 506 | Government of Canada’s Web Experience Toolkit Relevant Policies to Canada’s Web Presence (available at https://www.tbs-sct.gc.ca/pol/index-eng.aspx): 507 | 1. Directive on the Management of Communications 508 | 1. Directive on Official Languages for Communications and Services 509 | 1. Standard on Web Accessibility 510 | 1. Standard on Web Interoperability 511 | 1. Standard on Web Usability 512 | 1. Standard on Optimizing Websites and Applications for Mobile Devices 513 | 1. Guidance on Implementing the Standard on Web Accessibility 514 | 515 | The Open Government website is currently housed on a mix of cloud and on premise infrastructure. Solutions must be compatible with infrastructure hosted on the Microsoft (MS) Azure cloud in the Canada Central or Canada East availability regions. 516 | 517 | ### 5.2 Open Source Code Repository 518 | 519 | The Contractor must create and maintain a public repository for the project on GitHub during the period of the Contract. All updates to the Solution source code must be deposited on GitHub, as well as, the final Solution source code. 520 | 521 | ### 5.3 Design and Implementation Plan 522 | 523 | Updates to the Design and Implementation Plan must be approved by the Technical Authority. 524 | 525 | ### 5.4 Licencing 526 | 527 | Solutions developed (not pre-existing) for the challenge must be licenced under the MIT Licence. Where Contractors are leveraging an existing open source projects, adopting the parent licence of the open source software project is acceptable, where the licence is approved by the Open Source Institute. A list of approved licences is available at the following link: https://opensource.org/licenses/alphabetical 528 | 529 | ## 6. Language of Work 530 | 531 | English or French 532 | 533 | ## 7. Location of Work 534 | 535 | The Work must be performed at the Contractor’s site and Shawinigan, Quebec (Phase 1, article 4.1.2). 536 | 537 | ## 8. Travel 538 | 539 | Travel will be required to attend the presentation event at the expense to Canada (Phase 1, article 4.1.2). 540 | 541 | ## 9. Review and Acceptance 542 | 543 | ### 9.1 Software Deliverables 544 | 545 | Final acceptance of the software Solution will occur when all discrepancies, errors or other deficiencies identified in writing by the Technical Authority have been resolved, either through documentation updates, program correction or other methods approved by the Technical Authority. 546 | 547 | ### 9.2 Reports and Documentation Deliverables 548 | 549 | Reports and documentation deliverables will be accepted when all discrepancies, errors or other deficiencies identified in writing by the Technical Authority have been corrected. 550 | 551 | The Contractor must provide drafts all Reports and Documentation deliverables to the Technical Authority for review 10 business days prior to the specified due date. The Technical Authority will provide comments to the Contractor 5 business days prior to the due date. 552 | 553 | All of the Technical Authority's comments to deliverables must either be incorporated in the succeeding version of the deliverable or the Contractor must demonstrate to the Technical Authority’s satisfaction why such comments should not be incorporated. 554 | 555 | If the Contractor requires additional guidance to produce an acceptable deliverable, the Contractor must arrange a meeting with the Technical Authority. 556 | 557 | 558 | 559 | Current Infrastructure 560 | The Open by Default pilot is built on an infrastructure as described by the diagram below. 561 | 562 | Image missing 563 | 564 | 565 | 566 | Footer 567 | 568 | Accessibility Procurement Pilot 569 | Attachment 3 570 | Public Services and Procurement Canada 571 | LOI # 24062-180181/ 572 | 573 | 574 | 575 | 576 | -------------------------------------------------------------------------------- /EU-Functional-Accessibility-Requirements.md: -------------------------------------------------------------------------------- 1 | [List of detailed Accessibility Requirements for Web-based internet and intranet system](http://mandate376.nomensa.com/procurement-stages/writing-a-call-for-tenders/ad5cc802-a49c-11e3-884b-0050568763d9/download/) 2 | 3 | Functional Accessibility Requirements for Web-based internet and intranet system 4 | ================================================================================ 5 | 6 | Advisory notes - not to be inlcuded in a Call for Tenders 7 | --------------------------------------------------------- 8 | 9 | 1. The procuring authority should check that the Functionality Accessibility Requirements listed below relate to the functionality required for its specific procurement. Use the "Accessibility Requirements Generator" to change this list. 10 | 2. The list of requirements is suitable for use as Technical Specifications and/or Award Criteria. 11 | 1. The Column "Clauses met: Fully/Partially/Not" should only be used/included for Award Criteria. 12 | 2. Where the Functional Accessibility Requirements are used for the Technical Specification, it is presumed that all requirements are met, and therefore this column is not necessary. 13 | 14 | Scope 15 | ----- 16 | 17 | This example consists of the procurement of a web-based internet and intranet system, which includes web content, two-way voice and video communication (e.g. between employees), video capabilities, and the necessary content management system used to maintain and publish new content. 18 | 19 | The rendering (display) and interaction with the web content is not part of this procurement, as this functionality is addressed by user agents, such as web browsers and media players, and assistive technologies used by some people with disabilities. 20 | 21 | The following aspects are covered in the list of accessibility requirements: 22 | 23 | * generic requirements, such as activation of accessibility features, biometrics, preservation of accessibility information, operable parts, locking or toggle controls, key repeat, double-strike key acceptance and simultaneous user actions; 24 | * two-way voice or video communication; 25 | * video capabilities: playback, transmission, conversion of recording of video with synchronized audio; 26 | * web content success criteria that are equivalent to conformance with WCAG 2.0 level AA; 27 | * other software-related requirements, such as interoperability with assistive technology, documented accessibility usage, user preferences; 28 | * authoring tools; 29 | * documentation and support services. 30 | 31 | The following aspects are not covered in the list of accessibility requirements: 32 | 33 | * closed functionality; 34 | * hardware; 35 | * non-web documents and non-web software; 36 | * web browsers and assistive technologies; 37 | * relay service provision. 38 | 39 | Explanation of the table columns: 40 | --------------------------------- 41 | 42 | * **"EN 301 549 Clauses"** includes all Clauses of EN 301 549 "Accessibility requirements suitable for public procurement of ICT products and services in Europe" that may apply to the ICT product or service 43 | * **"Notes"** is for brief notes by the procuring authority about the Clauses of EN 301 549 or additional requirements that may wish to add. 44 | * **"Clause met:"** should be included ONLY where the procurer wishes to use Functional Accessibility Requirements as Award Criteria; the criteria should be based on the number of listed requirements which are fully met. It is to be filled in by the supplier. 45 | * **"Not Applicable"** may be used by the supplier to note if this Functional Accessibility Requirement does not apply to (as opposed to is not met by) the offered solution 46 | * **"Explanations"** is where the supplier can note explanations for any of the preceding columns 47 | 48 | Part A - Functional Performance Statements 49 | ------------------------------------------ 50 | 51 | These are the core aspects that the offered product / service must meet, either by meeting the relevant Functional Accessibility Requirements listed below, or outlining how the product / service would fulfil these Statements. 52 | 53 | * **4.2.1. Usage without vision:** Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that does not require vision. 54 | * **4.2.2. Usage with limited vision:** Where ICT provides visual modes of operation, some users will need the ICT to provide features that enable users to make better use of their limited vision. 55 | * **4.2.3. Usage without perception of colour:** Where ICT provides visual modes of operation, some users will need the ICT to provide a visual mode of operation that does not require user perception of colour. 56 | * **4.2.4. Usage without hearing:** Where ICT provides auditory modes of operation, some users need ICT to provide at least one mode of operation that does not require hearing. 57 | * **4.2.5. Usage with limited hearing:** Where ICT provides auditory modes of operation, some users will need the ICT to provide enhanced audio features. 58 | * **4.2.6. Usage without vocal capability:** Where ICT requires vocal input from users, some users will need the ICT to provide at least one mode of operation that does not require them to generate vocal output. 59 | * **4.2.7. Usage with limited manipulation or strength:** Where ICT requires manual actions, some users will need the ICT to provide features that enable users to make use of the ICT through alternative actions not requiring manipulation or hand strength. 60 | * **4.2.8. Usage with limited reach:** Where ICT products are free-standing or installed, the operational elements will need to be within reach of all users. 61 | * **4.2.9. Minimize photosensitive seizure triggers:** Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that minimizes the potential for triggering photosensitive seizures. 62 | * **4.2.10. Usage with limited cognition:** Some users will need the ICT to provide features that make it simpler and easier to use. 63 | * **4.2.11. Privacy:** Where ICT provides features that are provided for accessibility, some users will need their privacy to be maintained when using those ICT features that are provided for accessibility. 64 | 65 | Part B - Functional Accessibility Requirements 66 | ---------------------------------------------- 67 | 68 | The following Functional Accessibility Requirements are applicable to the Functional Performance Statements above. If a solution meets all of these it is considered to have met the Functional Performance Statements and is therefore deemed to conform with EN 301 549. 69 | 70 | **NOTE:** "Web pages that conform to WCAG 2.0 Level AA are deemed to have met the web content requirements of clause 9.2 and the conformance requirements of clause 9.3". 71 | 72 | EN 301 549 Clauses 73 | 74 | Notes 75 | 76 | Clause met (Y/N) 77 | 78 | Not Applicable 79 | 80 | Explanations 81 | 82 | 5.2 Activation of accessibility features 83 | 84 | Where ICT has documented accessibility features, it shall be possible to activate those documented accessibility features that are required to meet a specific need without relying on a method that does not support that need. 85 | 86 | 5.3 Biometrics 87 | 88 | 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. 89 | 90 | 5.4 Preservation of accessibility information during conversion 91 | 92 | 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 in or supported by the destination format. 93 | 94 | 5.6.1 Tactile or auditory status 95 | 96 | Where ICT has a locking or toggle control and 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. 97 | 98 | 5.6.2 Visual status 99 | 100 | When ICT has a locking or toggle control and 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. 101 | 102 | 5.7 Key repeat 103 | 104 | Where ICT with key repeat is provided and the key repeat cannot be turned off: 105 | 106 | a) the delay before the key repeat shall be adjustable to at least 2 seconds; and 107 | 108 | b) the key repeat rate shall be adjustable down to one character per 2 seconds. 109 | 110 | 6.2.1.2 Concurrent voice and text 111 | 112 | Where the ICT, or set of ICT, provided to a user, supports two-way voice communication and enables a user to communicate with another user by RTT, it shall provide a mechanism to select a mode of operation allowing concurrent voice and text. 113 | 114 | 6.2.2.1 Visually distinguishable display 115 | 116 | Where ICT has RTT send and receive capabilities, displayed sent text shall be visually differentiated from and separated from received text. 117 | 118 | 6.2.2.2 Programmatically determinable send and receive direction 119 | 120 | Where ICT has RTT send and receive capabilities, the send/receive direction of transmitted text shall be programmatically determinable, unless the RTT has closed functionality. 121 | 122 | 6.2.3 Interoperability 123 | 124 | Where ICT with RTT functionality interoperates with other ICT with RTT functionality (as required by [6.2.1.1](#)) they shall support at least one of the four RTT interoperability mechanisms described below: 125 | 126 | a) ICT interoperating over the Public Switched Telephone Network (PSTN), with other ICT that directly connects to the PSTN as described in Recommendation ITU-T V.18 \[[i.23](#)\] or any of its annexes for text telephony signals at the PSTN interface; 127 | 128 | b) ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using real-time text that conforms to RFC 4103 \[[i.13](../../../../standard/references#i13)\]; 129 | 130 | c) ICT interoperating with other ICT using RTT that conforms with the IP Multimedia Sub-System (IMS) set of protocols specified in TS 126 114 \[[i.10](../../../../standard/references#i10)\], TS 122 173 \[[i.11](../../../../standard/references#i11)\] and TS 134 229 \[[i.12](../../../../standard/references#i12)\]; 131 | 132 | d) ICT interoperating with other ICT using a relevant and applicable common specification for RTT exchange that is published and available. This common specification shall include a method for indicating loss or corruption of characters. 133 | 134 | 6.2.4 Real-time text responsiveness 135 | 136 | Where ICT utilises RTT input, that RTT input shall be transmitted to the ICT network supporting RTT within 1 second of the input entry. 137 | 138 | 6.3 Caller ID 139 | 140 | Where ICT provides caller identification and similar telecommunications functions are provided, the caller identification and similar telecommunications functions shall be available in text form and in at least one other modality. 141 | 142 | 6.4 Alternatives to voice-based services 143 | 144 | Where ICT provides real-time voice-based communication and also provides voice mail, auto-attendant, or interactive voice response facilities, the ICT should offer users a means to access the information and carry out the tasks provided by the ICT without the use of hearing or speech. 145 | 146 | 6.5.2 Resolution 147 | 148 | Where ICT that provides two-way voice communication includes real time video functionality, the ICT: 149 | 150 | a) shall support at least QCIF resolution; 151 | 152 | b) should preferably support at least CIF resolution. 153 | 154 | 6.5.3 Frame rate 155 | 156 | Where ICT that provides two-way voice communication includes real-time video functionality, the ICT: 157 | 158 | a) shall support a frame rate of at least 12 frames per second (FPS); 159 | 160 | b) should preferably support a frame rate of at least 20 frames per second (FPS) with or without sign language in the video stream. 161 | 162 | 6.5.4 Synchronization between audio and video 163 | 164 | Where ICT that provides two-way voice communication includes real-time video functionality, the ICT should ensure a maximum time difference of 100 ms between the speech and video presented to the user. 165 | 166 | 6.6 Alternatives to video-based services 167 | 168 | 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 these facilities: 169 | 170 | a) for audible information, without the use of hearing; 171 | 172 | b) for spoken commands, without the use of speech; 173 | 174 | c) for visual information, without the use of vision. 175 | 176 | 7.1.1 Captioning playback 177 | 178 | Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions. 179 | 180 | 7.1.2 Captioning synchronisation 181 | 182 | Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions. 183 | 184 | 7.1.3 Preservation of captioning 185 | 186 | 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 clauses 7.1.1 and 7.1.2. 187 | 188 | Additional presentational aspects of the text such as screen position, text colours, text style and text fonts may convey meaning, based on regional conventions. Altering these presentational aspects could change the meaning and should be avoided wherever possible. 189 | 190 | 7.2.1 Audio description playback 191 | 192 | Where ICT displays video with synchronized audio, it shall provide a mechanism to select and play available audio description to the default audio channel. 193 | 194 | Where video technologies do not have explicit and separate mechanisms for audio description, an ICT is deemed to satisfy this requirement if the ICT enables the user to select and play several audio tracks. 195 | 196 | 7.2.2 Audio description synchronisation 197 | 198 | Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description. 199 | 200 | 7.2.3 Preservation of audio description 201 | 202 | 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 clauses 7.2.1 and 7.2.2. 203 | 204 | 7.3 User controls for captions and audio description 205 | 206 | Where ICT primarily displays materials containing video with associated audio content, user controls 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. 207 | 208 | 9.2.1 Non-text content 209 | 210 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.1.1 Non-text content. 211 | 212 | **WCAG 2.0 Success Criterion 1.1.1 Non-text content** 213 | 214 | All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below: 215 | 216 | * **Controls, Input:** If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to WCAG 2.0 Guideline 4.1 for additional requirements for controls and content that accepts user input.) 217 | * **Time-Based Media:** If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to WCAG 2.0 Guideline 1.2 for additional requirements for media.) 218 | * **Test:** If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content. 219 | * **Sensory:** If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content. 220 | * **CAPTCHA:** If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities. 221 | * **Decoration, Formatting, Invisible:** If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology. 222 | 223 | 9.2.2 Audio-only and video-only (pre-recorded) 224 | 225 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.1 Audio-only and Video-only (Pre-recorded). 226 | 227 | **WCAG 2.0 success criterion: Audio-only and video-only (pre-recorded)** 228 | 229 | For pre-recorded audio-only and pre-recorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labelled as such: 230 | 231 | * Pre-recorded Audio-only: An alternative for time-based media is provided that presents equivalent information for pre-recorded audio-only content. 232 | * Pre-recorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for pre-recorded video-only content. 233 | 234 | 9.2.3 Captions (pre-recorded) 235 | 236 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.2 Captions (Pre-recorded). 237 | 238 | **WCAG 2.0 success criterion: Captions (pre-recorded)** 239 | 240 | Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. 241 | 242 | 9.2.4 Audio description or media alternative (pre-recorded) 243 | 244 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.3 Audio Description or Media Alternative (Pre-recorded). 245 | 246 | **WCAG 2.0 success criterion: Audio description or media alternative (pre-recorded)** 247 | 248 | An alternative for time-based media or audio description of the pre-recorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such. 249 | 250 | **NOTE 1:** The WCAG 2.0 definition of "audio description" says that "audio description" is "Also called 'video description' and 'descriptive narration'". 251 | 252 | **NOTE 2:** Secondary or alternate audio tracks are commonly used for this purpose. 253 | 254 | 9.2.5 Captions (live) 255 | 256 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.4 Captions (Live). 257 | 258 | **WCAG 2.0 success criterion: Captions (live)** 259 | 260 | Captions are provided for all live audio content in synchronized media. 261 | 262 | 9.2.6 Audio description (pre-recorded) 263 | 264 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.5 Audio Description (Pre-recorded). 265 | 266 | **WCAG 2.0 success criterion: Audio description (pre-recorded)** 267 | 268 | Audio description is provided for all pre-recorded video content in synchronized media. 269 | 270 | 9.2.7 Info and relationships 271 | 272 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.1 Info and Relationships. 273 | 274 | **WCAG 2.0 success criterion: Info and relationships** 275 | 276 | Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. 277 | 278 | 9.2.8 Meaningful sequence 279 | 280 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.2 Meaningful Sequence. 281 | 282 | **WCAG 2.0 success criterion: Meaningful sequence** 283 | 284 | When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. 285 | 286 | 9.2.9 Sensory characteristics 287 | 288 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.3 Sensory Characteristics. 289 | 290 | **WCAG 2.0 success criterion: Sensory characteristics** 291 | 292 | Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. 293 | 294 | **NOTE:** For requirements related to colour, refer to WCAG 2.0 Guideline 1.4. 295 | 296 | 9.2.10 Use of colour 297 | 298 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.1 Use of Color. 299 | 300 | **WCAG 2.0 success criterion: Use of colour** 301 | 302 | Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. 303 | 304 | **NOTE: **This success criterion addresses colour perception specifically. Other forms of perception are covered in WCAG 2.0 Guideline 1.3 including programmatic access to colour and other visual presentation coding. 305 | 306 | 9.2.11 Audio control 307 | 308 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.2 Audio Control. 309 | 310 | **WCAG 2.0 success criterion: Audio control** 311 | 312 | If any audio on a Web page 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. 313 | 314 | **NOTE:** Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether or not it is used to meet other success criteria) shall meet this success criterion. See _[Conformance Requirement 5: Non-Interference](http://www.w3.org/TR/2008/REC-WCAG20-20081211/#cc5)_. 315 | 316 | 9.2.12 Contrast (minimum) 317 | 318 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.3 Contrast (Minimum). 319 | 320 | **WCAG 2.0 success criterion: Contrast (Minimum)** 321 | 322 | The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: 323 | 324 | * Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1. 325 | * Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement. 326 | * Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement. 327 | 328 | 9.2.13 Resize text 329 | 330 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.4 Resize text. 331 | 332 | **WCAG 2.0 success criterion: Resize text** 333 | 334 | Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. 335 | 336 | 9.2.14 Images of text 337 | 338 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.5 Images of Text. 339 | 340 | **WCAG 2.0 success criterion: Images of text** 341 | 342 | If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: 343 | 344 | * **Customizable:** The image of text can be visually customized to the user's requirements. 345 | * **Essential:** A particular presentation of text is essential to the information being conveyed. 346 | 347 | NOTE: Logotypes (text that is part of a logo or brand name) are considered essential. 348 | 349 | 9.2.15 Keyboard 350 | 351 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.1.1 Keyboard. 352 | 353 | **WCAG 2.0 success criterion: Keyboard** 354 | 355 | All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. 356 | 357 | NOTE 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not. 358 | 359 | NOTE 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. 360 | 361 | 9.2.16 No keyboard trap 362 | 363 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.1.2 No Keyboard Trap. 364 | 365 | **WCAG 2.0 success criterion: No Keyboard Trap** 366 | 367 | If keyboard focus can be moved to a component of the page 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. 368 | 369 | NOTE: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole document, all content on the Web page (whether or not it is used to meet other success criteria) must meet this success criterion. 370 | 371 | 9.2.17 Timing adjustable 372 | 373 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.2.1 Timing Adjustable. 374 | 375 | **WCAG 2.0 success criterion: Timing Adjustable** 376 | 377 | For each time limit that is set by the content, at least one of the following is true: 378 | 379 | * **Turn off:** The user is allowed to turn off the time limit before encountering it; or 380 | * **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 381 | * **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 382 | * **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 383 | * **Essential Exception:** The time limit is essential and extending it would invalidate the activity; or 384 | * **20 Hour Exception:** The time limit is longer than 20 hours. 385 | 386 | NOTE: 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.0 Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action. 387 | 388 | 9.2.18 Pause, stop, hide 389 | 390 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.2.2 Pause, Stop, Hide. 391 | 392 | **WCAG 2.0 success criterion: Pause, Stop, Hide** 393 | 394 | For moving, blinking, scrolling, or auto-updating information, all of the following are true: 395 | 396 | * **Moving, blinking, scrolling:** For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented 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 397 | * **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. 398 | 399 | NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.0 Guideline 2.3. 400 | 401 | NOTE 2: This success criteria is applicable to all content (whether or not there is an alternate accessible version of the content) since any content that does not meet this success criterion can interfere with a user's ability to use the whole page (including a link to the alternate version). 402 | 403 | 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 initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so. 404 | 405 | 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. 406 | 407 | 9.2.19 Three flashes or below threshold 408 | 409 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.3.1 Three Flashes or Below Threshold. 410 | 411 | **WCAG 2.0 success criterion: Three Flashes or Below Threshold** 412 | 413 | Web pages 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. 414 | 415 | NOTE: This success criterion is applicable to all content on the Web page (whether or not there is an alternate accessible version of the content) since any part of a document that does not meet this success criterion can interfere with a user's ability to use the whole page (including a link to the alternate version). 416 | 417 | 9.2.20 Bypass blocks 418 | 419 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.1 Bypass Blocks. 420 | 421 | **WCAG 2.0 success criterion: Bypass Blocks** 422 | 423 | A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. 424 | 425 | 9.2.21 Page titled 426 | 427 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.2 Page Titled. 428 | 429 | **WCAG 2.0 success criterion: Page Titled** 430 | 431 | Web pages have titles that describe topic or purpose. 432 | 433 | 9.2.22 Focus Order 434 | 435 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.3 Focus Order. 436 | 437 | **WCAG 2.0 success criterion: Focus Order** 438 | 439 | If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. 440 | 441 | 9.2.23 Link purpose (in context) 442 | 443 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.4 Link Purpose (In Context). 444 | 445 | **WCAG 2.0 success criterion: Link Purpose (In Context)** 446 | 447 | The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. 448 | 449 | 9.2.24 Multiple ways 450 | 451 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.5 Multiple Ways. 452 | 453 | **WCAG 2.0 Success criterion: Multiple Ways** 454 | 455 | More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. 456 | 457 | 9.2.25 Headings and labels 458 | 459 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.6 Headings and Labels. 460 | 461 | **WCAG 2.0 Success Criterion: Headings and Labels** 462 | 463 | Headings and labels describe topic or purpose. 464 | 465 | 9.2.26 Focus visible 466 | 467 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.7 Focus Visible. 468 | 469 | **WCAG 2.0 Success Criterion: Focus Visible** 470 | 471 | Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. 472 | 473 | 9.2.27 Language of page 474 | 475 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.1.1 Language of Page. 476 | 477 | **WCAG 2.0 Success Criterion: Language of Page** 478 | 479 | The default human language of each Web page can be programmatically determined. 480 | 481 | 9.2.28 Language of parts 482 | 483 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.1.2 Language of Parts. 484 | 485 | **WCAG 2.0 Success Criterion: Language of Parts** 486 | 487 | The human language of each passage or phrase in the content 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 surrounding text. 488 | 489 | 9.2.29 On focus 490 | 491 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.1 On Focus. 492 | 493 | **WCAG 2.0 Success Criterion: On Focus** 494 | 495 | When any component receives focus, it does not initiate a change of context. 496 | 497 | 9.2.30 On input 498 | 499 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.2 On Input. 500 | 501 | **WCAG 2.0 Success Criterion: On Input** 502 | 503 | Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. 504 | 505 | 9.2.31 Consistent navigation 506 | 507 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.3 Consistent Navigation. 508 | 509 | **WCAG 2.0 Success Criterion: Consistent Navigation 510 | ** 511 | 512 | Navigational mechanisms that are repeated on multipleWeb pageswithin aset of Web pagesoccur in the same relative ordereach time they are repeated, unless a change is initiated by the user. 513 | 514 | 9.2.32 Consistent identification 515 | 516 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.4 Consistent Identification. 517 | 518 | **WCAG 2.0 Success Criterion: Consistent Identification 519 | ** 520 | 521 | Components that have thesame functionalitywithin a set ofWeb pagesare identified consistently. 522 | 523 | 9.2.33 Error identification 524 | 525 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.1 Error Identification. 526 | 527 | **WCAG 2.0 Success Criterion: Error Identification** 528 | 529 | If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. 530 | 531 | 9.2.34 Labels or instructions 532 | 533 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.2 Labels or Instructions. 534 | 535 | **WCAG 2.0 Success Criterion: Labels or Instructions** 536 | 537 | Labels or instructions are provided when content requires user input. 538 | 539 | 9.2.35 Error suggestion 540 | 541 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.3 Error Suggestion. 542 | 543 | **WCAG 2.0 Success Criterion: Error Suggestion** 544 | 545 | If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. 546 | 547 | 9.2.36 Error prevention (legal, financial, data) 548 | 549 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data). 550 | 551 | **WCAG 2.0 Success Criterion: Error prevention (Legal, Financial, Data)** 552 | 553 | For Web pages 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: 554 | 555 | 1. **Reversible:** Submissions are reversible. 556 | 2. **Checked:** Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. 557 | 3. **Confirmed:** A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission. 558 | 559 | 9.2.37 Parsing 560 | 561 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 4.1.1 Parsing. 562 | 563 | **WCAG 2.0 Success Criterion: Parsing** 564 | 565 | In content implemented using markup languages, 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 566 | 567 | NOTE: 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. 568 | 569 | 9.2.38 Name, role, value 570 | 571 | Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 4.1.2 Name, Role, Value. 572 | 573 | **WCAG 2.0 Success Criterion: Name, Role, Value** 574 | 575 | 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 programmatically set and notification of changes to these items is available to user agents, including assistive technologies 576 | 577 | NOTE: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. 578 | 579 | 9.3 WCAG 2.0 conformance requirements 580 | 581 | Where ICT is a web page, it shall satisfy all the following five WCAG 2.0 conformance requirements at Level AA. 582 | 583 | 1. Conformance level 584 | 2. Full pages 585 | 3. Complete processes 586 | 4. Only Accessibility-Supported Ways of Using Technologies 587 | 5. Non-interference 588 | 589 | 11.3.2.3 Use of accessibility services 590 | 591 | 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 11.3.2.5 to 11.3.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology. 592 | 593 | 11.3.2.5 Object information 594 | 595 | Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the user interface elements' role, state(s), boundary, name, and description programmatically determinable by assistive technologies. 596 | 597 | 11.3.2.6 Row, column, and headers 598 | 599 | Where the software provides a user interface it shall, by using the services as described in clause 11.3.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. 600 | 601 | 11.3.2.7 Values 602 | 603 | Where the software provides a user interface, it shall, by using the services as described in clause 11.3.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 determinable by assistive technologies. 604 | 605 | 11.3.2.8 Label relationships 606 | 607 | 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 11.3.2.3, so that this information is programmatically determinable by assistive technologies. 608 | 609 | 11.3.2.9 Parent-child relationships 610 | 611 | Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies. 612 | 613 | 11.3.2.10 Text 614 | 615 | Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies. 616 | 617 | 11.3.2.11 List of available actions 618 | 619 | Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make a list of available actions that can be executed on a user interface element, programmatically determinable by assistive technologies. 620 | 621 | 11.3.2.12 Execution of available actions 622 | 623 | When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow the programmatic execution of the actions exposed according to clause 11.3.2.11 by assistive technologies. 624 | 625 | 11.3.2.13 Tracking of focus and selection attributes 626 | 627 | Where software provides a user interface it shall, by using the services as described in clause 11.3.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. 628 | 629 | 11.3.2.14 Modification of focus and selection attributes 630 | 631 | When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow assistive technologies to programmatically modify focus, text insertion point, and selection attributes of user interface elements where the user can modify these items. 632 | 633 | 11.3.2.15 Change notification 634 | 635 | Where software provides a user interface it shall, by using the services as described in 11.3.2.3, notify assistive technologies about changes in those programmatically determinable attributes of user interface elements that are referenced in requirements 11.3.2.5 to 11.3.2.11 and 11.3.2.13. 636 | 637 | 11.3.2.16 Modifications of states and properties 638 | 639 | When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow assistive technologies to programmatically modify states and properties of user interface elements, where the user can modify these items. 640 | 641 | 11.3.2.17 Modifications of values and text 642 | 643 | When permitted by security requirements, software that provides a user interface shall, by using the services as described in 11.3.2.3, allow assistive technologies to modify values and text of user interface elements using the input methods of the platform, where a user can modify these items without the use of assistive technology. 644 | 645 | 11.4.1 User control of accessibility features 646 | 647 | Where software is a platform it shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users. 648 | 649 | 11.4.2 No disruption of accessibility features 650 | 651 | Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software. 652 | 653 | 11.5 User preferences 654 | 655 | Where software provides a user interface it shall provide sufficient modes of operation that use user preferences for platform settings for colour, contrast, font type, font size, and focus cursor except for software that is designed to be isolated from its underlying platforms. 656 | 657 | 11.6.1 Content technology 658 | 659 | Authoring tools shall conform to clauses 11.6.2 to 11.6.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool. 660 | 661 | 11.6.2 Accessible content creation 662 | 663 | Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable. 664 | 665 | 11.6.3 Preservation of accessibility information in transformations 666 | 667 | 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. 668 | 669 | 11.6.4 Repair assistance 670 | 671 | If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web content) or 10 (Documents) as applicable, then the authoring tool shall provide repair suggestion(s). 672 | 673 | 11.6.5 Templates 674 | 675 | When an authoring tool provides templates, at least one template that supports the creation of content that conforms to the requirements of clauses 9 (Web content) or 10 (Documents) as applicable shall be available and identified as such. 676 | 677 | 12.1.1 Accessibility and compatibility features 678 | 679 | Product documentation provided with the ICT whether provided separately or integrated within the ICT shall list and explain how to use the accessibility and compatibility features of the ICT. 680 | 681 | 12.1.2 Accessible documentation 682 | 683 | Product documentation provided with the ICT shall be made available in at least one of the following electronic formats: 684 | 685 | a) a Web format that conforms to clause 9, or 686 | 687 | b) a non-web format that conforms to clause 10. 688 | 689 | 12.2.2 Information on accessibility and compatibility features 690 | 691 | ICT support services shall provide information on the accessibility and compatibility features that are included in the product documentation. 692 | 693 | 12.2.3 Effective communication 694 | 695 | ICT support services shall accommodate the communication needs of individuals with disabilities either directly or through a referral point. 696 | 697 | 12.2.4 Accessible documentation 698 | 699 | Documentation provided by support services shall be made available in at least one of the following electronic formats: 700 | 701 | a) a Web format that conforms to clause 9, or 702 | 703 | b) a non-web format that conforms to clause 10. 704 | 705 | 13.2 Access to relay services 706 | 707 | Where ICT systems support two-way communication and a set of relay services for such communication is specified, access to those relay services shall not be prevented for outgoing and incoming calls. 708 | 709 | 13.3 Access to emergency services 710 | 711 | Where ICT systems support two-way communication and a set of emergency services for such communication is specified, access to those emergency services shall not be prevented for outgoing and incoming calls. 712 | --------------------------------------------------------------------------------