1

I have been working in the accessibility of an accordion that is used to take user input from checkboxes and return a list of criteria based on the user input. We are using Outsystems and have not been able to make the accordion accessible in JAWS for IE, chrome or firefox.

We have exhausted all our resources and rather than scrap the whole accordion, we'd like to create a version that would not involve an accordion and could pass AODA standards. I thought I could create a hidden header so that when a screen reader tabs into it, they would be notified of the accessible version available for them to use and could click the hidden header element to go to that version.

I am wondering if this is an acceptable way to create an accessible functioning page? Is there a better way to do this? Thanks

Improve this question
5
  • 1
    What you are proposing is "segregation". Historically this has not worked well. How would you feel if you were sent to a different page based on how tall you are? If accessibility is an important part of your business model (as it should be) you need to be thinking about it at the design level as well as the implementation level so that you don't end up with UI devices that you cannot build. There are plenty of resources for accessible accordions you can find by typing "accessible accordion" in google. Here's just one: mit.edu/~rjc/aria/expandingSections.html
    – Roux Martin
    Feb 17, 2017 at 8:44
  • Yes there are plenty of accessible accordion examples but the platform we are using (Outsystems) doesn't allow for editing of code at an html level.You assemble your components the and then compile and send to the browser. If it wasn't on dev I could show you an example of the extranious amount of code it produces. Also what I propose is the same thing that happens when someone on a mobile device visits a desktop and gets redirected to the mobile version.
    – tiki16
    Feb 17, 2017 at 14:06
  • The mobile/desktop issue is about the device being used and the user has a choice whether they use a mobile or sit at a desktop. Users who require accessibility concessions do not have a choice. If your platform does not allow you to build accessible solutions then you need to design around it until you can switch platforms. Adding a separate page for users with accessibility needs is extremely bad for your organisation's reputation.
    – Roux Martin
    Feb 17, 2017 at 14:11
  • That is the unfortunate issue with screen readers, browser versions, operating sytems and platforms (plugins). The bottom line is that accessibility can't always be met in every instance due to technical issues that cannot be addressed. JAWS extension for firefox doesn't work at all. To say that switching platforms, at a cost of thousands of dollars, to meet accessibility for one issue is a solution, is an overstatement. I wish there was an easier way. It's not actually a separate page, a different version of the app will load depending if the user chooses the accessible version.
    – tiki16
    Feb 17, 2017 at 17:42
  • Someone in this thread suggested that it's "segregation" to have a separate version of a site or web pages for screen-reader users. By that logic, a wheelchair ramp that's part of every building project in the US, today, is also "segregation" because it's separate from the staircase or steps that other users can take. That logic doesn't really hold up and flies in the face of how accessibility is handled for physical buildings. There are certain things like website components and stairs to a building, where you have no choice but to deliver a separate means of access to individuals that can't
    – Kurt Noble
    May 30 at 17:53

3 Answers 3

Reset to default
1

WCAG 2.0 allows a conforming alternate version if

  • the inaccessible page is accessible enough so that users that need it can find the link, and
  • the accessible page offers the same information and functionality.

See the full requirements you have to meet.

Of course it’s not a good practice to go down this route (one version for everyone is almost always preferable, for various reasons), but it’s better than not providing an accessible variant at all.

Depending on the nature of the accessibility problem with the accordion, keep in mind that screen reader users might not be the only users that have problems with it. If that’s the case, you should not visually hide the link to the accessible variant.

Improve this answer
0

If the OutSystems platform is truly the limitation, then why not ask them for support in making your accordion accessible? They clearly have some interest in fixing any such limitations having an Accessible Apps with OutSystems & WCAG 2.0 document and also a VPAT to download.

Improve this answer
0

Starting by an inaccessible thing and then turn it accessible is, generally, a very hard work.

If you can, start with a simple, non-js functional of your page, and then progressive enhance it, creating best experiences for users that have more resources.

In general, it will prevent this kind of problem.

Progressive enhancement reference:

https://www.smashingmagazine.com/2009/04/progressive-enhancement-what-it-is-and-how-to-use-it/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.