[Athen] Accessibility of SAP Web Dynpro Apps?

[Mary J Ziegler]

Hi Al,

Yes!  We are dealing with this at MIT.   I'm not the one to speak with you about the nitty gritty programming details, but I can put you in touch with accessibility experts and developers here that can.

I'd summarize the situation as follows:  The overarching issue is that what SAP deems accessible is not what our accessibility experts would - for example, SAP does not base their applications on common HTML markup and expects JAWS users to have changed many settings within JAWS to navigate their apps.  The best (or worst, I should say) example of this is that SAP recommends JAWS users turn the Virtual cursor off in order to navigate their web apps.   Of course, that's completely the opposite of what JAWS users are accustomed to doing on the web.

We are in the middle of trying to sort out what's doable and what's not (in terms of programming for accessibility with webdynpro for ABAP) and also trying to convince SAP to change their approach.   It's an uphill battle, but we're happy to have others join in... please feel free to contact me directly.

Best,
Mary

Mary J. Ziegler
IT Manager,  Accessibility and Usability
MIT Information Services and Technology (IS&T)
ATIC Room 7-143
617.258.9328
maryz at mit.edu<mailto:maryz at mit.edu>


On Nov 15, 2011, at 10:03 AM, Al Puzzuoli wrote:

Curious as to experiences others have had as regards accessibility of SAP NetWeaver and related ABAP Web Dynpro apps? Our university recently migrated all its core business applications to this architecture.  Thus far, our findings in terms of accessibility have been iffy at best. Many pages sport a bunch of clutter. Jaws detects frames and buttons that our developers didn’t put there, can’t see, and can’t explain. When a developer asks the toolkit for a heading level, they get a visually bolded heading, but apparently no HTML markup a screen reader can actually see as a heading. If they ask for a button, they get something that looks like a button but is really a link. Radio buttons and check boxes do weird things, there are odd graphics associated with them that have nonsensical labels. There are date pickers that Jaws can’t even see unless the virtual cursor is turned off, and even then, they are barely usable.
We’ve looked at forms designed out of the box by SAP that exhibit the same issues. Are there things our devs should be aware of that would help them in the design of more accessible Web Dynpro pages? The problem is that we are a large campus, and there are likely hundreds of developers working on numerous  projects at any given time. I’m not sure how to go about helping them all.

I really believe though that this is a systemic issue . If a developer designs a page, adds the appropriate headers and buttons, the  underlying software should be doing a better job of insuring that the code it generates is accessible.
Is anyone else seeing similar issues?
Thanks,

Al Puzzuoli
Michigan State University
Information Technologist                                       http://www.rcpd.msu.edu
Resource Center for Persons with Disabilities  517-884-1915 120 Bessey Hall East Lansing, MI  48824-1033
_______________________________________________

athen-list mailing list
athen-list at mailman1.u.washington.edu<mailto:athen-list at mailman1.u.washington.edu>
http://mailman1.u.washington.edu/mailman/listinfo/athen-list













-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20111115/f7207b92/attachment.html>