Feedback Mechanism Sample Clauses

Feedback Mechanism. Indicate any specific resources devoted to handling accessibility questions/concerns and provide the contact information for these resources. Provide a specific mechanism for users to contact in order to: Request accessibility-related assistance Report accessibility problems Request information in accessible alternate formats Please complete the following pieces of required information. Most of the inquiries are sufficiently answered with a yes or no. Include a statement that includes a clear commitment to equal access for all users and a summary of the conformance initiatives related to accessibility standards: Indicate whether a review of your product’s compliance was based on each of the following standards: Section 508 of the Rehabilitation Act: WCAG 2.1 (or most recent version) Level A & AA: EPub3 (or most recent version) Accessibility Guidelines: Indicate whether you included your most recent VPAT (Version 2.3 or most recent version preferred): Answer the following questions related to the information on the VPAT (Version 2.3 or most recent version preferred): Can all functionalities be accessed using keyboard only? Are appropriate color contrasts used? Are all pictures/images tagged with alternative text? Is your multimedia captioned? Is a transcript provided for any audio only components? Is your multimedia audio described when necessary? Are forms and challenge options (like CAPTCHAs) compatible with assistive technologies? Are all buttons, form fields, and labels compatible with assistive technologies? Do all charts and graphs have detailed description of their content? Is your product compatible with screen readers and screen magnification programs like JAWS and ZoomText? Are all Word documents and PDFs structured in an open and navigable way? Is all mathematics content created with MathML or an equally accessible format? Does your product have a touch screen? Do the buttons on your product have large bold lettering? Do the buttons on your product have Braille lettering? Does your hardware have a headphone xxxx for audio instructions? Have any other best practices or guidelines been used during design and development (Describe if yes)? Have you included results from any third-party agency with whom you have worked to evaluate accessibility support? Have you included results from any formal internal testing process you used to determine accessibility support? Did you conduct user testing with persons with disabilities to verify accessibility supp...
Sample 1
AutoNDA by SimpleDocs
Feedback Mechanism. Indicate whether you have specific resources devoted to handling accessibility questions/concerns and provide the contact information for these resources, so buyers or users can request accessibility-related assistance, report accessibility problems, and/or request information in accessible alternate formats. This form serves as a means to document accessibility gaps associated with Electronic Information Technology products and to indicate plans for addressing these gaps in the future. We ask that you complete the form as follows:
Sample 1
Feedback Mechanism. Parents/guardians will receive updates regarding progress within the transition program (including any employment roadblocks that are disability related) via the IEP process, as well as attend the established bi-annual parent night. Ongoing collaboration and dialogue will occur between DELEG/MCB, their collaborating agencies and MISD TC/VI staff to monitor and assess this partnership transition program. A transition skills portfolio (written, audio, visual, video or any combination) will be developed annually for each student by the skills provider to document skill acquisition. This portfolio will be shared with and housed by the local district to be part of the student’s permanent school record.
Sample 1
Feedback Mechanism. The Partner should establish a feedback mechanism to gather students’ experiences and suggestions regarding the OpenEDG resources. This feedback will be valuable for both the Partner and OpenEDG in understanding the effectiveness of the resources and identifying areas for improvement.
Sample 1
Feedback Mechanism. The Recipient shall maintain, throughout Project implementation, and publicize the availability of a feedback mechanism, in form and substance satisfactory to the Association, to receive feedback and hear and determine fairly and in good faith all complaints raised in relation to the Project, and take all measures necessary to implement the determinations made by such mechanism in a manner satisfactory to the Association.
Sample 1
Feedback Mechanism. This should be introduced as a process to do the perception index and community survey.
Sample 1
Feedback Mechanism. Within 60 days of the Effective Date of this Agreement, the University will submit to OCR for review and approval a proposed Notice to individuals with disabilities regarding: (i) how to submit user feedback and formal grievances under Section 504 regarding the accessibility of the NYU Website; and (ii) how to access content, including Legacy and Archived Content, on the NYU Website that may not be currently accessible. a) Within 30 days of receiving OCR’s approval of the proposed Notice, the University will officially adopt and post the approved Notice through a link included in the footer of the NYU Website’s home or landing page(s), all subordinate pages, and on NYU’s Accessibility web pages located at xxxxx://xxx.xxx.xxx/life/information- technology/help-and-service-status/accessibility.html and xxxxx://xxx.xxx.xxx/students/communities-and-groups/students-with-disabilities.html. b) Within 45 days of receiving OCR’s approval of the proposed Notice, the University will submit to OCR written certification of its posting of the Notice at the locations required in this Agreement.
Sample 1
AutoNDA by SimpleDocs
Feedback Mechanism. Within 60 days of the Effective Date of this Agreement, the University will submit to OCR for review and approval a proposed Notice to individuals with disabilities regarding: (i) how to submit user feedback and formal grievances under Section 504 regarding the accessibility of the YU Website; and (ii) how to access content, including Legacy and Archived Content, on the YU Website that may not be currently accessible. a) Within 30 days of receiving OCR’s approval of the proposed Notice, the University will officially adopt and post the approved Notice through a link included in the footer of the YU Website’s home or landing page(s), all subordinate pages, and on YU’s Accessibility web page located at xxxxx://xxx.xx.xxx/accessibility-statement. Within 45 days of receiving OCR’s approval of the proposed Notice, the University will submit to OCR written certification of its posting of the Notice at the locations required in this Agreement.
Sample 1

Related to Feedback Mechanism

  • Consultative Mechanism The parties agree that a precondition for the effective operation of the Agreement is the establishment of consultative mechanisms with the Company. To this end, a Consultative Committee, comprising of Company appointed representatives and employee elected representatives should be established and maintained. Officers of the Union shall have a standing invitation to attend any such meeting. The purpose of the Consultative Committee shall be to consult, develop, recommend and assist to implement strategies and measures designed to achieve the objectives outlined under Clause 4 of this Agreement.

  • Validation Mechanism To be eligible for articulation, the student must show evidence of their CompTIA A+ certification and it must have been issued within three (3) years prior to their enrollment in the program.

  • CONSULTATIVE MECHANISMS 11.1 Effective consultation is essential for continuous workplace reform and such consultation can take place at any time during the life of a project. Consultative Committees may be set up on larger projects for this purpose. The Consultative Committee will operate for the purpose of continually assessing the efficiency of working arrangements, monitoring the outcomes of this Agreement, coordinating training activities and sharing pertinent information.

  • Dispute Resolution Mechanisms Registry Operator will comply with the following dispute resolution mechanisms as they may be revised from time to time: the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN (posted at xxxx://xxx.xxxxx.xxx/en/resources/registries/pddrp and xxxx://xxx.xxxxx.xxx/en/resources/registries/rrdrp, respectively). Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Agreement) following a determination by any PDDRP or RRDRP panel and to be bound by any such determination; and the Uniform Rapid Suspension system (“URS”) adopted by ICANN (posted at xxxx://xxx.xxxxx.xxx/en/resources/registries/urs), including the implementation of determinations issued by URS examiners. CONTINUED OPERATIONS INSTRUMENT The Continued Operations Instrument shall (a) provide for sufficient financial resources to ensure the continued operation of the critical registry functions related to the TLD set forth in Section 6 of Specification 10 to this Agreement for a period of three (3) years following any termination of this Agreement on or prior to the fifth anniversary of the Effective Date or for a period of one (1) year following any termination of this Agreement after the fifth anniversary of the Effective Date but prior to or on the sixth (6th) anniversary of the Effective Date, and (b) be in the form of either (i) an irrevocable standby letter of credit, or (ii) an irrevocable cash escrow deposit, each meeting the requirements set forth in item 50(b) of Attachment to Module 2 – Evaluation Questions and Criteria – of the gTLD Applicant Guidebook, as published and supplemented by ICANN prior to the date hereof (which is hereby incorporated by reference into this Specification 8). Registry Operator shall use its best efforts to take all actions necessary or advisable to maintain in effect the Continued Operations Instrument for a period of six (6) years from the Effective Date, and to maintain ICANN as a third party beneficiary thereof. If Registry Operator elects to obtain an irrevocable standby letter of credit but the term required above is unobtainable, Registry Operator may obtain a letter of credit with a one-year term and an “evergreen provision,” providing for annual extensions, without amendment, for an indefinite number of additional periods until the issuing bank informs ICANN of its final expiration or until ICANN releases the letter of credit as evidenced in writing, if the letter of credit otherwise meets the requirements set forth in item 50(b) of Attachment to Module 2 – Evaluation Questions and Criteria – of the gTLD Applicant Guidebook, as published and supplemented by ICANN prior to the date hereof; provided, however, that if the issuing bank informs ICANN of the expiration of such letter of credit prior to the sixth (6th) anniversary of the Effective Date, such letter of credit must provide that ICANN is entitled to draw the funds secured by the letter of credit prior to such expiration. The letter of credit must require the issuing bank to give ICANN at least thirty (30) calendar days’ notice of any such expiration or non-renewal. If the letter of credit expires or is terminated at any time prior to the sixth (6th) anniversary of the Effective Date, Registry Operator will be required to obtain a replacement Continued Operations Instrument. ICANN may draw the funds under the original letter of credit, if the replacement Continued Operations Instrument is not in place prior to the expiration of the original letter of credit. Registry Operator shall provide to ICANN copies of all final documents relating to the Continued Operations Instrument and shall keep ICANN reasonably informed of material developments relating to the Continued Operations Instrument. Registry Operator shall not agree to, or permit, any amendment of, or waiver under, the Continued Operations Instrument or other documentation relating thereto without the prior written consent of ICANN (such consent not to be unreasonably withheld). If, notwithstanding the use of best efforts by Registry Operator to satisfy its obligations under the preceding paragraph, the Continued Operations Instrument expires or is terminated by another party thereto, in whole or in part, for any reason, prior to the sixth anniversary of the Effective Date, Registry Operator shall promptly (i) notify ICANN of such expiration or termination and the reasons therefor and (ii) arrange for an alternative instrument that provides for sufficient financial resources to ensure the continued operation of the critical registry functions related to the TLD set forth in Section 6 of Specification 10 to this Agreement for a period of three (3) years following any termination of this Agreement on or prior to the fifth anniversary of the Effective Date or for a period of one (1) year following any termination of this Agreement after the fifth anniversary of the Effective Date but prior to or on the sixth (6) anniversary of the Effective Date (an “Alternative Instrument”). Any such Alternative Instrument shall be on terms no less favorable to ICANN than the Continued Operations Instrument and shall otherwise be in form and substance reasonably acceptable to ICANN. Notwithstanding anything to the contrary contained in this Specification 8, at any time, Registry Operator may replace the Continued Operations Instrument with an Alternative Instrument that (i) provides for sufficient financial resources to ensure the continued operation of the critical registry functions related to the TLD set forth in Section 6 of Specification 10 to this Agreement for a period of three (3) years following any termination of this Agreement on or prior to the fifth anniversary of the Effective Date or for a period one (1) year following any termination of this Agreement after the fifth anniversary of the Effective Date but prior to or on the sixth (6) anniversary of the Effective Date, and (ii) contains terms no less favorable to ICANN than the Continued Operations Instrument and is otherwise in form and substance reasonably acceptable to ICANN. In the event Registry Operator replaces the Continued Operations Instrument either pursuant to paragraph 2 or this paragraph 3, the terms of this Specification 8 shall no longer apply with respect to the original Continuing Operations Instrument, but shall thereafter apply with respect to such Alternative Instrument(s), and such instrument shall thereafter be considered the Continued Operations Instrument for purposes of this Agreement. REGISTRY OPERATOR CODE OF CONDUCT In connection with the operation of the registry for the TLD, Registry Operator will not, and will not allow any parent, subsidiary, Affiliate, subcontractor or other related entity, to the extent such party is engaged in the provision of Registry Services with respect to the TLD (each, a “Registry Related Party”), to: directly or indirectly show any preference or provide any special consideration to any registrar with respect to operational access to registry systems and related registry services, unless comparable opportunities to qualify for such preferences or considerations are made available to all registrars on substantially similar terms and subject to substantially similar conditions; register domain names in its own right, except for names registered through an ICANN accredited registrar; provided, however, that Registry Operator may (a) reserve names from registration pursuant to Section 2.6 of the Agreement and (b) may withhold from registration or allocate to Registry Operator up to one hundred (100) names pursuant to Section 3.2 of Specification 5; register names in the TLD or sub-domains of the TLD based upon proprietary access to information about searches or resolution requests by consumers for domain names not yet registered (commonly known as, “front-running”); or allow any Affiliated registrar to disclose Personal Data about registrants to Registry Operator or any Registry Related Party, except as reasonably necessary for the management and operations of the TLD, unless all unrelated third parties (including other registry operators) are given equivalent access to such user data on substantially similar terms and subject to substantially similar conditions. If Registry Operator or a Registry Related Party also operates as a provider of registrar or registrar-reseller services, Registry Operator will, or will cause such Registry Related Party to, ensure that such services are offered through a legal entity separate from Registry Operator, and maintain separate books of accounts with respect to its registrar or registrar-reseller operations. If Registry Operator or a Registry Related Party also operates as a provider of registrar or registrar-reseller services, Registry Operator will conduct internal reviews at least once per calendar year to ensure compliance with this Code of Conduct. Within twenty (20) calendar days following the end of each calendar year, Registry Operator will provide the results of the internal review, along with a certification executed by an executive officer of Registry Operator certifying as to Registry Operator’s compliance with this Code of Conduct, via email to an address to be provided by ICANN. (ICANN may specify in the future the form and contents of such reports or that the reports be delivered by other reasonable means.) Registry Operator agrees that ICANN may publicly post such results and certification; provided, however, ICANN shall not disclose Confidential Information contained in such results except in accordance with Section 7.15 of the Agreement. Nothing set forth herein shall: (i) limit ICANN from conducting investigations of claims of Registry Operator’s non-compliance with this Code of Conduct; or (ii) provide grounds for Registry Operator to refuse to cooperate with ICANN investigations of claims of Registry Operator’s non-compliance with this Code of Conduct. Nothing set forth herein shall limit the ability of Registry Operator or any Registry Related Party, to enter into arms-length transactions in the ordinary course of business with a registrar or reseller with respect to products and services unrelated in all respects to the TLD. Registry Operator may request an exemption to this Code of Conduct, and such exemption may be granted by ICANN in ICANN’s reasonable discretion, if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for the exclusive use of Registry Operator or its Affiliates, (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (iii) application of this Code of Conduct to the TLD is not necessary to protect the public interest. REGISTRY PERFORMANCE SPECIFICATIONS DNS. Refers to the Domain Name System as specified in RFCs 1034, 1035, and related RFCs. DNSSEC proper resolution. There is a valid DNSSEC chain of trust from the root trust anchor to a particular domain name, e.g., a TLD, a domain name registered under a TLD, etc.

  • Alternative Warning Xxxxxxx may, but is not required to, use the alternative short-form warning as set forth in this § 2.3(b) (“Alternative Warning”) as follows: WARNING: Cancer and Reproductive Harm - xxx.X00Xxxxxxxx.xx.xxx.

  • Feedback You have no obligation to provide us with ideas, suggestions, or proposals (“Feedback”). However, if you submit Feedback to us, then you grant us a non-exclusive, worldwide, royalty-free license that is sub-licensable and trans- ferable, to make, use, sell, have made, offer to sell, import, reproduce, publicly display, distribute, modify, or publicly perform the Feedback in any manner without any obligation, royalty, or restriction based on intellectual property rights or otherwise.

  • Rights Protection Mechanisms Registry Operator shall implement and adhere to the rights protection mechanisms (“RPMs”) specified in this Specification. In addition to such RPMs, Registry Operator may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. Registry Operator will include all RPMs required by this Specification 7 and any additional RPMs developed and implemented by Registry Operator in the registry-­‐registrar agreement entered into by ICANN-­‐accredited registrars authorized to register names in the TLD. Registry Operator shall implement in accordance with requirements set forth therein each of the mandatory RPMs set forth in the Trademark Clearinghouse as of the date hereof, as posted at xxxx://xxx.xxxxx.xxx/en/resources/registries/tmch-­‐requirements (the “Trademark Clearinghouse Requirements”), which may be revised in immaterial respects by ICANN from time to time. Registry Operator shall not mandate that any owner of applicable intellectual property rights use any other trademark information aggregation, notification, or validation service in addition to or instead of the ICANN-­‐

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!