About a year ago was the first time I had to deal with the topic Accessibility in great detail concerning the WebDynpro ABAP Technology. It was back then when our applications (90% standard with some tweaks and enhancements here and there) were tested against the WCAG 2.0 Standard and, of course, there was room for improvement to be found. One particular point of criticism was “Where are my access keys at, bro? Can’t talk into my keyboard to navigate to where I want to, can I, bro?”.
This situation and a hint from a co-worker made me pay attention to the UI-Property “activateAccessKey” for the first time. For a couple of applications that are bottom line programmed in Freestyle-UI, things weren’t very hard to achieve and didn’t require too much brainpower:
. . . lo_el_ui_buffer ?= view->GET_ELEMENT( ID = 'Foobar' ). IF lo_el_ui_buffer IS NOT INITIAL. CALL METHOD lo_el_ui_buffer->SET_ACTIVATE_ACCESS_KEY EXPORTING VALUE = abap_true. ENDIF. . . .
Hooray for activated Access Keys! However, it didn’t take long before the first GUIBB-based FPM-Application came around the corner where this approach doesn’t work, because:
- The UI-Elements’ IDs are created generically and can change whenever the UI-Tree changes, so you can’t address them statically in design time
- You don’t really want to program static stuff into the Generic UIBB FPM WDA Components, because ewwww
Thus I “designed” (it’s pretty trivial actually, if you’re much into dynamic programming) the following Class that can be implemented into a Post Exit of WDDOMODIFYVIEW. The Following picture shows what the Class does (note: the picture isn’t accessible 😈 ). In Before: I only share the approach, I don’t share the coding.
I have then created Enhancement Implementations for each Top-Level-GUIBB-Component and implemented Post Exits for WDDOMOIFY-View calling my class dependent on which application is used(so I’m still in control which Application benefits from this). Example for FPM_FORM_UIBB:
And finally here’s the result (example from the WDA based Leave Request):
Notice the underlined First Letters of the Labels? (the 4th Input field has an access key too, but the label has been changed and the Letter that has been assigned by the framework doesn’t exist in the new label, in case you were wondering).
The downer of that whole approach is, that you have to touch the FPM UIBB Components once with means of an enhancement which is not very elegant. However, the preceding feeder classes do not know what UI-Element Types the fields from the field catalog will have, since this is decided later in the FPM Component Configuration where it’s also not possible do declare anything access-key-wise so there is no other way (as far as I know).
That’s it folks. Maybe this approach is going to be useful to some of you when the Accessibility-Bat comes around 😉