Policy Automation for B2C Service

Get Involved. Join the Conversation.

Topic

    Sheri Hastings
    Making OPA interviews compliant with the Americans with...
    Topic posted March 31, 2017 by Sheri HastingsSilver Medal: 2,000+ Points 
    138 Views, 7 Comments
    Title:
    Making OPA interviews compliant with the Americans with Disabilities Act
    Content:

    I have an OPA  interview called from Service Cloud that I need to make compatible with the Americans with Disabilities Act.
    Here are three examples of what I need to do to make the interviews more accessible for sight impaired people. I have no idea how to access the HTML inside the interview to fix these things:

    1. I need  to ensure that error messages are explicitly indicated when the user clicks the next button on an interview screen.
    Currently  when a user does not enter a value for a required field, the error message "This value is mandatory" does not receive focus.  As a result, as creen reader user is unaware of the problem area(s)  on the page. 

    2. when I have a calendar question, the calendar element is not keyboard accessible in IE11.
     

    3. When I use checkboxes for Boolean attributes  they do no display a visable focus indicator in firefox.

     

    Comment

     

    • Sheri Hastings

       

      This article shows what we need to change to make these pages comply with the WCAG guidelines, but that’s already information I know.  What I don’t know is how to edit the code to apply these guidelines.   http://www.oracle.com/us/corporate/accessibility/templates/t2-6197.html

    • kevin wan

      1. The mandatory error message is associated with the input control using correct aria attributes. If user tabs on or off the control, screen reader is able to read the error correctly. 

      2. The keyboard accessible interface for calendar control is typing into the Edit field
       

      3. Which Firefox version are you using? I tried the latest version and version 47, it seems working fine.

    • Fiona Guy

      Just to add that you can find more information on Oracle Policy Automation accessibility in the online documentation:
      http://documentation.custhelp.com/euf/assets/devdocs/february2017/PolicyAutomation/en/Default.htm#Guides/Getting_Started/Accessibility_overview.htm

      Also thanks for raising this - we do take accessibility very seriously in the OPA team and thoroughly test every version for compliance prior to release. Smart self-service advice should be accessible by everyone!

       

       

    • Sheri Hastings

      Thank you Fiona

      I think these instructions are about making OPA accessible for OPA developers. We're interested in making OPA interviews accessible for the end users of those interviews.  What I am wondering is where to edit the code to format the interviews to make them ADA accessible.  

    • Davin Fifield

      Hi Sherri,

      For the first item, the current OPA behavior is WCAG compliant: when Next is pressed, each field with an error is annotated with information that lets screen readers know about them, without any need for one or more of those errors to be given focus. 

      If you absolutely need to set the focus on the first such error on the page when it refreshes after pressing Next, you could add some JavaScript to the interview that looked for the error tag (sorry I don't know exactly how the aria tag is structured that indicates the error), and gave the focus to the first such tag it finds when the page is loaded.

      Exactly how you'd do that would probably need a bit of trial and error from someone with more JavaScript skills than I have!

      Davin.

    • Fiona Guy

      It refers to both - out-of-the box the end-user interviews are accessible by default. If you find otherwise please let us know. 

      If you add your own custom interview screens or controls then you need to be sure your own code meets accessibility requirements.

    • Davin Fifield

      Ah yes, thanks Fiona. That topic also explains that the aria-invalid attribute is used to indicate which controls have errors.