University Councils and Committees
Page tree

Accessibility ICT Policy Council 
Tuesday, July 27, 2021
3:00 - 4:00 PM
Zoom (Please see Outlook Invite for Details)

Members: Lisa Andreotta, Donna Carelli, Melanie Domanico, Bethany Heaton Crawford, Angela King Taylor, Vince Patriarco, Lana Pettit, Miguel Pica, Paula Possenti-Perez, Pamela Thomas, Brian Tibbens, Robin Wade, and Scott Warren

Co-chairs: Jenny Gluck and William Myhill

Guests: Michael Morrison, Matthew Warne

Minutes: Christian Jones

Minutes

  1. Welcome/Announcements (William)
    • The group welcomed Michael Morrison, Associate Director of Academic Service Centers, and Matthew Warne, Senior Instructional Technology Analyst, from ITS to aid with the conversation around Authoring Tool Accessibility Guidelines (ATAG), recommendation 7a.
  2. Review Table of Recommendations (Group)
    1. AICTPC Table of Recommendations
      1. Recommendation 11 - Policy Update
        • The committee reviewed the language for this recommendation and determined it should specifically reference the ICT Accessibility Policy where restricted access is defined. The new language reads as:
          • “Agree with this recommendation to exempt property management building codes, as they relate to ADA specifications for embedded building maintenance and monitoring equipment, and make the evaluation exempt from the policy as articulated in the Accessibility ICT Policy under the definition of ‘Restricted Access to the Technology.’ This exemption strictly applies to work done by facilities. Examples of software for this exemption include (but are not limited to) software used to configure and manage energy controls for heating and air conditioning units, devices to read usage and monitor utility meters (e.g., electricity, water, natural gas), and software to configure and control lighting systems.”
      2. Recommendation 9a - Policy Update
        • Scott Warren recommended clarifying that by “archived” we are not referring to University Archives (University History, Records Management, etc.), that we’re talking about local archiving as opposed to centralized archiving.  
          • University Archives has a more active component to it than the definition we are using when talking about archived content. When we say “if it’s archived, leave it alone,” we’re not necessarily talking about University Archived content. Some University Archives content is active and public. 
          • To the extent that electronic content is requested, it then needs to become active and accessible. 
          • Across the University there is content outside of University Archives that is (generically speaking) “archived,” some of which happens to be in a digital format. To the extent that it is digital content (housed in University Archives or elsewhere), for the purposes of this Policy, it is non-active content and would not need to be remediated unless requested for use. 
          • There was a recommendation to remove “archived” from the recommendation language. 
          • Under definitions, we can note that “archived” in its broadest definition refers to, for example, inactive, archived web pages. We would then refer to that policy definition in the recommendation. 
          • William offered the suggestion to do away with the word “archived” entirely and refer to this content as “legacy content, ” since this is already defined in the policy. The group agreed and the new recommendation language will read as:
            • “Anything that is active and inaccessible needs to be remediated; any legacy content that is inactive can be left alone. If it’s inactive, leave it alone/get an exception, but if it’s active/public, we need to make sure it’s accessible. Active content will take highest priority.  Owners of inaccessible active content should also offer an option for remediation on demand. Upon adoption of Policy, owners will be given a year to review inaccessible active content then come up with a plan for addressing this content with timelines for remediation, replacement, or abandonment.”
        • Another note worth clarifying is that we are not asking the University to remediate content over the course of a year, more so that they are being expected to identify inaccessible content to better enable the University to understand the volume of the work ahead.  
  3. Outstanding Action Items
    1. Purchasing Policy - update on scheduling with smaller group 
      • The group will be meeting next Friday, August 6th.
    2. Adding an associate dean, faculty, and grad student to AICTPC
      • If you know of anyone who could join our committee to represent the graduate student body, faculty, or an associate dean, please send any recommendations to Jenny, William, and Christian.  
  4. Recommendations 
    1. Recommendation 7a: The University intends to use ATAG (Authoring Tool Accessibility Guidelines) 2.0 to ensure that authoring tools are capable of producing accessible content. (William)
      1. Preview ATAG at a Glance
        • We have provided a link to World Wide Web Consortium (W3C)’s Authoring Tool Accessibility Guidelines (ATAG) overview, which provides something of a layperson’s guide to understanding ATAG. Many of these guidelines are similar to the web content accessibility guidelines and standards that we apply to the products we review in the Accessibility Assessment Committee.
      2. Distinguishing between an authoring tool and a software tool (Michael, Matthew)
        • We wanted to provide a distinction between applications that build content that is only viewable in that application. FlipBoard, for example, can build content and to view that content you have to be in FlipBoard; you can’t view it outside the application. 
        • What we’re talking about here are apps that create content that can be viewed outside the application - WordPress, for example. WordPress (the application) needs to be able to create accessible content as the end-point of that application. PowerPoint is another application that can create content within the app and saved as a PDF, for example, that would also be accessible. ATAG at a Glance addresses the content, itself, but not the application that creates the content. That’s the difference between recommendation 7a and 9a. 
        • Video can also be created and viewed outside of the application. Kaltura is a video application that can be used simply as a player (a video from another system can be uploaded to Kaltura and viewed). Similarly, you can use Kaltura to record a video based on your screen presentation that’s ingested into the system. If your screen contrasts too low, that is what will show in Kaltura, and you can actually edit that within Kaltura. You can also export it and present it in another format (YouTube, attachment to an e-mail, etc.). 
        • Textbooks that are bought from a vendor as an e-book can be added to Blackboard and viewed there.
        • Because of the many nuances of the technological capabilities, it is important when writing policy guidelines to help articulate which area the tool should be evaluated in and under which criteria.  
        • This recommendation is intended to be applied to the tool that’s used to create accessible content. Both the tool and the content it creates have to be accessible. 
          • If you’re using a tool that doesn’t allow the application of alt tags, for example, the content created will not be accessible. 
          • There are applications that export formats that don’t copy metadata from an accessible document to create an equally accessible version of that document.
        • We’re also talking about web tools vs desktop tools. InDesign is a desktop tool, but its content (same with MS Office Suite) can be shared via the web. In most cases, we’d be looking at digital, web-based outcomes (accessible e-mail content, for example). 
        • The distinction between this recommendation and 9a is whether we can view the content created outside the application that created it. PlayPosit content can only be viewed inside PlayPosit, for example, so when we evaluated the PlayPosit application, we assessed all parts of it. For 7a, you create accessible content that can then be used in other ways (browser/online, e-mail, etc.). We’d want to make sure the tool we’re using can create accessible content. 
        • W3C defines “authoring tool” as “any web-based or non-web-based application(s) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users),” as provides a list of examples. If we agree with this definition, we could reference the W3C’s definition in the policy. 
        • In terms of trends, technologies that weren’t web-based before are likely to move to web-based platforms. 
          • Shared via the chat, Matthew shared the W3C definition for “technology (web content),” which classifies it as “a mechanism for encoding instructions to be rendered, played or executed by user agents. Web content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end user experiences that range from static web pages to multimedia presentations to dynamic web applications. Some common examples of web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, Silverlight, Flex, and JavaScript.”
        • Perhaps we can put some loose, informal language acknowledging the W3C definition of an authoring tool but also recognizing that there are limitations to this regarding things that can be viewed on the web but not created by a web authoring tool. 
        • On a related note, in terms of content we don’t create but are purchasing/acquiring with the intent to use for training or in a class, folks should be sure that the content, itself, is accessible. While Microsoft or Adobe-produced content will likely meet accessibility standards, content found on another third party site has the potential not to, and we don’t want this to slip around the procurement process. 
  5. Next/Future Meeting
    1. Draft Language for Recommendation 7a
      • The next Council meeting will be held on Tuesday, August 10th. In the meantime, William, Jenny, and Christian will meet separately to draft language for this recommendation, and would like to invite Michael and Matthew to join for this planning discussion. 
      • W3C is a good place to start, but it might not cover the range of content that the University works with. Searching for a broader definition of ATAG could be helpful. 
      • Next planning meeting - we’ll prepare some draft language. 
      • There was mention of possible expanding 7a into a “7b” to speak to both desktop and web-based content. 
    2. Next Recommendations
    3. Language

Supplemental Materials:

Accessibility ICT Policy 

Accessibility ICT Policy - Working Document

 Standards Table for AICTPC (Draft)

Draft Legacy Software Reference Guide

Ongoing Issues to Address

  1. Glossary of Terms
  2. End of Exception Cycle
    1. The exception is only good for the term of the version. How long is the life of the exception? What triggers a review of the product?
  3. Auto-renewals
  4. Vendor-deliverables 
  5. Review of DERC Phase 2 Recommendations Communications with Council (available in the Restricted Resource Library to AICTPC members)

  6. Review Purchasing procedures manual and the Purchasing website
  7. Recruiting graduate student and associate dean-level membership
  8. WCAG Review - 1 vs 3 years

Next Meeting: Tuesday, July 27, 2021  


  • No labels