[ADF EMG] I am an accessibility engineer

[DAVE ROBINSON]

Hi! My name is Dave Robinson and I'm a developer on the ADF Faces team. I've been the lead on accessibility for the group for the past few years. I'm also the lead for the group for bringing ADF Faces to WCAG 2.0AA standards, which is an active development for an upcoming 12.x release.

To set the stage, our current ADF versions have separate modes to support accessibility.

Screen Reader Mode

Screen reader mode provides an alternate rendering of components than our default mode. The purpose of this mode is usage by visual impaired users. Like the default (rich) mode, it provides components that can be used without a mouse (keyboard only). In addition, it uses HTML markup that is optimized for use with screen reader applications (like JAWS). The screenReader mode facilitates disabled users, but may degrade the output for nondisabled users or users with only some physical limitations.

High Contrast Mode

In high contrast mode ADF Faces provides visual content that is friendly with high contrast. High contrast mode is intended to make ADF Faces applications compatible with operating systems or browsers that have high contrast features enabled. For example, ADF Faces changes its use of background images and background colors in high contrast mode to prevent the loss of visual information while in high contrast mode.

Large Fonts Mode

In large fonts mode ADF Faces provides content that is friendly with browser zoom modes. In default mode, most text and many containers have a fixed size to provide a consistent and well defined look. In large fonts mode, text and containers are specified to have a scalable size.


One of the exciting developments in accessibility is the WAI-ARIA specification. By using WAI-ARIA, rich UI HTML content can be made accessible without having to downgrade to a simpler presentation (like we currently do) and requiring a separate screen reader friendly mode. In our new WCAG 2.0 development work, we are utilizing WAI-ARIA to eliminate the need for accessibility modes completely.

I'm looking forward to this discussion!

--
Thanks,
Dave

[Amr Gawish]

Hi Dave,

First very nice to see you, I was missing these kind of discussions in ADF EMG, and specially when it comes to accessibility as it's a very interesting topic, since most of the stuff you are talking about are not even fully implemented in the modern browsers (eg: ARIA role attributes) and so it's good to hear that you and the ADF team are working on it.

I'm wondering about how are you enforcing such behavior in the context of the ADF Application among ADF Developers, for example I know that when you put an af:image tag you are prompt with a warning message that tells you to add a short description, however developers often ignores that. Is there anything in the upcoming 12c that rather enforces this for accessibility?

Also how ADF is going to support aria-* attributes in ADF, is it going to introduce a specific set of aria-* attributes to original ADF components or are we going the facelets way?

Best Regards,

Amr

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[DAVE ROBINSON]

I don't work as much on the audits and design time side of things. We do have the warnings that appear in JDeveloper. Internally we run audits as well against our apps code base and find things that need fixing that way. We also have specific Acc QA efforts. I think the most important part is for everyone to understand what is required for accessibility and keep it in mind when developing. I like to tell people that they need to understand accessibility as they are required to write accessible code.

The aria tags will probably mostly be behind the scenes - they won't be exposed in most cases. One exception to this that comes to mind is 'landmark' which we expose on several of our layout type components so you can identify a part of the page as main, navigation, search, etc.

We already have some ARIA in our code base, like role/state used by menus and tabs, landmarks, and live region.

Thanks,

Dave

On 4/22/2014 9:18 AM MT Amr Gawish said the following:

[Blake Sullivan]

On the audit side, as long as an audit exists in JDeveloper, you can change the severity of the audit in Tools->Preferences->Audit->Profiles->ADF->ADF Faces->Accessibility and share the profile across developers.  These audits are warnings by default, but you can make them errors if you wish.

-- Blake Sullivan

[Luc Bors]

Hi Dave,

nice to see you here.

I actually do not use any of the accessibility modes. This is mainly due to the fact that functional designers at customers usually are not aware of the fact that ADF does have support for this. How will Oracle spread the word and help us consultants to enable customers and design teams ?

Will there be documentation and also online demos ?

Thanks

--

[james.nurthen]

Hi. My name is James Nurthen and I work in the Accessibility Program Office at Oracle. I am involved with products across all of our Lines of Business not just ADF. In the Accessibility Program Office we set the standards that our products need to follow which as Dave has mentioned are currently based on WCAG 2.0 AA.

I'm also involved at the W3C where I participate in the Protocols and Formats Working Group which has created the WAI-ARIA specification to enable accessibility in Rich Internet Applications, as well as on the Web Content Accessibility Working Group which create the WCAG Guidelines and associated specific techniques.

I'll be helping out Dave in this discussion, particularly where the conversation veers towards more general accessibility issues.

Regards,

James

[James Nurthen]

Luc,

One of the reasons that we aim to remove accessibility modes, where practical, in the future is due to the fact that customers are often unaware that these modes exist - despite them being mentioned in both the VPATs (Voluntary Product Accessibility Templates) for the products as well as in the documentation. The Accessibility chapter of the ADF documentation talks about setting the modes - http://docs.oracle.com/middleware/1212/adf/ADFUI/af_access.htm

You can also enable the modes in the demos for ADF which are available at http://jdevadf.oracle.com/ from either the Settings menu, or the Accessibility link on the page.

Regards,

James

[Jan Vervecken]

hi Dave and James

When aiming for a standard like "WCAG 2.0 AA", is there an "easy" (automated) way to verify to what extend a specific ADF application complies to such a standard?

many thanks
Jan Vervecken

[James Nurthen]

Jan,

Unfortunately only a small percentage of WCAG 2.0 AA standards can be checked automatically. The following article by Karl Groves goes into more detail on this - http://www.karlgroves.com/2012/09/15/accessibility-testing-what-can-be-tested-and-how/

ADF does provide audits for some standards but these audits can only determine that a property which is required for accessibility has been completed. They do not determine if the quality of the text or other information that has been supplied is sufficient to create an accessible application.

Regards,

James

--

[Andreas Koop]

Hi Dave,
Hi James

thanks for taking your time and joining the ADF EMG Forum for that very important topic in Web application development. Most of the web apps for public sector projects must be accessible. 

Some time ago I asked myself if (and how) Oracle is testing ADF Accessibility features with e.g. JAWS - a screen reading tool which is widely used. Maybe you could elaborate on how ADF Features are tested for accessbility and certified against a certain JAWS version. Are „real JAWS users“ involved? Why I am asking? We got feedback from real users that e.g. components like the ADF-Tree or treeTable is really hard to use in screenReader Mode compared to a folder tree in windows file explorer. (Plus more shortcomings on others components. The details would be to much for this forum I guess...)

In one of our current ADF / WebCenter projects we are facing the challenge that an accessibility switcher is not allowed to be used. This is pretty hard because some of the components use e.g. the table layout without presentation role (attribute on table element). Do you have any practical advices how to make this possible in ADF 11gR1 ? Do you have any plans to make ADF Apps accessible in default mode? From which version on? Would it be possible for developers to decide on their own to put ARIA attributes on components? JAWS users, that are testing the ADF Apps, are complaining about no usage of WAI-ARIA attributes (required, hidden, has pop-pup and so on….) It would be cool, to have these attributes set by default. 


Looking forward to your responses. 

Kind regards,
Andreas Koop
www.enpit-consulting.com

[DAVE ROBINSON]

We do test with JAWS. And we do have, as you say, real JAWS users as part of our staff. One such person teaches people internally in how to use JAWS, a training that begins with "OK, throw away your mouse and turn off your monitor". The mouse is strictly forbidden in the class, though after initial chuckles he allows monitor usage in the class.

OK, bullet round:

>> we are facing the challenge that an accessibility switcher is not allowed to be used
This environment is not going to be accessible, everything currently depends on this screen reader mode being on.

>> Do you have any plans to make ADF Apps accessible in default mode?
Yes

>> From which version on?
A future 12.x version to start.

>> Would it be possible for developers to decide on their own to put ARIA attributes on components?

Doubtful, as they don't have access to the HTML DOM structure encapsulated by the component. ADF should be doing this, as we know when something is role="button" and has state="disabled". We do have landmark attribute on some layout components, which translates to the ARIA landmark value applied.

JAWS users, that are testing the ADF Apps, are complaining about no usage of WAI-ARIA attributes (required, hidden, has pop-pup and so on….) It would be cool, to have these attributes set by default.

>> This is part of our current work for WCAG 2.0AA uptake. We do have some ARIA used currently, around menus and tabs, and sprinkled elsewhere I believe, but not much currently.

Thanks,
Dave

On 4/22/2014 3:51 PM MT Andreas Koop said the following:

[Chris Muir]

Dave and James

Thanks for sharing to date.

On a slightly different track from big brother ADF, can you comment on
accessibility on mobile and tablet devices please?

I note that there is a level of churn occurring on these devices right
now with respect to accessibility as I guess firstly it's a relatively
new market still, and in turn each vendor (Apple/Google) seem to be
dictating what accessibility means for each of their platforms (at least
from my independent eye) rather than an overseeing committee.

So firstly can you raise any comments or share experiences with what's
happening in the mobility world for accessibility? Are there any
general trends that developers should be aware of or good resources in
this area to read? Are there any areas Oracle is investigating or
working with that customers should be aware?

And secondly, even with big brother ADF and general web technologies, do
you see an impact of mobility accessibility ideas into traditional web
technologies? I know the accessibility standards are always evolving,
so is it likely we'll see even faster churn with the web accessibility
standards?

Thanks for your time and comments.

CM.

On 22/04/2014 11:01 pm, DAVE ROBINSON wrote:
> Hi! My name is Dave Robinson and I'm a developer on the ADF Faces team.
> I've been the lead on accessibility for the group for the past few
> years. I'm also the lead for the group for bringing ADF Faces to WCAG
> 2.0AA standards, which is an active development for an upcoming 12.x
> release.
>
> To set the stage, our current ADF versions have separate modes to
> support accessibility.
>

> *Screen Reader Mode*

>
> Screen reader mode provides an alternate rendering of components than
> our default mode. The purpose of this mode is usage by visual impaired
> users. Like the default (rich) mode, it provides components that can be
> used without a mouse (keyboard only). In addition, it uses HTML markup
> that is optimized for use with screen reader applications (like JAWS).
> The screenReader mode facilitates disabled users, but may degrade the
> output for nondisabled users or users with only some physical limitations.
>

> *High Contrast Mode*

>
> In high contrast mode ADF Faces provides visual content that is friendly
> with high contrast. High contrast mode is intended to make ADF Faces
> applications compatible with operating systems or browsers that have
> high contrast features enabled. For example, ADF Faces changes its use
> of background images and background colors in high contrast mode to
> prevent the loss of visual information while in high contrast mode.
>

> *Large Fonts Mode*

>
> In large fonts mode ADF Faces provides content that is friendly with
> browser zoom modes. In default mode, most text and many containers have
> a fixed size to provide a consistent and well defined look. In large
> fonts mode, text and containers are specified to have a scalable size.
>
>
> One of the exciting developments in accessibility is the WAI-ARIA
> specification. By using WAI-ARIA, rich UI HTML content can be made
> accessible without having to downgrade to a simpler presentation (like
> we currently do) and requiring a separate screen reader friendly mode.
> In our new WCAG 2.0 development work, we are utilizing WAI-ARIA to
> eliminate the need for accessibility modes completely.
>
> I'm looking forward to this discussion!
> --
> Thanks,
> Dave
>

> --
> --
> You received this message because you are subscribed to the ADF
> Enterprise Methodology Group
> (http://groups.google.com/group/adf-methodology). To unsubscribe send
> email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution
> 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any
> content sourced must be attributed back to the ADF EMG with a link to
> the Google Group (http://groups.google.com/group/adf-methodology).
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ADF Enterprise Methodology Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to adf-methodolo...@googlegroups.com

> <mailto:adf-methodolo...@googlegroups.com>.

[Amr Gawish]

Hi Dave,

Thanks for answering my question and I'm glad that this will be done by default, but the thing about ARIA attributes is that it be highly customizable, for instance if I want to use an af:link but I'm styling it as a button, I'll not be able to do that!

Also to continue broadening the scope to cover more than ADF. What is the strategy for other middleware products like WebCenter Portal, WebCenter Sites and Forms Editor of BPM to support accessibility? Will these products also adhere to the WCAG 2.0 compliance you are doing with ADF?

Best Regards,

Amr

email to adf-methodology+unsubscribe@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution
3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any
content sourced must be attributed back to the ADF EMG with a link to
the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google
Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to adf-methodology+unsubscribe@googlegroups.com

<mailto:adf-methodology+unsub...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--- You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodology+unsubscribe@googlegroups.com.

[James Nurthen]

Amr,

On Thu, Apr 24, 2014 at 9:24 AM, Amr Gawish <amr.g...@gmail.com> wrote:

Hi Dave,

Thanks for answering my question and I'm glad that this will be done by default, but the thing about ARIA attributes is that it be highly customizable, for instance if I want to use an af:link but I'm styling it as a button, I'll not be able to do that!

This is true. However, in order to make a link work as a button you also need to add more event handlers (you need to activate on a space key press). It is not just as simple as adding the role. Why not just use a button control in the first place? The "first rule of ARIA" is not to use ARIA unless you really have to. In this case a native button is better.

 

Also to continue broadening the scope to cover more than ADF. What is the strategy for other middleware products like WebCenter Portal, WebCenter Sites and Forms Editor of BPM to support accessibility? Will these products also adhere to the WCAG 2.0 compliance you are doing with ADF?

The general direction is to move our internal standards towards WCAG2 AA.

Regards,

James

 

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.

[DAVE ROBINSON]

Amr,

If you have specific use cases where it makes sense for the ARIA values to be exposed, please let us know. We are making these values available where it makes sense, like the landmark values.

Thanks,
Dave

On 4/24/2014 10:31 AM MT James Nurthen said the following:

Amr,

Best Regards,

Amr

email to adf-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution
3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any
content sourced must be attributed back to the ADF EMG with a link to
the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google
Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to adf-methodolo...@googlegroups.com

<mailto:adf-methodolo...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
--

You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--- You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[DAVE ROBINSON]

James might have a better answer here than me, as I'm more involved on the nuts and bolts side of accessibility in ADF Faces. But I really don't see iOS/Android going off in their own directions in regards to accessibility. Apple's implementation of VoiceOver, in my opinion, is brilliant, and shows their commitment to accessibility by having it as part of the base OS. It still works off the industry standard ARIA, so I don't think they've wandered off the reservation in regards to standards, but rather created a nice newly thought out screen reader app that has a completely different approach than desktop versions like JAWS.

In regards to ADF, mobile apps AT like VoiceOver will work with our screen reader optimized content. But in the long run this is definitely an area that will benefit from having fully accessible content in regular 'rich' rendering mode.

Thanks,
Dave

On 4/23/2014 6:22 PM MT Chris Muir said the following:

[James Nurthen]

Chris,

I'll try to talk about these. Please see inline.

On Wed, Apr 23, 2014 at 5:22 PM, Chris Muir <chris...@gmail.com> wrote:

Dave and James

Thanks for sharing to date.

On a slightly different track from big brother ADF, can you comment on accessibility on mobile and tablet devices please?

When talking about accessibility on mobile it is important to differentiate between HTML and native applications. However, for both there isn't really a lot of difference between desktop and mobile. For HTML you essentially follow WCAG2 just like for desktop applications.

For applications you do the same things you do in a native desktop product. You need to follow either Google's or Apple's accessibility development guidelines just as you would follow Microsoft's guidelines to create an accessible Windows app or Java's guidelines to create an accessible Java Application.

 

I note that there is a level of churn occurring on these devices right now with respect to accessibility as I guess firstly it's a relatively new market still, and in turn each vendor (Apple/Google) seem to be dictating what accessibility means for each of their platforms (at least from my independent eye) rather than an overseeing committee.

Assuming we are talking about native applications I'm not sure why this is a problem. They are creating the accessibility APIs which the Assistive Technologies are using so it is entirely appropriate that they determine how to develop their own guidelines in order to communicate correctly with those. This is the same on any native platform like Windows or even Java.

 

So firstly can you raise any comments or share experiences with what's happening in the mobility world for accessibility?  Are there any general trends that developers should be aware of or good resources in this area to read?  Are there any areas Oracle is investigating or working with that customers should be aware?

An excellent resource for mobile accessibility is the BBC - http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile 

I believe these standards go beyond WCAG and veer into a "best practices" kind of level in some places so I wouldn't ever want to require developers to follow them - but a developer reading this would certainly understand accessibility better.

The W3C also has a mobile accessibility task force as part of WCAG and (i think) the Educations and Outreach working groups of the Web Accessibility Initiative. Hopefully we will see WCAG techniques for mobile out of this soon.

 

And secondly, even with big brother ADF and general web technologies, do you see an impact of mobility accessibility ideas into traditional web technologies?  I know the accessibility standards are always evolving, so is it likely we'll see even faster churn with the web accessibility standards?

The great thing about mobile is that it forces you to simplify your UI designs which is almost always a good thing for accessibility. It is much easier to use a page with 10 entry fields as an AT user than one with 200.

I don't think we will see faster churn on standards. Indeed I don't forsee WCAG changing in response to mobile - as WCAG was written in a technology agnostic manner - but I do see specific techniques which work well for mobile being developed.

[Ultan Ó Broin (Oracle Applications User Experience]

Great to see this topic raised. I used to be the owner for accessibility side of EBS doc, and I've done some work in the non-profit sector too (not to mention an MSc on Anti-Social Media - and the lack of accessibiltiy there). on to ym question; How are gestures on mobile devices  handled from an accessibility perspective with AMX? What is the equivalent of a pinch of swipe for a user with a motor impairment for example?

U

[Andreas Koop]

Hi Dave, Hi Amr,

from our JAWS testers / users we know that there is need for the following ARIA attributes (at least)

- Required field labels are marked with „Label (required)“ which is quite long and could also be shortend by „*“ plus having the WAI-ARIA „aria-required“ attribute set

- Popups, that will be opened by command links or buttons should be marked with the ARIA attriute „aria-haspopup“

- Hidden Elements should be marked with ARIA attribute "aria-hidden"

Hope to see improvements in the future. JAWS users will love it. ADF will gain popularity.

Best regards,

Andreas Koop

www.enpit-consulting.com

[DAVE ROBINSON]

Thanks for sharing this. These are some of the top use cases that we've identified as well.

Thanks,
Dave

On 4/27/2014 7:23 AM MT Andreas Koop said the following:

[DAVE ROBINSON]

That's a really interesting question! Being in development we are focused on coding to the standard, and the job of the various OS/AT (like VoiceOver) is to take that accessible content and present it to users in a way that it is fully accessible. I did find some information about switch control, assistive touch, and Siri at this link:

https://www.apple.com/support/accessibility/physicalmotorskills/

Thanks,
Dave

On 4/26/2014 11:03 AM MT Ultan Ó Broin (Oracle Applications User Experience said the following:

[Chris Muir]

At this point as the thread naturally concludes, it's a good time for me to wind this effort up.  There might be a few more posts after this but I need to call "time!" at some point.

I'd like to extend the thanks of all members to both Dave and James for participating and sharing their limited time, especially with the current internal deadlines taking focus.  For some of our internal teams talking to customers is a scary exercise, but both gentlemen were more than happy to take this challenge on & share their knowledge and expertise.  I hope the discussion has been useful for Oracle customers, and also gives you a little idea of what happens behind the scenes in developing a large & sophisticated product like ADF, there is a huge array of people and skills involved.  Thanks Dave and James for giving some insight into the whole Oracle engine, and more importantly information around the important area of accessibility :-)

I'd also like to thank the EMG members who took time out to post questions and replies to the thread.  Quite a few people behind the scenes mentioned the "I am" threads are one of the most valuable exercises the group undertakes, and these threads only succeed with members actually participating - otherwise it just becomes another Oracle press release - so thanks to you too.

I'll continue to seek other teams to join us for our next "I am" thread.

Regards,

Chris Muir

ADF EMG Mod & Oracle Product Management