Please report any problems to the Shared Tools Team at st-help@doit.wisc.edu    Broken Links? Missing Macros? WIKI Retiring Plugins
Child pages
  • ITAccessCG Meeting 2015-12-03
Skip to end of metadata
Go to start of metadata

Agenda & Notes - Accessibility/Usability of IT Coordinating Group (Coordinating Group)

Dec 03, 2015, 11:00-12:00, McBurney Center, Graaskamp Rm 

  1. Agenda Review
      

  2. Notes from the previous meeting . Please send comments or changes to Gary.
     

  3. Scheduling for November and December - Decided to leave schedule every-other Thursday as scheduled to keep working on documenting workflows/ best practices and to develop a complaint response process.

  4. Brief updates
    1. Post-production media captioning RFP
      Action:
      • See Dec 3 email from Phyllis to the team's list – Great summary of current status!
      • A quesstions was raised:
        • In the campus documentation, do we mention using YouTube captions along with how to clean them up?
          (Currently there is no mention of YouTube, which might be more harmful because silence means there is also no mention of the need to clean them up.)
            
    2. Drop-in sessions attendance
      Action:
      • Deferred until next meeting.
      
  5. NFB Web Accessibility Training Day
    Two main pearls of information:
    1. Access Control Board will definitely be incorporating WCAG 2.0 by reference. It could still take a year or more before the section 508 refresh occurs.
    2. One of the best (perhaps THE best) ways to work with vendors on accessibility issues is to write good bug reports. When the slides are available there is a whole presentation on how to do this.
    Action:
    • Gary will forward links and other information when the slides are available.
    • Not sure when that will be.
        
  6. Accessibility Complaint Response Process 
    1. Handout: See attachments to this page.
    2. Discussion: Generate ideas for completing the document(s), where to post it, how to vet it, and how to advertise that it is available.
    3. Action:
      • Gary has notes, will start working on revision. Will need to consult with Todd.
      • Purpose of the procedure should be to give units a path to follow to help address accessibility needs.
      • How to communicate the procedure? Probably via the DoIT accessibility resources page.
      • Major change in approach was proposed:
        • Have two documents:
          • A super simple document for web developers and content providers. Would cover (roughly):
            • importance of responding quickly and helpfully
            • initial intake of a request
            • immediately informing Legal Services if at any point the requestor is threatening legal or regulatory action.
            • initial response to the requestor, (try to contact them, learn more, etc. Let them know you care.)
            • initial attempt(s) to resolve locally, (could include asking for advice from accessibility@cio.wisc.edu or Univ Marketing).
            • making sure to close the loop with the requestor to check how they feel about the resolution, or lack thereof.
            • further escalation if necessary
          • A more detailed procedural document for use by those who are handling escalations. Those handling the escalations can evaluate the situation and help guide the developers and content providers through the escalation process. No need to train everyone else on how escalation works.
        • Change the focus from level of risk to a combination of level of severity and level of difficulty in resolving.
          • Folks don't have a good enough understanding of risk.
          • Also makes it sound like we are more concerned about reducing risk than we are about making things accessibile! (The two go together and are compatible, but the impression that we give to the reader is important.)
          • Along these lines, keep the three levels (I, II, III) but tie them to a combination of severity of the problem and difficulty of resolution. This would roughly align with the level of risk, but would avoid discussing it in terms of risk.
             
  7. Getting it Right, From the Beginning - Documenting processes and best practices during Phase I (all)
    • References: Web Accessibility Workflow - Drafts, Web Accessibility Workflow - AssumptionsAccessible Development and Publishing Phase I Project.
    • Objective: Discuss issues during the meeting. Between meetings keep working on the workflows, guided by the discussion.
    • Background information:
      (From OCT 01)
      • Discussed the list of cases. Are there any missing? Duplicates? Idea is to cover case that occur on campus. Don't have to cover every possible case.
      • Documenting the different cases is what Phase I is about.
      • If the documented process is new or is an improvement to an existing process, it needs to be tested in actual use.
      • Deliverable for Phase I is a group of documented and tested processes intended to help units improve their own process.
    • Discussion: 
    • Action (from Nov):
      • Please complete scenarios by the Thursday December 17th meeting
      • Need to develop ideas for presenting the recommended workflows in ways that make it easy to match scenarios and consume the information

  8. AMP Feedback (Phil)
    1. Discussion: Preview from Phil of the need for a sub-group to provide feedback 
    2. Action (from Nov):
      1. Record issues and descriptions of design/feature issues with AMP outside of the meeting time so they can be summarized and presented to SSB Bart in early 2016
  9. Check in on other open action items (not necessarily in the order listed):

    1. Sub-group providing feedback on needed improvements in AMP
    2. Accessibility content & new it.wisc.edu site (Todd & Phyllis)
      • Objective:
      • Background information:
      • Discussion:
      • Next Steps:
    3. Accessibility accommodation response process (Todd & Gary)
      • Objective:
      • Background information:
        • From 10/22 meeting) Discussion of accessibility accommodation response
          Questions/issues to address:
          • Discussion highlighteed the need to have a response process. (Not the same as a complaint process, although we need a complaint process too.)
          • When a site or applications is not sufficiently accessible, how do we as an institution respond?
            • Start with the unit that publishes/maintains the web resource.
            • If they can bring it to a reasonably satisfactory conclusion, great!
            • If they can't resolve it. What then?
          • What about communicating our existing informal response process?
            • If the unit can't resolve it, the unit can contact accessibility@cio.wisc.edu for advice.
            • Still leaves us with the question: if that advice is not sufficient to resolve it, what then?
        • From (10/22 meeting) Discussion of how making things accessible ties into usability.
          Questions/issues to address, implied by the discussion:
          • Not always clear if it is a usability problem or an accessiblity problem.
          • Not always enough information. Not always possible to get enough information.
          • Are we communicating enough about usability and relationship between usability and accessibility?
      • Discussion:
      • Next Steps:
    4. Commitee membership (Todd)
      • Objective: Options for short, middle, and longer-term sustainability of the committee
      • Background information:
      • Discussion:
        • Consider sending a message via MTAG, inviting units to appoint someone to the Coordinating Group.
        • Nature of a volunteer based group
        • Campus need for a sustained and cohesive effort
        • Unknown future of new positions
      • Next steps:
    5. Captioning Contract (Sandi Arendalkowski, Todd Schwanke)

      • Objective:
      • Background information:
      • Discussion:
      • Next Steps:
        • What are next steps?

        • What can the committee contribute?

    6. Accessibility policy draft & edits (Todd & Gary)
      • Objective: Review, and if warranted, update our approach to accessibility policy.
      • Background information:
        • (From an earlier meeting) Online course accessibility policies
          • Receiving regular questions about what the policy is related to online courses and interpretations of the web policy
          • Dealing more directly with what should be done proactively vs. as an accommodation, and with what is practical or not.
          • August IT Policy discussion notes address this. See IT Policy Forum 2015-08.
        • (From 10/22 meeting) Discussion about standards-based approach to making things accessible.
          Questions/issues to address, implied by the discussion:
          • Laws prohibit discrimination. That get's interperted into: follow this or that standard.
          • Compliance with standards does not equal compliance with the law – it helps with compliance.
          • Standards-based approach can distract service providers from considering the needs of their entire community of users.
            • Example: a perception that if we can't make a tool accessible we have to stop using it.
            • Not necessarily. Instead, could provide an alternative that is sufficiently functional, timely, etc. so that offering it as an alternative is not discrimination, it's accomodation.
          • Is our campus policy taking the right approach?
      • Discussion:
      • Next steps: 
    7. Enhanced voiceover PowerPoints (Todd)
      • Objective:
      • Background information:
      • Discussion:
        • What tools are in this space?  - Articulate Storyline, Adobe Captivate, Adobe Presenter, others
        • How can a tool be identified that meets the needs/preferences of designers, instructors, students (including those with disabilities)
        • Determine what can be done to move ahead in this critical area
      • Next Steps: 
    8. Browser support trends, accessibility, and policy context (Todd)
      • Objective:
      • Background information:
      • Discussion: Deferred.
      • Next Steps:
    9. Unizin & Courseload accessibility follow-up

      • Objective:
      • Background Information:
      • Discussion:
      • Next Steps (from Aug 6):
        • Possible sub-committee to assist Bruce in assuring Unizin and related systems are accessibile.
        • Discuss in future.
           
  10. Upcoming agenda items
    • See "On Deck Items", "Future Agenda Items" below.

Future agenda items:

  • Get more info on new Executive Committee meeting (invite Chris Holsman to a meeting?) (12/4 note: Check with Phyllis on this item.)
  • How to communicate our progress to faculty.
    • One way might be to work through the Equity and Diversity Committees that are advisory to deans and are composed of faculty and staff.

    • Accessibility and diversity are related, followup (suggested at May 1, 2014 meeting). Note: we made brief contact with Hazel Symonette at the T&LS on May 19.

  • Accessibility of email. (Campus Communicators have discussed this, see 10/30 notes.)
  • Go over the implications of the new Wisconsin law on accessibile educational materials in higher education (suggested at April 17, 2014 meeting)
  • Brainstorm how to build awareness of instructional content accessibility (suggested at May 29 meeting)
  • Brainstorm "Resources to help developers and content providers to incorporate accessibility into their existing processes" (suggested at March 6, 2014 meeting) 

Future dates:

  • Accessing Higher Ground conference – Nov 2015 (will be the week before Thanksgiving), see: http://accessinghigherground.org/  
  • Report to the sponsors – December 31, 2015. 
  • Community of Educational Technology Support (ComETS) annual meeting – January 2016, see: https://comets.wisc.edu/  
  • Workshop sponsored by the Coordinating Group – Tentatively: March 3, 2016 
  • Report to the sponsors – March 31, 2016. 
  • Showcase –  April 2016
  • Teaching and Learning Symposium – May 2016
  • Report to the sponsors – June 30, 2016.
  • National Disability Employment Awareness Month – October, 2016, see http://www.dol.gov/odep/topics/ndeam/    
  • Report to the sponsors – September 30, 2016.

Furture meetings:

  • Coordinating Group Meeting 2017-09-11, 11:00-12:00, McBurney Graaskamp Rm
  • Coordinating Group Meeting 2017-09-28, 11:00-12:00, McBurney Graaskamp Rm
  • Coordinating Group Meeting 2017-10-12, 11:00-12:00, McBurney Graaskamp Rm
  • Coordinating Group Meeting 2017-10-26, 11:00-12:00, McBurney Graaskamp Rm
  • Coordinating Group Meeting 2017-11-09, 11:00-12:00, McBurney Graaskamp Rm
  • Coordinating Group Meeting 2017-11-23, 11:00-12:00, McBurney Graaskamp Rm
  • Coordinating Group Meeting 2017-12-14, 11:00-12:00, McBurney Graaskamp Rm
  • Coordinating Group Meeting 2017-12-28, 11:00-12:00, McBurney Graaskamp Rm (tentative) *
  • Coordinating Group Meetings

* Tentative meeting on Dec 28, between the holidays.

Coordinating Group members:

MemberUnitMemberUnitMemberUnit
Sandi ArendalkowskiDoIT MarketingSteven BoldtDCSGary De CluteCIO Office
Brendon DybdahlHousingApril EbacherDoIT ADIRyan EngelLSS
Matt GoinsDoIT PTEAndy GoldsteinDoIT ATLaura GradyDoIT Marketing
Jamie GutkowskiDoIT ADIJohn HareDoIT EIS  
Jini JastiLaw SchoolHaley KerkhoffDCSAl NemecCALS
Jessie NemecLibraries

Casey Schacher

LibrariesTodd Schwanke, (co-chair)McBurney Center
James SkempBusinessGarrett SmithDoIT ATPhyllis TreigeDoIT Marketing
Nick WeaverUniv. MarketingPeter Weil (co-chair)Univ. Marketing  
Also attendingUnitAlso attendingUnitAlso attendingUnit
Phil JochimsenDoIT EISLee KonradLibraries  
vacant, (sponsor)CIO OfficeCathy Trueba, (sponsor)Office of Compliance  

Liaisons

Attachments:

File Created Comment

UW-Web-Accessibility-Incident-Response-DRAFT-2015-02-23.docx

Nov 17, 2015 10:53 2015-02-23 version

Web accessibility complaint response process-2014-12-16.docx

Nov 17, 2015 10:36 2014-12-16 version

Contact

  • No labels