Announcement

**sujaydutta** · 14 Nov 2011, 07:49

Any update on my above post? Am I doing something wrong or there are still issue with WAI-ARIA in SmartGWT 2.5?

**Isomorphic** · 14 Nov 2011, 11:12

Please read the Accessibility overview in the docs. You are currently testing compliant with the accessibility system turned off.

**sujaydutta** · 14 Nov 2011, 11:49

I am not sure I follow when you say "You are currently testing compliant with the accessibility system turned off.". I have accessibility turned on via JSNI using the following:

public static native void enableAria() /*-{
$wnd.isc.screenReader = true;
$wnd.isc.setScreenReaderMode(true);
}-*/;

You can see for some of the items, such as TextItem the ARIA role shows up (e.g. role="textbox" aria-label="Text Item1"), however it's not consistent for all. For e.g. for IButton there's no ARIA tag and since buttons are rendered as <td>, that's a problem if it doesn't have any ARIA role. There are a few other items as mentioned above that are not ARIA compliant.

Also in a few of the posts you mention to pass application mode hint, that can't be right since setting body role to application using <body role="application"> puts the entire application in application mode and the screen reader doesn't treat the app as a web page, i.e. no headers are shown in JAWS (INSERT+F6), or landmarks (INSERT+CTRL+SEMICOLON).

**Isomorphic** · 14 Nov 2011, 11:55

You've never mentioned what version you're testing, but all of those elements have ARIA tags in the most recent release. So although you've shown code for enabling screenReaders, it appears that in reality you're either not running that code, or you're using an older release. Also note, you're picking specific tags and expecting the ARIA roles and state to be there - in some cases they are not on the specific tag you're looking at.

For a starting point, grab a recent release, and run through it with NVDA, where there is no need to enable application mode, it just works. Once you've seen the whole system working, you can troubleshoot what's wrong with your JAWS tests (you may, for example, also have an old JAWS).

**sujaydutta** · 14 Nov 2011, 12:14

I am using latest SmartGWT 2.5, GWT 2.3 and using JAWS 12, but the problem is the SmartGWT controls are not spitting out the ARIA tags. I can upload my test sample if you want to take a look?

**Isomorphic** · 14 Nov 2011, 12:18

There are some post-2.5 ARIA fixes in nightlies - the 2.5.x nightlies at smartclient.com/builds are what we recommend testing with, they contain only fixes relative to the 2.5 release. But just a note that something appears to be more fundamentally wrong, as you are reporting problems that were not present in 2.5. If you continue to have troubles, we recommend going through the install procedure from scratch on a new machine, to ensure you do not have stale files.

**sujaydutta** · 14 Nov 2011, 13:51

I have uploaded the main files, and I am using the following links for:

SmartGWT 2.5: http://code.google.com/p/smartgwt/downloads/list
GWT 2.3: http://code.google.com/webtoolkit/versions.html

Attached Files

**Isomorphic** · 14 Nov 2011, 13:51

No need. As context, our ARIA support has already been signed off as complete by multiple customers who had their app reviewed for accessibility. So please first follow our recommendations in terms of getting into a known correct state, then, if you problems, we will recommend things to check out.

**sujaydutta** · 14 Nov 2011, 13:58

Where are the recommendations? I have followed the recommendations that I have gathered from the forum posts.

**Isomorphic** · 14 Nov 2011, 14:01

See our previous posts in this thread (get a nightly, check with NVDA, rebuild your project, etc). There's nothing we can help you with until you get into a state where you're seeing what all our other users are seeing.

**sujaydutta** · 14 Nov 2011, 14:07

But if SmartGWT 2.5 supports WAI-ARIA tags, shouldn't the production release for 2.5 generate the ARIA tags for all form components? I don't think they are please use the test files I sent to test it out.

The problem is not with JAWS or NVDA, if the components are not plain html components, then they (div/td tags etc.) need to have the aria role in them. Some of the SmartGWT components don't generate the ARIA tags now. I am not sure how you say ARIS support was signed off.

**Isomorphic** · 14 Nov 2011, 14:10

?

We're familiar with ARIA and how it used - as we just mentioned, our technology has already been vetted by actual testing.

If you would please follow our recommendations then we can potentially help you with any further problems you might have. But will not be responding any more on this thread if you are just going to ignore what we're telling you.

**chacomo** · 15 Nov 2011, 04:04

Hi sujadutta,

I think you haven't posted which browser you are using. Is it Internet Explorer?

I have mentioned in the post "Accessibility issues on IE" that all Canvas objects, e.g. Buttons don't get any aria role using Internet Explorer and SGWT 2.5. It is totally skipped:

Code:

var isFF3 = isc.Browser.isMoz && isc.Browser.geckoVersion >= 20080529;

// use two DIVs: an inner one to hold the content, and an outer one for clipping       
        var output = isc.StringBuffer.concat(
       
            // the clipDiv           
            "<div id='" , this._getClipDivDOMID(),
            "' eventProxy=" , eventProxy,
            (isFF3 && this.ariaRole ? " role='" + this.ariaRole + "'" : ""),
            (isFF3 && this.ariaState ? this.getAriaStateAttributes() : ""),
            (this.className ? " class='" + this.className + "'" : ""),
            focusString,

Isomorphic posted that they will check on the missing role settings using IE.
But I haven't got a response, yet.

If you are even using IE 8 than also the FormItem role setting isn't done, because the flag "liteAria" is true for IE 8. But according to your reports it seems you get the roles for FormItems, e.g. TextItem.

The not read value in the SelectItem might also be related to the usage of IE.
I have found that for some reason the table element doesn't always get the focus in in the new (SGWT 2.5) method putNativeFocusInRow as this.hasFocus is false.

Code:

_putNativeFocusInRow : function (rowNum, suppressElementFocus) {
        this._nativeFocusRow = rowNum;

        if (suppressElementFocus || !this.hasFocus) return;

        var element = this.getTableElement(rowNum);
        if (element == null) return;

        
        isc.EH._focusCanvas = null;
        element.focus();
        isc.EH._focusCanvas = this;
    },

In the SGWT 2.5 nightly build from the 14th of October some changes have been done in this area to fix a problem with the focus traversal in screen reader mode. But I think they had no positive effect on the element focus setting.

Regards,
Manuel

**sujaydutta** · 15 Nov 2011, 06:41

Manuel,

I am using FF 7 and IE 9 with the 2.5 production release of SmartGWT. I will download the latest nightly and test again. This is a big deal for SmartGWT to support, companies are being forced to support accessibility these days, so the framework we use should obviously support accessibility :)

**chacomo** · 15 Nov 2011, 06:58

Hi sujadutta,

check if the aria roles of Canvas elements are set using FF7.
Most of our customers are using IE, so we have to deal with the IE/accessibility issues.

Regards,
Manuel

Announcement

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment