New Lectora Accessibility template
January 8, 2018 12:00 AM
I'm considering the creation of a new accessibility template that includes a variety of solutions I've found beyond standard functions in Lectora. I would love to hear what types of challenges and questions you might like to see addressed in a course, which would include the sample awt file as well. Some topics include:
- Decorative images and tab order
- Creating cross-browser tab focus
- Announcing text or screen changes for screen readers
- Accessible tables (new - based on a recent forum post)
- Color contrast
- Tools for checking accessibility
I'm not sure when I would be able to work on this, as it would mostly be during personal time which, as we all know, tends to be at a premium for personal dev time.
Discussion (5)
Great Idea! Maybe we could make this an ongoing topic for our live group discussions? We could carve out some time to build it (on the fly) during those meetings... one bite at a time (like how you would eat an elephant, ha ha!)
THOUGHTS?
I did receive the message re: the next LAUG meeting and regretfully will be out of town and unable to attend. I hate to be the one to raise a question, then disappear when it's to be discussed.
That said, I volunteer for tab order and decorative images, cross-browser tab focus, and announcing changes for screen readers. I already have a "starting" point since I'm prepping for a new teammate in my department.
Hi William,
I'll answer the second question first :) I'm use aria-live on items with changing contents, such as a button that displays information or feedback for a question. There's more control over aria-live than role=alert. Aria-live allows for "polite" (waits until the current "reading" is finished) or "assertive" (overrides what is currently being "read", so it's more like an alert). It gets tricky if you have a string of elements changing, so I try to avoid that if I can. Otherwise, "polite" works nicely. What's been the challenge for you with these?
I've attached a sample of how I use aria-live.
As for a mechanism, that's a great question. My schedule has gotten extremely packed in the last couple of weeks, so not as much time as I had hoped to be thinking about it. Random ideas include using ReviewLink, if available, to publish samples of what "we" hope to accomplish, then discuss on ReviewLink or a forum of some sort.
Jason,
I am interested in contributing to solutions (and often workarounds) to accessibility challenges in Lectora. I've come up with my own strategies and practices, but I am always looking for better, more elegant means of accomplishing those goals. What do you think would be the best mechanism for collaboration?
A more immediate question. How are you handling those cases where new content on a page is not automatically being read by screen readers? Are you using "role=alert" or "aria-live" attributes to accomplish this? I've been experimenting with adding these to HTML elements, but haven't been completely satisified with the results in testing.
Thanks, Jason. I was working on a series of pages demonstrating different solutions to the general issue of an accessible text reveal, so that it would be automatically read by a screen reader. I hadn't worked out all the details, so your file will allow me to refine it further.
I was at first leaning towards "role=alert" because it seemed that was the way things were eventually headed. I wasn't getting consistent results across browsers. I'm not sure if the alert role is designed to replace aria-live, but the usages don't seem entirely identical. I've opted for "aria-live=assertive" because I get consistent results with screen readers and browsers. An issue I have been grappling with is where to place the aria-live attribute within a nested HTML tag structure, so that not just a change of text content would trigger it, but also a change of HTML content containing text.
I've been working on developing a modal dialog box that is accessible. It has always irritated me that one (maybe the only?) of the consequences of checking the web accessibility options for titles is to change the modal popup dialog boxes to old school dialog boxes. The classic dialog boxes are good for accessibility because they trigger automatic reading by screen readers, but the text cannot be styled to make them easier to read for those with visual impairments or plain old poor vision. I think it also helps to foster the notion that design has to be visually bland and uninteresting in order to be accessible. It doesn't have to be a zero sum game. Lectora could easily make those modal boxes accessible by using aria-live attributes (and other techniques), but they have decided not to. They have just fallen back on old techniques if the designer "chooses" to make the title accessible.
I'm attaching a library object that demonstrates the accessible modal box I've come up with. Besides using aria-live=assertive, I've defined a region for the modal box using the header of the box as the label. I'd be interested in your feedback on how to improve it. Thanks.
Bill
Discussions have been disabled for this post