2

I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.

While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.

  • We can use JAWS scripting to instruct the browser how to read the page.
  • We can use ARIA attributes to give the pages better organization and structure.

Specifically, I'm trying to figure out: Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?

Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).

Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(

Many thanks for any input.

user2177720
  • 65
  • 4
  • I'm not sure how/if JAWS scripts are used by other assistive tech. Are you only targeting JAWS? ARIA should have wider support across other mediums. Please share your page markup if you'd like more concrete assistance. – Canica Mar 21 '19 at 16:38
  • You are aware though, that screen reader support is only one part of accessibility? Don't forget about keyboard navigation, resizing text w/o breaking layout, sufficient contrast, tolerance towards other input modes, etc. – Andy Mar 21 '19 at 18:51
  • The customer has insisted that we use JAWS because that is their go to screen reader. I'm mostly trying to figure out which path I should take. JAWS scripts or an ARIA makeover. I like the ARIA makeover better, but if I uploaded a sample page, your eyes would glaze over and I'm not even sure ARIA will give the page enough clarity. – user2177720 Mar 21 '19 at 19:47
  • Quick update on this project: We mostly opted for some strategic use of aria-attributes. The goal wasn't to make a perfect ADA experience. It was to make a passable experience for a screen reader with the goal of better fixes in the future. To that end, making good use of the following aria attributes did the trick for us: aria-label to force the screen reader to read whatever is in that label aria-required aria-invalid to flag an error and the aria role These got us to a good place. It was a lot of grunt work, but it did the trick. – user2177720 Jul 13 '19 at 14:32

2 Answers2

1

Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.

In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include

  • speaking out information that you have to find elsewhere on the page
  • adding keyboard navigation where it's missing

Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).

What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.

But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.

I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.

Andy
  • 4,783
  • 2
  • 26
  • 51
  • I hadn't considered this as an option. It might be compelling enough to dive a little deeper as it might be the lightest weight solution (and that's what I'm looking for). We don't have any JAWS or ARIA expertise in house. Thanks for sharing the idea. – user2177720 Mar 21 '19 at 19:51
  • I'm choosing this as my answer because it's best for me in my situation. I'm looking for a lightweight way to make the pages work. The biggest hurdle is our skill set. I'm quite sure we could find someone to master JAWS scripting and deal with browser and version incompatibilities, but, that's not going to happen in 6 weeks. I also found an accessbility javasscript library (https://allyjs.io/) which might help in my efforts. Thanks for the insights. – user2177720 Mar 27 '19 at 12:15
  • Just wanted to follow up on the wisdom of javascript. After studying JAWS, we learned that JAWS scripting is no joke. It brings a mountain of maintenance dealing with different users that have different versions. If you have a SaaS application, different customers will have different experiences. Then you have the browser issues. If you have lots of javascript, you'll have problems. I'm making a good deal of headway creating a javascript function that cleans up the page elements and makes a generic screen reader work better. Probably not completely compliant, but the pages work. – user2177720 Apr 05 '19 at 16:08
  • Thanks for the update. Is the allyjs library you found of use to you? If it is, it would be a great addition to the answer, I think. – Andy Apr 05 '19 at 18:16
  • 1
    I didn't actually use allyjs. I looked at it briefly, but quickly learned that the customer was mostly looking for something quick that would help the screen reader. The quickest path was to add aria-labels, 'roles', aira-invalid attributes in key places. A few days of dummy work got things to a passable state. – user2177720 Aug 29 '19 at 18:45
1

The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.

If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc

That's how you create structure on your page that a screen reader user will appreciate.

If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.

If you can't use a native <h2>, then make sure you use the appropriate role and attributes.

<div role="heading" aria-level="2">this is my custom h2</div>

If you can't use a native <header>, then make sure you use the appropriate role and attributes.

<div role="banner">my header stuff goes in here</div>

I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.

Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.

slugolicious
  • 15,824
  • 2
  • 29
  • 43
  • I agree, in theory, about the semantic HTML. That's not really an option at this point because of the messiness of the pages. We're mostly looking for a lightweight way to fix this and I'm hoping to get some clarification on the relationship between JAWS scripts and ARIA. We don't have experts in either area. It's sounding as though there is no simple path and that the fix will have to be in the form of ARIA to clean up the structure and JAWS scripts to make the screen reader work. I like the javascript idea presented below, but need to study how it could work – user2177720 Mar 25 '19 at 14:27