E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 22 (In chronological order)

From: Kevin White
Date: Fri, Nov 04 2011 8:30AM
Subject: Browser version advice in accessibility statement
No previous message | Next message →

Hi All,

I have a client who is doing some excellent work on creating an inclusive and engaging website. In order to do so they are drawing on the features provided in WAI-ARIA. This leads to some difficulties regarding browser and screen reader compatibility and we discussed how to address this. My personal opinion is to use part of the accessibility statement to highlight the efforts but point out the need for users to upgrade but I was curious to understand how people view this?

My opinion is based on the idea that ARIA provides the opportunity to help users of assistive technologies but in order to do that there is a need to use a modern browser. User may not know this and by providing information around this there is an opportunity to provide wider help.

I would be interested to hear any other views on this,

Thanks

Kevin

From: Patrick H. Lauke
Date: Fri, Nov 04 2011 9:36AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

On 04/11/2011 14:33, Kevin White wrote:
> Hi All,
>
> I have a client who is doing some excellent work on creating an inclusive and engaging website. In order to do so they are drawing on the features provided in WAI-ARIA. This leads to some difficulties regarding browser and screen reader compatibility and we discussed how to address this. My personal opinion is to use part of the accessibility statement to highlight the efforts but point out the need for users to upgrade but I was curious to understand how people view this?
>
> My opinion is based on the idea that ARIA provides the opportunity to help users of assistive technologies but in order to do that there is a need to use a modern browser. User may not know this and by providing information around this there is an opportunity to provide wider help.

Personally, I'd be all for a generic sentence mentioning that users
should - if at all possible - be using an up-to-date version of their
browser of choice...as long as you don't go down the "These pages are
best viewed in BLAH" route...

P
--
Patrick H. Lauke

From: Henny Swan
Date: Fri, Nov 04 2011 9:51AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Don't forget this is not just a browser support issue for WAI ARIA but
also an assistive tech support issue.

Screen readers have variable support for WAI ARIA and for those that
cost money it's unreasonable to expect a user to pay for the latest
version. WAI ARIA is great but should only be used if the page
absolutely can not be made accessible via other means. In other words
think about how to use it at the start of a project but implement it
only when other routes are exhausted.

At my place of work we've been trying to work out what browsers and
screen readers to best support and it is complicated. One way of
looking at it is to support the latest 3 versions of screen reader or
anything that was released up to 18 months ago.

Having a look over the WebAIM screen reader surveys does give some
anecdotal evidence of what people are using too
http://webaim.org/projects/screenreadersurvey3/

Henny

--
www.iheni.com
@iheni

On 4 November 2011 15:38, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 04/11/2011 14:33, Kevin White wrote:
>> Hi All,
>>
>> I have a client who is doing some excellent work on creating an inclusive and engaging website. In order to do so they are drawing on the features provided in WAI-ARIA. This leads to some difficulties regarding browser and screen reader compatibility and we discussed how to address this. My personal opinion is to use part of the accessibility statement to highlight the efforts but point out the need for users to upgrade but I was curious to understand how people view this?
>>
>> My opinion is based on the idea that ARIA provides the opportunity to help users of assistive technologies but in order to do that there is a need to use a modern browser. User may not know this and by providing information around this there is an opportunity to provide wider help.
>
> Personally, I'd be all for a generic sentence mentioning that users
> should - if at all possible - be using an up-to-date version of their
> browser of choice...as long as you don't go down the "These pages are
> best viewed in BLAH" route...
>
> P
> --
> Patrick H. Lauke
>

From: Aaron Leventhal
Date: Fri, Nov 04 2011 9:57AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Hi Kevin,

First, I think reasonable ARIA usage depends on the target audience and
type of content:

Content:
1. For critical pages, such as documentation and support, it seems
reasonable to support accessibility without ARIA -- only as a progressive
enhancement
2. For pages using dynamic content to spiffy it up, it seems reasonable to
use WAI-ARIA as a progressive enhancement.
3. For content such as rich internet applications, it seems reasonable to
use ARIA to its fullest power available today.

Target audience:
1. If targeting the broad public (e.g. a government website), it seems
necessary to stay on the safe side.
2. If targeting advanced technology users (e.g. a high tech company), it
seems reasonable to use ARIA a lot more, and to require a more advanced
browser - screen reader combo for content outside of the basics
(documentation, support, etc.)

Safe -- content for the broader public, or is primarily static HTML:
• IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal (version?),
System Access (version?), etc.
• Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+
• Safari 4+ with VoiceOver on Snow Leopard or later
• Mobile Safari and VoiceOver on iOS 4 or later

Full -- content for a high tech audience or must be dynamic by its nature:
• IE8+ with JAWS 10+ (unfortunately there is no live region support in
NVDA+IE)
• Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+
• Safari 5+ with VoiceOver on Lion or later
• Mobile browsers: to be determined

I'm still keeping my eye on Google Chrome. That is becoming more accessible.

Finally, regarding the upgrade message. I think this can be done in a
clever, automatic way. Basically, in the "Full" case we can put in hidden
content that only non-ARIA screen reader users will hear, a friendly
message explaining that the site uses ARIA, an advanced technology for
making websites accessible, and to please press the Enter key to learn
about supported combinations. I'm looking into some code for this.

Thoughts?

Aaron

On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = > wrote:

> Hi All,
>
> I have a client who is doing some excellent work on creating an inclusive
> and engaging website. In order to do so they are drawing on the features
> provided in WAI-ARIA. This leads to some difficulties regarding browser and
> screen reader compatibility and we discussed how to address this. My
> personal opinion is to use part of the accessibility statement to highlight
> the efforts but point out the need for users to upgrade but I was curious
> to understand how people view this?
>
> My opinion is based on the idea that ARIA provides the opportunity to help
> users of assistive technologies but in order to do that there is a need to
> use a modern browser. User may not know this and by providing information
> around this there is an opportunity to provide wider help.
>
> I would be interested to hear any other views on this,
>
> Thanks
>
> Kevin
>

From: Aaron Leventhal
Date: Fri, Nov 04 2011 10:09AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Henny, can you advise on what Opera version - screen reader version combos
work best for the "safe" and "full" ARIA cases I mentioned? I'd like to
include that in my list. Sorry for not including in the first place.

Aaron

On Fri, Nov 4, 2011 at 11:54 AM, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Kevin,
>
> First, I think reasonable ARIA usage depends on the target audience and
> type of content:
>
> Content:
> 1. For critical pages, such as documentation and support, it seems
> reasonable to support accessibility without ARIA -- only as a progressive
> enhancement
> 2. For pages using dynamic content to spiffy it up, it seems reasonable to
> use WAI-ARIA as a progressive enhancement.
> 3. For content such as rich internet applications, it seems reasonable to
> use ARIA to its fullest power available today.
>
> Target audience:
> 1. If targeting the broad public (e.g. a government website), it seems
> necessary to stay on the safe side.
> 2. If targeting advanced technology users (e.g. a high tech company), it
> seems reasonable to use ARIA a lot more, and to require a more advanced
> browser - screen reader combo for content outside of the basics
> (documentation, support, etc.)
>
> Safe -- content for the broader public, or is primarily static HTML:
> • IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal (version?),
> System Access (version?), etc.
> • Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+
> • Safari 4+ with VoiceOver on Snow Leopard or later
> • Mobile Safari and VoiceOver on iOS 4 or later
>
> Full -- content for a high tech audience or must be dynamic by its nature:
> • IE8+ with JAWS 10+ (unfortunately there is no live region support in
> NVDA+IE)
> • Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+
> • Safari 5+ with VoiceOver on Lion or later
> • Mobile browsers: to be determined
>
> I'm still keeping my eye on Google Chrome. That is becoming more
> accessible.
>
> Finally, regarding the upgrade message. I think this can be done in a
> clever, automatic way. Basically, in the "Full" case we can put in hidden
> content that only non-ARIA screen reader users will hear, a friendly
> message explaining that the site uses ARIA, an advanced technology for
> making websites accessible, and to please press the Enter key to learn
> about supported combinations. I'm looking into some code for this.
>
> Thoughts?
>
> Aaron
>
> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Hi All,
>>
>> I have a client who is doing some excellent work on creating an inclusive
>> and engaging website. In order to do so they are drawing on the features
>> provided in WAI-ARIA. This leads to some difficulties regarding browser and
>> screen reader compatibility and we discussed how to address this. My
>> personal opinion is to use part of the accessibility statement to highlight
>> the efforts but point out the need for users to upgrade but I was curious
>> to understand how people view this?
>>
>> My opinion is based on the idea that ARIA provides the opportunity to
>> help users of assistive technologies but in order to do that there is a
>> need to use a modern browser. User may not know this and by providing
>> information around this there is an opportunity to provide wider help.
>>
>> I would be interested to hear any other views on this,
>>
>> Thanks
>>
>> Kevin
>>

From: Elle
Date: Fri, Nov 04 2011 11:24AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Aaron, that's the most helpful list of recommended browser/AT combinations
that I've seen. Thank you!
While I do plan to modify it a bit according to our own browser support
levels, it really helps me in shaping what our internal corporate policy is
for AT support.

As a tangential question, do you think, then, that these scenarios are
something accessibility test labs need to have installed (ex. JAWS 7,8, and
9, for example)? Otherwise, it'd be difficult to ensure success. The
reason I ask is because AT licenses are not the same kind of cost
considerations as browser versions which are free. I have 4 computers, and
I am in the middle of requesting licenses for JAWS 11 and 12 (we already
have 10). If there are other versions that represent a better range of
use, that would be helpful to know. I tried to get this user statistics
information from Freedom Scientific, but they didn't want to give that to
me.

Cheers,
Elle

From: Aaron Leventhal
Date: Fri, Nov 04 2011 11:30AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

All I can say is that these recommendations are based on my limited knowledge and may not be perfect. I want to work with the community to further define the safe and full baselines and what techniques can/should be used in these. Plan is to do this on the aria dev portal.
-----Original Message-----
From: Elle < = EMAIL ADDRESS REMOVED = >
Sender: = EMAIL ADDRESS REMOVED =
Date: Fri, 4 Nov 2011 13:24:34
To: WebAIM Discussion List< = EMAIL ADDRESS REMOVED = >
Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Browser version advice in accessibility statement

Aaron, that's the most helpful list of recommended browser/AT combinations
that I've seen. Thank you!
While I do plan to modify it a bit according to our own browser support
levels, it really helps me in shaping what our internal corporate policy is
for AT support.

As a tangential question, do you think, then, that these scenarios are
something accessibility test labs need to have installed (ex. JAWS 7,8, and
9, for example)? Otherwise, it'd be difficult to ensure success. The
reason I ask is because AT licenses are not the same kind of cost
considerations as browser versions which are free. I have 4 computers, and
I am in the middle of requesting licenses for JAWS 11 and 12 (we already
have 10). If there are other versions that represent a better range of
use, that would be helpful to know. I tried to get this user statistics
information from Freedom Scientific, but they didn't want to give that to
me.

Cheers,
Elle

From: ihenix
Date: Fri, Nov 04 2011 11:48AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Hi Aaron,

I'm no longer at Opera so can't advise on screen reader support. There was some for Safari but nothing beyond that when I was there.

According to WhenCanIUse.com (http://caniuse.com/wai-aria) Opera Mobile and Mini have some support for WAI ARIA but as the mobile browser doesn't support speech output it's difficult to comment.

As an aside I did some testing on iOS for WAI ARIA together with Kevin Chao, results can be found here:
http://www.iheni.com/wai-aria-support-on-ios/

Henny

---
@iheni
www.iheni.com

On 4 Nov 2011, at 15:56, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:

> Henny, can you advise on what Opera version - screen reader version combos
> work best for the "safe" and "full" ARIA cases I mentioned? I'd like to
> include that in my list. Sorry for not including in the first place.
>
> Aaron
>
> On Fri, Nov 4, 2011 at 11:54 AM, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi Kevin,
>>
>> First, I think reasonable ARIA usage depends on the target audience and
>> type of content:
>>
>> Content:
>> 1. For critical pages, such as documentation and support, it seems
>> reasonable to support accessibility without ARIA -- only as a progressive
>> enhancement
>> 2. For pages using dynamic content to spiffy it up, it seems reasonable to
>> use WAI-ARIA as a progressive enhancement.
>> 3. For content such as rich internet applications, it seems reasonable to
>> use ARIA to its fullest power available today.
>>
>> Target audience:
>> 1. If targeting the broad public (e.g. a government website), it seems
>> necessary to stay on the safe side.
>> 2. If targeting advanced technology users (e.g. a high tech company), it
>> seems reasonable to use ARIA a lot more, and to require a more advanced
>> browser - screen reader combo for content outside of the basics
>> (documentation, support, etc.)
>>
>> Safe -- content for the broader public, or is primarily static HTML:
>> • IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal (version?),
>> System Access (version?), etc.
>> • Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+
>> • Safari 4+ with VoiceOver on Snow Leopard or later
>> • Mobile Safari and VoiceOver on iOS 4 or later
>>
>> Full -- content for a high tech audience or must be dynamic by its nature:
>> • IE8+ with JAWS 10+ (unfortunately there is no live region support in
>> NVDA+IE)
>> • Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+
>> • Safari 5+ with VoiceOver on Lion or later
>> • Mobile browsers: to be determined
>>
>> I'm still keeping my eye on Google Chrome. That is becoming more
>> accessible.
>>
>> Finally, regarding the upgrade message. I think this can be done in a
>> clever, automatic way. Basically, in the "Full" case we can put in hidden
>> content that only non-ARIA screen reader users will hear, a friendly
>> message explaining that the site uses ARIA, an advanced technology for
>> making websites accessible, and to please press the Enter key to learn
>> about supported combinations. I'm looking into some code for this.
>>
>> Thoughts?
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >wrote:
>>
>>> Hi All,
>>>
>>> I have a client who is doing some excellent work on creating an inclusive
>>> and engaging website. In order to do so they are drawing on the features
>>> provided in WAI-ARIA. This leads to some difficulties regarding browser and
>>> screen reader compatibility and we discussed how to address this. My
>>> personal opinion is to use part of the accessibility statement to highlight
>>> the efforts but point out the need for users to upgrade but I was curious
>>> to understand how people view this?
>>>
>>> My opinion is based on the idea that ARIA provides the opportunity to
>>> help users of assistive technologies but in order to do that there is a
>>> need to use a modern browser. User may not know this and by providing
>>> information around this there is an opportunity to provide wider help.
>>>
>>> I would be interested to hear any other views on this,
>>>
>>> Thanks
>>>
>>> Kevin
>>>

From: Christophe Strobbe
Date: Fri, Nov 04 2011 12:06PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Hi Aaron,

At 16:54 4-11-2011, Aaron Leventhal wrote:
>(...)
>
>Target audience:
>1. If targeting the broad public (e.g. a government website), it seems
>necessary to stay on the safe side.
>2. If targeting advanced technology users (e.g. a high tech company), it
>seems reasonable to use ARIA a lot more, and to require a more advanced
>browser - screen reader combo for content outside of the basics
>(documentation, support, etc.)
>
>Safe -- content for the broader public, or is primarily static HTML:
>� IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal (version?),
>System Access (version?), etc.
>� Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+
>� Safari 4+ with VoiceOver on Snow Leopard or later
>� Mobile Safari and VoiceOver on iOS 4 or later

This list reminds me of a similar list I wrote
last year (in deliverable D3.1.2 for the AEGIS
project; PDF at <http://tinyurl.com/6jjw8pz>;):

* Internet Explorer 7 with JAWS 9 on Windows XP
with Service Pack 3 (older versions of Internet
Explorer and JAWS have no support for WAI-ARIA),
* Firefox 3.0 with JAWS 9 on Windows XP with
Service Pack 3 (Firefox 2 also supported MSAA and early drafts of WAI-ARIA),
* Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
* Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
* Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack 3,
* Safari 3 on Mac OS X 10.5 with VoiceOver,
* Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
* Firefox 3.0 with GNOME's built-in magnifiers on
Ubuntu 8.04 LTS ("Hardy Heron").

This list was intended for creating accessibility
support documentation ("accessibility support" as
defined by WCAG 2.0), hence JAWS 9 instead of
JAWS 7. (JAWS 7 is still in use, even in
countries with refund schemes for assistive technologies, e.g. Belgium.)

Best regards,

Christophe


>Full -- content for a high tech audience or must be dynamic by its nature:
>� IE8+ with JAWS 10+ (unfortunately there is no live region support in
>NVDA+IE)
>� Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+
>� Safari 5+ with VoiceOver on Lion or later
>� Mobile browsers: to be determined
>
>(...)
>Thoughts?
>
>Aaron
>
>On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi All,
> >
> > I have a client who is doing some excellent work on creating an inclusive
> > and engaging website. In order to do so they are drawing on the features
> > provided in WAI-ARIA. This leads to some difficulties regarding browser and
> > screen reader compatibility and we discussed how to address this. My
> > personal opinion is to use part of the accessibility statement to highlight
> > the efforts but point out the need for users to upgrade but I was curious
> > to understand how people view this?
> >
> > My opinion is based on the idea that ARIA provides the opportunity to help
> > users of assistive technologies but in order to do that there is a need to
> > use a modern browser. User may not know this and by providing information
> > around this there is an opportunity to provide wider help.
> >
> > I would be interested to hear any other views on this,
> >
> > Thanks
> >
> > Kevin


--
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Twitter: @RabelaisA11y
---
Open source for accessibility: results from the
AEGIS project www.aegis-project.eu
---
Please don't invite me to Facebook, Quechup or
other "social networks". You may have agreed to
their "privacy policy", but I haven't.

From: Aaron Leventhal
Date: Fri, Nov 04 2011 1:00PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Hi Christophe, I agree that every effort should be made to support older
versions of JAWS and IE, and screen readers w/o ARIA support (like
Windoew-Eyes). However, in dynamic content it's not always feasible. In
many cases, depending on the audience and type of content, it simply makes
sense to use ARIA.

To make things better for users of JAWS 7 or IE7, etc., I advocate a few
things:
- Use "safe" ARIA techniques as a progressive enhancement when feasible
- When "full" ARIA support is necessary, inform users with older technology
of the need to upgrade and what their options are -- via the fancy
automatic approach if we can get that to work well.

As far as WCAG 2 compliance in that case, a strict reading of accessibility
supported indicates we just need a free alternative -- such as Firefox +
NVDA. Unfortunately as much as we'd all like to, we can't support five year
old screen reading solutions in modern web content. We need to start
educating users of the need to refresh their technology.

Aaron

On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi Aaron,
>
> At 16:54 4-11-2011, Aaron Leventhal wrote:
>
>> (...)
>>
>>
>> Target audience:
>> 1. If targeting the broad public (e.g. a government website), it seems
>> necessary to stay on the safe side.
>> 2. If targeting advanced technology users (e.g. a high tech company), it
>> seems reasonable to use ARIA a lot more, and to require a more advanced
>> browser - screen reader combo for content outside of the basics
>> (documentation, support, etc.)
>>
>> Safe -- content for the broader public, or is primarily static HTML:
>> • IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal (version?),
>> System Access (version?), etc.
>> • Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+
>> • Safari 4+ with VoiceOver on Snow Leopard or later
>> • Mobile Safari and VoiceOver on iOS 4 or later
>>
>
> This list reminds me of a similar list I wrote last year (in deliverable
> D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>
> * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3 (older
> versions of Internet Explorer and JAWS have no support for WAI-ARIA),
> * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox 2
> also supported MSAA and early drafts of WAI-ARIA),
> * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
> * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
> * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack 3,
> * Safari 3 on Mac OS X 10.5 with VoiceOver,
> * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
> * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS ("Hardy
> Heron").
>
> This list was intended for creating accessibility support documentation
> ("accessibility support" as defined by WCAG 2.0), hence JAWS 9 instead of
> JAWS 7. (JAWS 7 is still in use, even in countries with refund schemes for
> assistive technologies, e.g. Belgium.)
>
> Best regards,
>
> Christophe
>
>
> Full -- content for a high tech audience or must be dynamic by its nature:
>> • IE8+ with JAWS 10+ (unfortunately there is no live region support in
>> NVDA+IE)
>> • Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+
>> • Safari 5+ with VoiceOver on Lion or later
>> • Mobile browsers: to be determined
>>
>> (...)
>>
>> Thoughts?
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> > Hi All,
>> >
>> > I have a client who is doing some excellent work on creating an
>> inclusive
>> > and engaging website. In order to do so they are drawing on the features
>> > provided in WAI-ARIA. This leads to some difficulties regarding browser
>> and
>> > screen reader compatibility and we discussed how to address this. My
>> > personal opinion is to use part of the accessibility statement to
>> highlight
>> > the efforts but point out the need for users to upgrade but I was
>> curious
>> > to understand how people view this?
>> >
>> > My opinion is based on the idea that ARIA provides the opportunity to
>> help
>> > users of assistive technologies but in order to do that there is a need
>> to
>> > use a modern browser. User may not know this and by providing
>> information
>> > around this there is an opportunity to provide wider help.
>> >
>> > I would be interested to hear any other views on this,
>> >
>> > Thanks
>> >
>> > Kevin
>>
>
>
> --
> Christophe Strobbe
> K.U.Leuven - Dept. of Electrical Engineering - SCD
> Research Group on Document Architectures
> Kasteelpark Arenberg 10 bus 2442
> B-3001 Leuven-Heverlee
> BELGIUM
> tel: +32 16 32 85 51
> http://www.docarch.be/
> Twitter: @RabelaisA11y
> ---
> Open source for accessibility: results from the AEGIS project
> www.aegis-project.eu
> ---
> Please don't invite me to Facebook, Quechup or other "social networks".
> You may have agreed to their "privacy policy", but I haven't.
>
>
>

From: Randy Pope
Date: Fri, Nov 04 2011 2:30PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

HI Aaron,

I'm in agreement with your thoughts. For many people with disabilities,
updating or updating their assistive equipment and software pose a
financial hardship. But again,,,it's very difficult to please everyone.

With Warm Regards,
Randy Pope

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron Leventhal
Sent: Friday, November 04, 2011 3:02 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Browser version advice in accessibility statement

Hi Christophe, I agree that every effort should be made to support older
versions of JAWS and IE, and screen readers w/o ARIA support (like
Windoew-Eyes). However, in dynamic content it's not always feasible. In many
cases, depending on the audience and type of content, it simply makes sense
to use ARIA.

To make things better for users of JAWS 7 or IE7, etc., I advocate a few
things:
- Use "safe" ARIA techniques as a progressive enhancement when feasible
- When "full" ARIA support is necessary, inform users with older technology
of the need to upgrade and what their options are -- via the fancy automatic
approach if we can get that to work well.

As far as WCAG 2 compliance in that case, a strict reading of accessibility
supported indicates we just need a free alternative -- such as Firefox +
NVDA. Unfortunately as much as we'd all like to, we can't support five year
old screen reading solutions in modern web content. We need to start
educating users of the need to refresh their technology.

Aaron

On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi Aaron,
>
> At 16:54 4-11-2011, Aaron Leventhal wrote:
>
>> (...)
>>
>>
>> Target audience:
>> 1. If targeting the broad public (e.g. a government website), it
>> seems necessary to stay on the safe side.
>> 2. If targeting advanced technology users (e.g. a high tech company),
>> it seems reasonable to use ARIA a lot more, and to require a more
>> advanced browser - screen reader combo for content outside of the
>> basics (documentation, support, etc.)
>>
>> Safe -- content for the broader public, or is primarily static HTML:
>> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>> (version?), System Access (version?), etc.
>> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ . Safari
>> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>> VoiceOver on iOS 4 or later
>>
>
> This list reminds me of a similar list I wrote last year (in
> deliverable
> D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>
> * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3
> (older versions of Internet Explorer and JAWS have no support for
> WAI-ARIA),
> * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox 2
> also supported MSAA and early drafts of WAI-ARIA),
> * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
> * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
> * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack
> 3,
> * Safari 3 on Mac OS X 10.5 with VoiceOver,
> * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
> * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
> ("Hardy Heron").
>
> This list was intended for creating accessibility support
> documentation ("accessibility support" as defined by WCAG 2.0), hence
> JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in countries
> with refund schemes for assistive technologies, e.g. Belgium.)
>
> Best regards,
>
> Christophe
>
>
> Full -- content for a high tech audience or must be dynamic by its
nature:
>> . IE8+ with JAWS 10+ (unfortunately there is no live region support
>> in
>> NVDA+IE)
>> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>> VoiceOver on Lion or later . Mobile browsers: to be determined
>>
>> (...)
>>
>> Thoughts?
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> > Hi All,
>> >
>> > I have a client who is doing some excellent work on creating an
>> inclusive
>> > and engaging website. In order to do so they are drawing on the
>> > features provided in WAI-ARIA. This leads to some difficulties
>> > regarding browser
>> and
>> > screen reader compatibility and we discussed how to address this.
>> > My personal opinion is to use part of the accessibility statement
>> > to
>> highlight
>> > the efforts but point out the need for users to upgrade but I was
>> curious
>> > to understand how people view this?
>> >
>> > My opinion is based on the idea that ARIA provides the opportunity
>> > to
>> help
>> > users of assistive technologies but in order to do that there is a
>> > need
>> to
>> > use a modern browser. User may not know this and by providing
>> information
>> > around this there is an opportunity to provide wider help.
>> >
>> > I would be interested to hear any other views on this,
>> >
>> > Thanks
>> >
>> > Kevin
>>
>
>
> --
> Christophe Strobbe
> K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on
> Document Architectures Kasteelpark Arenberg 10 bus 2442
> B-3001 Leuven-Heverlee
> BELGIUM
> tel: +32 16 32 85 51
> http://www.docarch.be/
> Twitter: @RabelaisA11y
> ---
> Open source for accessibility: results from the AEGIS project
> www.aegis-project.eu
> ---
> Please don't invite me to Facebook, Quechup or other "social networks".
> You may have agreed to their "privacy policy", but I haven't.
>
>
>

From: Aaron Leventhal
Date: Fri, Nov 04 2011 2:42PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

I agree Randy, although at least we can start to proceed conservatively for
most content, using the fallbacks. And with the friendly message in place,
we can start to be aggressive with ARIA for the high tech crowd. We'll find
out what's appropriate for the middle ground as we go -- and it will change
(although not as fast as we'd like!)

Aaron

On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:

> HI Aaron,
>
> I'm in agreement with your thoughts. For many people with disabilities,
> updating or updating their assistive equipment and software pose a
> financial hardship. But again,,,it's very difficult to please everyone.
>
> With Warm Regards,
> Randy Pope
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron Leventhal
> Sent: Friday, November 04, 2011 3:02 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>
> Hi Christophe, I agree that every effort should be made to support older
> versions of JAWS and IE, and screen readers w/o ARIA support (like
> Windoew-Eyes). However, in dynamic content it's not always feasible. In
> many
> cases, depending on the audience and type of content, it simply makes sense
> to use ARIA.
>
> To make things better for users of JAWS 7 or IE7, etc., I advocate a few
> things:
> - Use "safe" ARIA techniques as a progressive enhancement when feasible
> - When "full" ARIA support is necessary, inform users with older technology
> of the need to upgrade and what their options are -- via the fancy
> automatic
> approach if we can get that to work well.
>
> As far as WCAG 2 compliance in that case, a strict reading of accessibility
> supported indicates we just need a free alternative -- such as Firefox +
> NVDA. Unfortunately as much as we'd all like to, we can't support five year
> old screen reading solutions in modern web content. We need to start
> educating users of the need to refresh their technology.
>
> Aaron
>
> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi Aaron,
> >
> > At 16:54 4-11-2011, Aaron Leventhal wrote:
> >
> >> (...)
> >>
> >>
> >> Target audience:
> >> 1. If targeting the broad public (e.g. a government website), it
> >> seems necessary to stay on the safe side.
> >> 2. If targeting advanced technology users (e.g. a high tech company),
> >> it seems reasonable to use ARIA a lot more, and to require a more
> >> advanced browser - screen reader combo for content outside of the
> >> basics (documentation, support, etc.)
> >>
> >> Safe -- content for the broader public, or is primarily static HTML:
> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
> >> (version?), System Access (version?), etc.
> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ . Safari
> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
> >> VoiceOver on iOS 4 or later
> >>
> >
> > This list reminds me of a similar list I wrote last year (in
> > deliverable
> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
> >
> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3
> > (older versions of Internet Explorer and JAWS have no support for
> > WAI-ARIA),
> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox 2
> > also supported MSAA and early drafts of WAI-ARIA),
> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack
> > 3,
> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
> > ("Hardy Heron").
> >
> > This list was intended for creating accessibility support
> > documentation ("accessibility support" as defined by WCAG 2.0), hence
> > JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in countries
> > with refund schemes for assistive technologies, e.g. Belgium.)
> >
> > Best regards,
> >
> > Christophe
> >
> >
> > Full -- content for a high tech audience or must be dynamic by its
> nature:
> >> . IE8+ with JAWS 10+ (unfortunately there is no live region support
> >> in
> >> NVDA+IE)
> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
> >> VoiceOver on Lion or later . Mobile browsers: to be determined
> >>
> >> (...)
> >>
> >> Thoughts?
> >>
> >> Aaron
> >>
> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >> > Hi All,
> >> >
> >> > I have a client who is doing some excellent work on creating an
> >> inclusive
> >> > and engaging website. In order to do so they are drawing on the
> >> > features provided in WAI-ARIA. This leads to some difficulties
> >> > regarding browser
> >> and
> >> > screen reader compatibility and we discussed how to address this.
> >> > My personal opinion is to use part of the accessibility statement
> >> > to
> >> highlight
> >> > the efforts but point out the need for users to upgrade but I was
> >> curious
> >> > to understand how people view this?
> >> >
> >> > My opinion is based on the idea that ARIA provides the opportunity
> >> > to
> >> help
> >> > users of assistive technologies but in order to do that there is a
> >> > need
> >> to
> >> > use a modern browser. User may not know this and by providing
> >> information
> >> > around this there is an opportunity to provide wider help.
> >> >
> >> > I would be interested to hear any other views on this,
> >> >
> >> > Thanks
> >> >
> >> > Kevin
> >>
> >
> >
> > --
> > Christophe Strobbe
> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on
> > Document Architectures Kasteelpark Arenberg 10 bus 2442
> > B-3001 Leuven-Heverlee
> > BELGIUM
> > tel: +32 16 32 85 51
> > http://www.docarch.be/
> > Twitter: @RabelaisA11y
> > ---
> > Open source for accessibility: results from the AEGIS project
> > www.aegis-project.eu
> > ---
> > Please don't invite me to Facebook, Quechup or other "social networks".
> > You may have agreed to their "privacy policy", but I haven't.
> >
> >
> >

From: Birkir R. Gunnarsson
Date: Sat, Nov 05 2011 9:36PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Two minor thoughts on this (apart from me being outright impressed
with the wealth of useful info on here, and discovering Henni's blog,
which is excellent).
1. It seems to me that it might make sense for someone like webAIM, or
a relatively objective and well respected third party to create and
maintain a compatibility page for browsers and assistive technologies
with regards to accessibility support (all the info is basically here
in various blogs and in these discussions), and it might act as a
disclaimer or source that people could link to in their own
accessibility disclaimers. This would enable a somewhat generic
accessibility statement and ensure a central page where changes can be
made consistently as Assistive Technology is upgraded, or better info
is available. Of course there could be issues, political or otherwise,
why WebAIM per se, would not want to do this, but it seems to me like
it would be a nice idea if some organization maintained a page with
this info, allowing those who want to put browser and A.T. version
support information on their websites (which I think is a great idea).
If it is not centralized these statements will differ, be fragmented
(not all people are aware of all screen readers, I see that
Hal/Supernova support is absent in most lists for instance, something
I could definitely help clear up), and out of synch, as it is not
clear when each of these statements was updated and, hence, valid with
regards to A.T. support for accessibility.


2. Perhaps I am somewhat alone in this opinion, I have certainly seen
divided opinions on this. I think that when there is a free and open
source screen reader out there, with navigation very similar to the
Windows screen readers, that we can reasonably expect users who have
older screen reading solutions, but require a more updated
accessibility support, to go out there, download NVDA and learn how to
use it. This is exaggerating the point certainly, especially when ARIA
definitely is not as consistent in its implementation (for instance
with keyboard support for flyout menus) as we'd wish it to be perhaps.
There is a lot of users, who have recently lost their sight or are
older and less computer savvy users, who simply can't deal with the
complexities of ARIA, and are unlikely to frequent pages where ARIA is
used aggressively. But, I think the availibility of quality ARIA
support in a free and open source screen reader is a huge benefit, and
can allow us to be a little more aggressive as developers utilizing
these recent technologies to enable accessibility where other
traditional means of A T support are not available. In short, whereas
we need to preserve a balance, I wuld hate to avoid using ARIA because
users of Jaws 7 can't utilize it. At this point, these users have the
option to upgrade,and they need to.

In my screen reader testing I have given a green light to features
that NVDA 2011.2 supports, and also try to test two major versions
back for the traditional major screen readers (now I test Jaws 12 and
13, with Jaws 11 testing being phased out).
Perhaps this is overly aggressive, but there is definitely some
responsibility for users to be up-to-date with their assistive
technology, as long as it does not impose undue financial hardship on
them.


Cheers
-B

On 11/4/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
> I agree Randy, although at least we can start to proceed conservatively for
> most content, using the fallbacks. And with the friendly message in place,
> we can start to be aggressive with ARIA for the high tech crowd. We'll find
> out what's appropriate for the middle ground as we go -- and it will change
> (although not as fast as we'd like!)
>
> Aaron
>
> On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:
>
>> HI Aaron,
>>
>> I'm in agreement with your thoughts. For many people with disabilities,
>> updating or updating their assistive equipment and software pose a
>> financial hardship. But again,,,it's very difficult to please everyone.
>>
>> With Warm Regards,
>> Randy Pope
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron Leventhal
>> Sent: Friday, November 04, 2011 3:02 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>>
>> Hi Christophe, I agree that every effort should be made to support older
>> versions of JAWS and IE, and screen readers w/o ARIA support (like
>> Windoew-Eyes). However, in dynamic content it's not always feasible. In
>> many
>> cases, depending on the audience and type of content, it simply makes
>> sense
>> to use ARIA.
>>
>> To make things better for users of JAWS 7 or IE7, etc., I advocate a few
>> things:
>> - Use "safe" ARIA techniques as a progressive enhancement when feasible
>> - When "full" ARIA support is necessary, inform users with older
>> technology
>> of the need to upgrade and what their options are -- via the fancy
>> automatic
>> approach if we can get that to work well.
>>
>> As far as WCAG 2 compliance in that case, a strict reading of
>> accessibility
>> supported indicates we just need a free alternative -- such as Firefox +
>> NVDA. Unfortunately as much as we'd all like to, we can't support five
>> year
>> old screen reading solutions in modern web content. We need to start
>> educating users of the need to refresh their technology.
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > Hi Aaron,
>> >
>> > At 16:54 4-11-2011, Aaron Leventhal wrote:
>> >
>> >> (...)
>> >>
>> >>
>> >> Target audience:
>> >> 1. If targeting the broad public (e.g. a government website), it
>> >> seems necessary to stay on the safe side.
>> >> 2. If targeting advanced technology users (e.g. a high tech company),
>> >> it seems reasonable to use ARIA a lot more, and to require a more
>> >> advanced browser - screen reader combo for content outside of the
>> >> basics (documentation, support, etc.)
>> >>
>> >> Safe -- content for the broader public, or is primarily static HTML:
>> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>> >> (version?), System Access (version?), etc.
>> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ . Safari
>> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>> >> VoiceOver on iOS 4 or later
>> >>
>> >
>> > This list reminds me of a similar list I wrote last year (in
>> > deliverable
>> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>> >
>> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3
>> > (older versions of Internet Explorer and JAWS have no support for
>> > WAI-ARIA),
>> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox 2
>> > also supported MSAA and early drafts of WAI-ARIA),
>> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
>> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
>> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack
>> > 3,
>> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
>> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
>> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
>> > ("Hardy Heron").
>> >
>> > This list was intended for creating accessibility support
>> > documentation ("accessibility support" as defined by WCAG 2.0), hence
>> > JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in countries
>> > with refund schemes for assistive technologies, e.g. Belgium.)
>> >
>> > Best regards,
>> >
>> > Christophe
>> >
>> >
>> > Full -- content for a high tech audience or must be dynamic by its
>> nature:
>> >> . IE8+ with JAWS 10+ (unfortunately there is no live region support
>> >> in
>> >> NVDA+IE)
>> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>> >> VoiceOver on Lion or later . Mobile browsers: to be determined
>> >>
>> >> (...)
>> >>
>> >> Thoughts?
>> >>
>> >> Aaron
>> >>
>> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >
>> >> wrote:
>> >>
>> >> > Hi All,
>> >> >
>> >> > I have a client who is doing some excellent work on creating an
>> >> inclusive
>> >> > and engaging website. In order to do so they are drawing on the
>> >> > features provided in WAI-ARIA. This leads to some difficulties
>> >> > regarding browser
>> >> and
>> >> > screen reader compatibility and we discussed how to address this.
>> >> > My personal opinion is to use part of the accessibility statement
>> >> > to
>> >> highlight
>> >> > the efforts but point out the need for users to upgrade but I was
>> >> curious
>> >> > to understand how people view this?
>> >> >
>> >> > My opinion is based on the idea that ARIA provides the opportunity
>> >> > to
>> >> help
>> >> > users of assistive technologies but in order to do that there is a
>> >> > need
>> >> to
>> >> > use a modern browser. User may not know this and by providing
>> >> information
>> >> > around this there is an opportunity to provide wider help.
>> >> >
>> >> > I would be interested to hear any other views on this,
>> >> >
>> >> > Thanks
>> >> >
>> >> > Kevin
>> >>
>> >
>> >
>> > --
>> > Christophe Strobbe
>> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on
>> > Document Architectures Kasteelpark Arenberg 10 bus 2442
>> > B-3001 Leuven-Heverlee
>> > BELGIUM
>> > tel: +32 16 32 85 51
>> > http://www.docarch.be/
>> > Twitter: @RabelaisA11y
>> > ---
>> > Open source for accessibility: results from the AEGIS project
>> > www.aegis-project.eu
>> > ---
>> > Please don't invite me to Facebook, Quechup or other "social networks".
>> > You may have agreed to their "privacy policy", but I haven't.
>> >
>> >
>> >

From: Aaron Leventhal
Date: Sun, Nov 06 2011 9:30AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

We definitely all need the compatibility list!

Also, as far as inconsistent implementations of ARIA and how it affects older users ... If ARIA is implemented well the user should not have any trouble, because on almost l cases the accessibility behavior should be what they are already accustomed to. The inconsistency really points to the need for the ARIA developer portal where proper ARIA techniques are discussed and documented. We need aria testing tools, and we need a community that is more involved. We need to Identify and document the techniques and issues or inconsistencies in key implementations, and get after developers to fix their bugs.

I believe this is all possible.

Aaron
-----Original Message-----
From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
Sender: = EMAIL ADDRESS REMOVED =
Date: Sun, 6 Nov 2011 03:36:27
To: WebAIM Discussion List< = EMAIL ADDRESS REMOVED = >
Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Browser version advice in accessibility statement

Two minor thoughts on this (apart from me being outright impressed
with the wealth of useful info on here, and discovering Henni's blog,
which is excellent).
1. It seems to me that it might make sense for someone like webAIM, or
a relatively objective and well respected third party to create and
maintain a compatibility page for browsers and assistive technologies
with regards to accessibility support (all the info is basically here
in various blogs and in these discussions), and it might act as a
disclaimer or source that people could link to in their own
accessibility disclaimers. This would enable a somewhat generic
accessibility statement and ensure a central page where changes can be
made consistently as Assistive Technology is upgraded, or better info
is available. Of course there could be issues, political or otherwise,
why WebAIM per se, would not want to do this, but it seems to me like
it would be a nice idea if some organization maintained a page with
this info, allowing those who want to put browser and A.T. version
support information on their websites (which I think is a great idea).
If it is not centralized these statements will differ, be fragmented
(not all people are aware of all screen readers, I see that
Hal/Supernova support is absent in most lists for instance, something
I could definitely help clear up), and out of synch, as it is not
clear when each of these statements was updated and, hence, valid with
regards to A.T. support for accessibility.


2. Perhaps I am somewhat alone in this opinion, I have certainly seen
divided opinions on this. I think that when there is a free and open
source screen reader out there, with navigation very similar to the
Windows screen readers, that we can reasonably expect users who have
older screen reading solutions, but require a more updated
accessibility support, to go out there, download NVDA and learn how to
use it. This is exaggerating the point certainly, especially when ARIA
definitely is not as consistent in its implementation (for instance
with keyboard support for flyout menus) as we'd wish it to be perhaps.
There is a lot of users, who have recently lost their sight or are
older and less computer savvy users, who simply can't deal with the
complexities of ARIA, and are unlikely to frequent pages where ARIA is
used aggressively. But, I think the availibility of quality ARIA
support in a free and open source screen reader is a huge benefit, and
can allow us to be a little more aggressive as developers utilizing
these recent technologies to enable accessibility where other
traditional means of A T support are not available. In short, whereas
we need to preserve a balance, I wuld hate to avoid using ARIA because
users of Jaws 7 can't utilize it. At this point, these users have the
option to upgrade,and they need to.

In my screen reader testing I have given a green light to features
that NVDA 2011.2 supports, and also try to test two major versions
back for the traditional major screen readers (now I test Jaws 12 and
13, with Jaws 11 testing being phased out).
Perhaps this is overly aggressive, but there is definitely some
responsibility for users to be up-to-date with their assistive
technology, as long as it does not impose undue financial hardship on
them.


Cheers
-B

On 11/4/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
> I agree Randy, although at least we can start to proceed conservatively for
> most content, using the fallbacks. And with the friendly message in place,
> we can start to be aggressive with ARIA for the high tech crowd. We'll find
> out what's appropriate for the middle ground as we go -- and it will change
> (although not as fast as we'd like!)
>
> Aaron
>
> On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:
>
>> HI Aaron,
>>
>> I'm in agreement with your thoughts. For many people with disabilities,
>> updating or updating their assistive equipment and software pose a
>> financial hardship. But again,,,it's very difficult to please everyone.
>>
>> With Warm Regards,
>> Randy Pope
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron Leventhal
>> Sent: Friday, November 04, 2011 3:02 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>>
>> Hi Christophe, I agree that every effort should be made to support older
>> versions of JAWS and IE, and screen readers w/o ARIA support (like
>> Windoew-Eyes). However, in dynamic content it's not always feasible. In
>> many
>> cases, depending on the audience and type of content, it simply makes
>> sense
>> to use ARIA.
>>
>> To make things better for users of JAWS 7 or IE7, etc., I advocate a few
>> things:
>> - Use "safe" ARIA techniques as a progressive enhancement when feasible
>> - When "full" ARIA support is necessary, inform users with older
>> technology
>> of the need to upgrade and what their options are -- via the fancy
>> automatic
>> approach if we can get that to work well.
>>
>> As far as WCAG 2 compliance in that case, a strict reading of
>> accessibility
>> supported indicates we just need a free alternative -- such as Firefox +
>> NVDA. Unfortunately as much as we'd all like to, we can't support five
>> year
>> old screen reading solutions in modern web content. We need to start
>> educating users of the need to refresh their technology.
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > Hi Aaron,
>> >
>> > At 16:54 4-11-2011, Aaron Leventhal wrote:
>> >
>> >> (...)
>> >>
>> >>
>> >> Target audience:
>> >> 1. If targeting the broad public (e.g. a government website), it
>> >> seems necessary to stay on the safe side.
>> >> 2. If targeting advanced technology users (e.g. a high tech company),
>> >> it seems reasonable to use ARIA a lot more, and to require a more
>> >> advanced browser - screen reader combo for content outside of the
>> >> basics (documentation, support, etc.)
>> >>
>> >> Safe -- content for the broader public, or is primarily static HTML:
>> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>> >> (version?), System Access (version?), etc.
>> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ . Safari
>> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>> >> VoiceOver on iOS 4 or later
>> >>
>> >
>> > This list reminds me of a similar list I wrote last year (in
>> > deliverable
>> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>> >
>> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3
>> > (older versions of Internet Explorer and JAWS have no support for
>> > WAI-ARIA),
>> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox 2
>> > also supported MSAA and early drafts of WAI-ARIA),
>> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
>> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
>> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack
>> > 3,
>> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
>> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
>> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
>> > ("Hardy Heron").
>> >
>> > This list was intended for creating accessibility support
>> > documentation ("accessibility support" as defined by WCAG 2.0), hence
>> > JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in countries
>> > with refund schemes for assistive technologies, e.g. Belgium.)
>> >
>> > Best regards,
>> >
>> > Christophe
>> >
>> >
>> > Full -- content for a high tech audience or must be dynamic by its
>> nature:
>> >> . IE8+ with JAWS 10+ (unfortunately there is no live region support
>> >> in
>> >> NVDA+IE)
>> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>> >> VoiceOver on Lion or later . Mobile browsers: to be determined
>> >>
>> >> (...)
>> >>
>> >> Thoughts?
>> >>
>> >> Aaron
>> >>
>> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >
>> >> wrote:
>> >>
>> >> > Hi All,
>> >> >
>> >> > I have a client who is doing some excellent work on creating an
>> >> inclusive
>> >> > and engaging website. In order to do so they are drawing on the
>> >> > features provided in WAI-ARIA. This leads to some difficulties
>> >> > regarding browser
>> >> and
>> >> > screen reader compatibility and we discussed how to address this.
>> >> > My personal opinion is to use part of the accessibility statement
>> >> > to
>> >> highlight
>> >> > the efforts but point out the need for users to upgrade but I was
>> >> curious
>> >> > to understand how people view this?
>> >> >
>> >> > My opinion is based on the idea that ARIA provides the opportunity
>> >> > to
>> >> help
>> >> > users of assistive technologies but in order to do that there is a
>> >> > need
>> >> to
>> >> > use a modern browser. User may not know this and by providing
>> >> information
>> >> > around this there is an opportunity to provide wider help.
>> >> >
>> >> > I would be interested to hear any other views on this,
>> >> >
>> >> > Thanks
>> >> >
>> >> > Kevin
>> >>
>> >
>> >
>> > --
>> > Christophe Strobbe
>> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on
>> > Document Architectures Kasteelpark Arenberg 10 bus 2442
>> > B-3001 Leuven-Heverlee
>> > BELGIUM
>> > tel: +32 16 32 85 51
>> > http://www.docarch.be/
>> > Twitter: @RabelaisA11y
>> > ---
>> > Open source for accessibility: results from the AEGIS project
>> > www.aegis-project.eu
>> > ---
>> > Please don't invite me to Facebook, Quechup or other "social networks".
>> > You may have agreed to their "privacy policy", but I haven't.
>> >
>> >
>> >

From: Kevin Chao
Date: Sun, Nov 06 2011 3:24PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

There's no excuse or reason at all one should not be running the
latest web browser and assistive technology, such as screen reader.
There's performance, security, accessibility, usability, support, etc.
benefits. Vendors/industry should not be limited due to users refusing
to update.

I think that HTML5 and ARIA should only be applied when needed, such
as rich, interactive, and dynamic sites. If a website is a fairly
static site and standard HTML4 markup will work, there's no need to
add additional complexity by adding in ARIA. However, if in the road
map of a company/site has plans on adding more rich, interactive, and
dynamic components; it's best to build in the HTML5 and ARIA support
during the R&D stage.

When it comes to web browser and assistive technology support, the web
is moving very quickly, and in order for companies/websites to keep
up; the minimum requirement and support must be very strict. It should
be forced to current and previous version, nothing more.

Firefox+NVDA, specifically 10 Nightly and 2011.3 Snapshot has the most
fastest, solid, accurate, and rich support for the web, specifically
HTML5 and ARIA.
NVDA works very well with Chrome 17 Canary and Google is actively
working on fixing a lot of accessibility support in many areas,
including HTML5 and ARIA.

Chrome+ChromeVox on Windows or Mac has very good support for the web
(rich, dynamic, and interactive), but ARIA support is a work in
progress.

Internet Explorer 9/8 does not have proper, robust, and rich
accessibility API's for ARIA and HTML5. Any AT/screen reader who
claims support for it is hacking support in, which results in poor
performance, instability, and buggy/inaccurate results.

iOS 5, VoiceOver, and Safari made a lot of great strides, especially
over iOS 4.3.X in improving HTML5 and ARIA accessibility support.

OS X Lion, Safari, and Voiceover just added ARIA support, it's quite
weak, and has a ways to go still. However, its support for HTML5 and
ARIA is far better than Window-Eyes, who has very weak web support,
and no HTML5 or ARIA.

I'm not sure how well SuperNova and System Access HTML5 and ARIA support is.

Opera web browser should not even been considered at all or mentioned
until it's fully accessible with various assistive technologies.

As a user myself, I don't think it's unreasonable at all to ask the
end-user of a website to upgrade to the latest web browser and AT to
fully utalize, leverage, and benefit from the Web 2.0 features of the
website. This should not be provided in a hidden link, but a visible
link, which when viewed provides the best combination, which on
Windows is Firefox+NVDA. NVDA, which is free and open source has the
best support, which results in the cost factor/excuse being thrown out
the window.

Most of the paid commercial screen readers are ones that I don't use
as their bloated, buggy, slow, and don't have great support for the
web, such as HTML5 and ARIA.

Kevin

On 11/6/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
> We definitely all need the compatibility list!
>
> Also, as far as inconsistent implementations of ARIA and how it affects
> older users ... If ARIA is implemented well the user should not have any
> trouble, because on almost l cases the accessibility behavior should be what
> they are already accustomed to. The inconsistency really points to the need
> for the ARIA developer portal where proper ARIA techniques are discussed and
> documented. We need aria testing tools, and we need a community that is more
> involved. We need to Identify and document the techniques and issues or
> inconsistencies in key implementations, and get after developers to fix
> their bugs.
>
> I believe this is all possible.
>
> Aaron
> -----Original Message-----
> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> Sender: = EMAIL ADDRESS REMOVED =
> Date: Sun, 6 Nov 2011 03:36:27
> To: WebAIM Discussion List< = EMAIL ADDRESS REMOVED = >
> Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>
> Two minor thoughts on this (apart from me being outright impressed
> with the wealth of useful info on here, and discovering Henni's blog,
> which is excellent).
> 1. It seems to me that it might make sense for someone like webAIM, or
> a relatively objective and well respected third party to create and
> maintain a compatibility page for browsers and assistive technologies
> with regards to accessibility support (all the info is basically here
> in various blogs and in these discussions), and it might act as a
> disclaimer or source that people could link to in their own
> accessibility disclaimers. This would enable a somewhat generic
> accessibility statement and ensure a central page where changes can be
> made consistently as Assistive Technology is upgraded, or better info
> is available. Of course there could be issues, political or otherwise,
> why WebAIM per se, would not want to do this, but it seems to me like
> it would be a nice idea if some organization maintained a page with
> this info, allowing those who want to put browser and A.T. version
> support information on their websites (which I think is a great idea).
> If it is not centralized these statements will differ, be fragmented
> (not all people are aware of all screen readers, I see that
> Hal/Supernova support is absent in most lists for instance, something
> I could definitely help clear up), and out of synch, as it is not
> clear when each of these statements was updated and, hence, valid with
> regards to A.T. support for accessibility.
>
>
> 2. Perhaps I am somewhat alone in this opinion, I have certainly seen
> divided opinions on this. I think that when there is a free and open
> source screen reader out there, with navigation very similar to the
> Windows screen readers, that we can reasonably expect users who have
> older screen reading solutions, but require a more updated
> accessibility support, to go out there, download NVDA and learn how to
> use it. This is exaggerating the point certainly, especially when ARIA
> definitely is not as consistent in its implementation (for instance
> with keyboard support for flyout menus) as we'd wish it to be perhaps.
> There is a lot of users, who have recently lost their sight or are
> older and less computer savvy users, who simply can't deal with the
> complexities of ARIA, and are unlikely to frequent pages where ARIA is
> used aggressively. But, I think the availibility of quality ARIA
> support in a free and open source screen reader is a huge benefit, and
> can allow us to be a little more aggressive as developers utilizing
> these recent technologies to enable accessibility where other
> traditional means of A T support are not available. In short, whereas
> we need to preserve a balance, I wuld hate to avoid using ARIA because
> users of Jaws 7 can't utilize it. At this point, these users have the
> option to upgrade,and they need to.
>
> In my screen reader testing I have given a green light to features
> that NVDA 2011.2 supports, and also try to test two major versions
> back for the traditional major screen readers (now I test Jaws 12 and
> 13, with Jaws 11 testing being phased out).
> Perhaps this is overly aggressive, but there is definitely some
> responsibility for users to be up-to-date with their assistive
> technology, as long as it does not impose undue financial hardship on
> them.
>
>
> Cheers
> -B
>
> On 11/4/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>> I agree Randy, although at least we can start to proceed conservatively
>> for
>> most content, using the fallbacks. And with the friendly message in place,
>> we can start to be aggressive with ARIA for the high tech crowd. We'll
>> find
>> out what's appropriate for the middle ground as we go -- and it will
>> change
>> (although not as fast as we'd like!)
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> HI Aaron,
>>>
>>> I'm in agreement with your thoughts. For many people with disabilities,
>>> updating or updating their assistive equipment and software pose a
>>> financial hardship. But again,,,it's very difficult to please everyone.
>>>
>>> With Warm Regards,
>>> Randy Pope
>>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron
>>> Leventhal
>>> Sent: Friday, November 04, 2011 3:02 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>>>
>>> Hi Christophe, I agree that every effort should be made to support older
>>> versions of JAWS and IE, and screen readers w/o ARIA support (like
>>> Windoew-Eyes). However, in dynamic content it's not always feasible. In
>>> many
>>> cases, depending on the audience and type of content, it simply makes
>>> sense
>>> to use ARIA.
>>>
>>> To make things better for users of JAWS 7 or IE7, etc., I advocate a few
>>> things:
>>> - Use "safe" ARIA techniques as a progressive enhancement when feasible
>>> - When "full" ARIA support is necessary, inform users with older
>>> technology
>>> of the need to upgrade and what their options are -- via the fancy
>>> automatic
>>> approach if we can get that to work well.
>>>
>>> As far as WCAG 2 compliance in that case, a strict reading of
>>> accessibility
>>> supported indicates we just need a free alternative -- such as Firefox +
>>> NVDA. Unfortunately as much as we'd all like to, we can't support five
>>> year
>>> old screen reading solutions in modern web content. We need to start
>>> educating users of the need to refresh their technology.
>>>
>>> Aaron
>>>
>>> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> > Hi Aaron,
>>> >
>>> > At 16:54 4-11-2011, Aaron Leventhal wrote:
>>> >
>>> >> (...)
>>> >>
>>> >>
>>> >> Target audience:
>>> >> 1. If targeting the broad public (e.g. a government website), it
>>> >> seems necessary to stay on the safe side.
>>> >> 2. If targeting advanced technology users (e.g. a high tech company),
>>> >> it seems reasonable to use ARIA a lot more, and to require a more
>>> >> advanced browser - screen reader combo for content outside of the
>>> >> basics (documentation, support, etc.)
>>> >>
>>> >> Safe -- content for the broader public, or is primarily static HTML:
>>> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>>> >> (version?), System Access (version?), etc.
>>> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ . Safari
>>> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>>> >> VoiceOver on iOS 4 or later
>>> >>
>>> >
>>> > This list reminds me of a similar list I wrote last year (in
>>> > deliverable
>>> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>>> >
>>> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3
>>> > (older versions of Internet Explorer and JAWS have no support for
>>> > WAI-ARIA),
>>> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox 2
>>> > also supported MSAA and early drafts of WAI-ARIA),
>>> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
>>> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
>>> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack
>>> > 3,
>>> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
>>> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
>>> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
>>> > ("Hardy Heron").
>>> >
>>> > This list was intended for creating accessibility support
>>> > documentation ("accessibility support" as defined by WCAG 2.0), hence
>>> > JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in countries
>>> > with refund schemes for assistive technologies, e.g. Belgium.)
>>> >
>>> > Best regards,
>>> >
>>> > Christophe
>>> >
>>> >
>>> > Full -- content for a high tech audience or must be dynamic by its
>>> nature:
>>> >> . IE8+ with JAWS 10+ (unfortunately there is no live region support
>>> >> in
>>> >> NVDA+IE)
>>> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>>> >> VoiceOver on Lion or later . Mobile browsers: to be determined
>>> >>
>>> >> (...)
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> Aaron
>>> >>
>>> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >
>>> >> wrote:
>>> >>
>>> >> > Hi All,
>>> >> >
>>> >> > I have a client who is doing some excellent work on creating an
>>> >> inclusive
>>> >> > and engaging website. In order to do so they are drawing on the
>>> >> > features provided in WAI-ARIA. This leads to some difficulties
>>> >> > regarding browser
>>> >> and
>>> >> > screen reader compatibility and we discussed how to address this.
>>> >> > My personal opinion is to use part of the accessibility statement
>>> >> > to
>>> >> highlight
>>> >> > the efforts but point out the need for users to upgrade but I was
>>> >> curious
>>> >> > to understand how people view this?
>>> >> >
>>> >> > My opinion is based on the idea that ARIA provides the opportunity
>>> >> > to
>>> >> help
>>> >> > users of assistive technologies but in order to do that there is a
>>> >> > need
>>> >> to
>>> >> > use a modern browser. User may not know this and by providing
>>> >> information
>>> >> > around this there is an opportunity to provide wider help.
>>> >> >
>>> >> > I would be interested to hear any other views on this,
>>> >> >
>>> >> > Thanks
>>> >> >
>>> >> > Kevin
>>> >>
>>> >
>>> >
>>> > --
>>> > Christophe Strobbe
>>> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on
>>> > Document Architectures Kasteelpark Arenberg 10 bus 2442
>>> > B-3001 Leuven-Heverlee
>>> > BELGIUM
>>> > tel: +32 16 32 85 51
>>> > http://www.docarch.be/
>>> > Twitter: @RabelaisA11y
>>> > ---
>>> > Open source for accessibility: results from the AEGIS project
>>> > www.aegis-project.eu
>>> > ---
>>> > Please don't invite me to Facebook, Quechup or other "social networks".
>>> > You may have agreed to their "privacy policy", but I haven't.
>>> >
>>> >
>>> >

From: Patrick H. Lauke
Date: Sun, Nov 06 2011 3:33PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

On 06/11/2011 22:23, Kevin Chao wrote:
> There's no excuse or reason at all one should not be running the
> latest web browser and assistive technology, such as screen reader.
> There's performance, security, accessibility, usability, support, etc.
> benefits. Vendors/industry should not be limited due to users refusing
> to update.

Sadly, the reality in many companies is that central IT departments
often prevent updates for various reasons...sometimes because the
enterprise intranet systems were designed to only work in IE6 (my
previous employer, a university, had this issue, with our internal
accounting and personnel systems refusing to even work in IE7), other
times because certain browsers don't play well with distributed profiles
(I seem to remember older versions of Firefox had this issue) or because
they simply don't want the strain on the network when every day a new
fast-release-cycle version is being downloaded across thousands of
installs around the organisation.

However, the employers should provide modern versions that play well
with AT under their duty (where applicable...section 508, DDA, etc) to
make reasonable adjustments for their employees.

But yes, just wanted to point out that users aren't always fully in control.

P
--
Patrick H. Lauke

From: Birkir R. Gunnarsson
Date: Sun, Nov 06 2011 3:45PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Kevin

Agreed for the most part, in fact nearly completely.
Cool to know that Chrome is coming around when it comes to accessibility.
I've been waiting to try it out because I knew there were significant
issues in the past, but it seems now the time has come to try it out.
I am a little more conservative when it comes to A.T. and NVDA specifically.
There are two reasons for this:
a. Non-technical users (and let's face it, they are probably a
majority of users). I did not realize how much you need to hold their
hand until I started working part time for a resource center, in
charge of A.T. and training. There is a lot of people out there who
will not download and install browsers, updates and A.T. by
themselves. They have a fixed set up taylorred to what they want to do
with computers, and specific training and instructions on how to get
those things done. We have to keep them in mind to some degree, even
as the web moves forward. We can significantly simplify their learning
curve by doingmore work on standardizing ARIA implimentations,
keyboard accessibility etc, by utilizing technical users first, making
it easier for non-technical folks to make the switch.


b. NVDA braille support is sadly still lacking significantly, which is
the reasonI still stick with Jaws as my main screen reader. This is
getting past the topic of this list, but I believe the OpenBraile
project failed, and there won't be a universal API access to
supporting braille displays in the near future on the Windows
platform, which is a crying shame. Regardless of that, NVDA needs to
do more when it comes to braile support. There is progress, but it's
not sufficient. Many users in Europe, who are fortunate enough to get
significant budgets towards purchasing A.T. hardware, rely heavily on
braille for a lot of computer activities, for instance the mouse
simulation keys whih NVDA does not support, at least not on the
displays I have tested (Focus, Alva Satellite, Seika and Baum). I hope
this can be fixed.

Cheers
-B

On 11/6/11, Kevin Chao < = EMAIL ADDRESS REMOVED = > wrote:
> There's no excuse or reason at all one should not be running the
> latest web browser and assistive technology, such as screen reader.
> There's performance, security, accessibility, usability, support, etc.
> benefits. Vendors/industry should not be limited due to users refusing
> to update.
>
> I think that HTML5 and ARIA should only be applied when needed, such
> as rich, interactive, and dynamic sites. If a website is a fairly
> static site and standard HTML4 markup will work, there's no need to
> add additional complexity by adding in ARIA. However, if in the road
> map of a company/site has plans on adding more rich, interactive, and
> dynamic components; it's best to build in the HTML5 and ARIA support
> during the R&D stage.
>
> When it comes to web browser and assistive technology support, the web
> is moving very quickly, and in order for companies/websites to keep
> up; the minimum requirement and support must be very strict. It should
> be forced to current and previous version, nothing more.
>
> Firefox+NVDA, specifically 10 Nightly and 2011.3 Snapshot has the most
> fastest, solid, accurate, and rich support for the web, specifically
> HTML5 and ARIA.
> NVDA works very well with Chrome 17 Canary and Google is actively
> working on fixing a lot of accessibility support in many areas,
> including HTML5 and ARIA.
>
> Chrome+ChromeVox on Windows or Mac has very good support for the web
> (rich, dynamic, and interactive), but ARIA support is a work in
> progress.
>
> Internet Explorer 9/8 does not have proper, robust, and rich
> accessibility API's for ARIA and HTML5. Any AT/screen reader who
> claims support for it is hacking support in, which results in poor
> performance, instability, and buggy/inaccurate results.
>
> iOS 5, VoiceOver, and Safari made a lot of great strides, especially
> over iOS 4.3.X in improving HTML5 and ARIA accessibility support.
>
> OS X Lion, Safari, and Voiceover just added ARIA support, it's quite
> weak, and has a ways to go still. However, its support for HTML5 and
> ARIA is far better than Window-Eyes, who has very weak web support,
> and no HTML5 or ARIA.
>
> I'm not sure how well SuperNova and System Access HTML5 and ARIA support is.
>
> Opera web browser should not even been considered at all or mentioned
> until it's fully accessible with various assistive technologies.
>
> As a user myself, I don't think it's unreasonable at all to ask the
> end-user of a website to upgrade to the latest web browser and AT to
> fully utalize, leverage, and benefit from the Web 2.0 features of the
> website. This should not be provided in a hidden link, but a visible
> link, which when viewed provides the best combination, which on
> Windows is Firefox+NVDA. NVDA, which is free and open source has the
> best support, which results in the cost factor/excuse being thrown out
> the window.
>
> Most of the paid commercial screen readers are ones that I don't use
> as their bloated, buggy, slow, and don't have great support for the
> web, such as HTML5 and ARIA.
>
> Kevin
>
> On 11/6/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>> We definitely all need the compatibility list!
>>
>> Also, as far as inconsistent implementations of ARIA and how it affects
>> older users ... If ARIA is implemented well the user should not have any
>> trouble, because on almost l cases the accessibility behavior should be
>> what
>> they are already accustomed to. The inconsistency really points to the
>> need
>> for the ARIA developer portal where proper ARIA techniques are discussed
>> and
>> documented. We need aria testing tools, and we need a community that is
>> more
>> involved. We need to Identify and document the techniques and issues or
>> inconsistencies in key implementations, and get after developers to fix
>> their bugs.
>>
>> I believe this is all possible.
>>
>> Aaron
>> -----Original Message-----
>> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
>> Sender: = EMAIL ADDRESS REMOVED =
>> Date: Sun, 6 Nov 2011 03:36:27
>> To: WebAIM Discussion List< = EMAIL ADDRESS REMOVED = >
>> Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>>
>> Two minor thoughts on this (apart from me being outright impressed
>> with the wealth of useful info on here, and discovering Henni's blog,
>> which is excellent).
>> 1. It seems to me that it might make sense for someone like webAIM, or
>> a relatively objective and well respected third party to create and
>> maintain a compatibility page for browsers and assistive technologies
>> with regards to accessibility support (all the info is basically here
>> in various blogs and in these discussions), and it might act as a
>> disclaimer or source that people could link to in their own
>> accessibility disclaimers. This would enable a somewhat generic
>> accessibility statement and ensure a central page where changes can be
>> made consistently as Assistive Technology is upgraded, or better info
>> is available. Of course there could be issues, political or otherwise,
>> why WebAIM per se, would not want to do this, but it seems to me like
>> it would be a nice idea if some organization maintained a page with
>> this info, allowing those who want to put browser and A.T. version
>> support information on their websites (which I think is a great idea).
>> If it is not centralized these statements will differ, be fragmented
>> (not all people are aware of all screen readers, I see that
>> Hal/Supernova support is absent in most lists for instance, something
>> I could definitely help clear up), and out of synch, as it is not
>> clear when each of these statements was updated and, hence, valid with
>> regards to A.T. support for accessibility.
>>
>>
>> 2. Perhaps I am somewhat alone in this opinion, I have certainly seen
>> divided opinions on this. I think that when there is a free and open
>> source screen reader out there, with navigation very similar to the
>> Windows screen readers, that we can reasonably expect users who have
>> older screen reading solutions, but require a more updated
>> accessibility support, to go out there, download NVDA and learn how to
>> use it. This is exaggerating the point certainly, especially when ARIA
>> definitely is not as consistent in its implementation (for instance
>> with keyboard support for flyout menus) as we'd wish it to be perhaps.
>> There is a lot of users, who have recently lost their sight or are
>> older and less computer savvy users, who simply can't deal with the
>> complexities of ARIA, and are unlikely to frequent pages where ARIA is
>> used aggressively. But, I think the availibility of quality ARIA
>> support in a free and open source screen reader is a huge benefit, and
>> can allow us to be a little more aggressive as developers utilizing
>> these recent technologies to enable accessibility where other
>> traditional means of A T support are not available. In short, whereas
>> we need to preserve a balance, I wuld hate to avoid using ARIA because
>> users of Jaws 7 can't utilize it. At this point, these users have the
>> option to upgrade,and they need to.
>>
>> In my screen reader testing I have given a green light to features
>> that NVDA 2011.2 supports, and also try to test two major versions
>> back for the traditional major screen readers (now I test Jaws 12 and
>> 13, with Jaws 11 testing being phased out).
>> Perhaps this is overly aggressive, but there is definitely some
>> responsibility for users to be up-to-date with their assistive
>> technology, as long as it does not impose undue financial hardship on
>> them.
>>
>>
>> Cheers
>> -B
>>
>> On 11/4/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>>> I agree Randy, although at least we can start to proceed conservatively
>>> for
>>> most content, using the fallbacks. And with the friendly message in
>>> place,
>>> we can start to be aggressive with ARIA for the high tech crowd. We'll
>>> find
>>> out what's appropriate for the middle ground as we go -- and it will
>>> change
>>> (although not as fast as we'd like!)
>>>
>>> Aaron
>>>
>>> On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>>> HI Aaron,
>>>>
>>>> I'm in agreement with your thoughts. For many people with disabilities,
>>>> updating or updating their assistive equipment and software pose a
>>>> financial hardship. But again,,,it's very difficult to please
>>>> everyone.
>>>>
>>>> With Warm Regards,
>>>> Randy Pope
>>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron
>>>> Leventhal
>>>> Sent: Friday, November 04, 2011 3:02 PM
>>>> To: WebAIM Discussion List
>>>> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>>>>
>>>> Hi Christophe, I agree that every effort should be made to support older
>>>> versions of JAWS and IE, and screen readers w/o ARIA support (like
>>>> Windoew-Eyes). However, in dynamic content it's not always feasible. In
>>>> many
>>>> cases, depending on the audience and type of content, it simply makes
>>>> sense
>>>> to use ARIA.
>>>>
>>>> To make things better for users of JAWS 7 or IE7, etc., I advocate a few
>>>> things:
>>>> - Use "safe" ARIA techniques as a progressive enhancement when feasible
>>>> - When "full" ARIA support is necessary, inform users with older
>>>> technology
>>>> of the need to upgrade and what their options are -- via the fancy
>>>> automatic
>>>> approach if we can get that to work well.
>>>>
>>>> As far as WCAG 2 compliance in that case, a strict reading of
>>>> accessibility
>>>> supported indicates we just need a free alternative -- such as Firefox +
>>>> NVDA. Unfortunately as much as we'd all like to, we can't support five
>>>> year
>>>> old screen reading solutions in modern web content. We need to start
>>>> educating users of the need to refresh their technology.
>>>>
>>>> Aaron
>>>>
>>>> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
>>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>> > Hi Aaron,
>>>> >
>>>> > At 16:54 4-11-2011, Aaron Leventhal wrote:
>>>> >
>>>> >> (...)
>>>> >>
>>>> >>
>>>> >> Target audience:
>>>> >> 1. If targeting the broad public (e.g. a government website), it
>>>> >> seems necessary to stay on the safe side.
>>>> >> 2. If targeting advanced technology users (e.g. a high tech company),
>>>> >> it seems reasonable to use ARIA a lot more, and to require a more
>>>> >> advanced browser - screen reader combo for content outside of the
>>>> >> basics (documentation, support, etc.)
>>>> >>
>>>> >> Safe -- content for the broader public, or is primarily static HTML:
>>>> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>>>> >> (version?), System Access (version?), etc.
>>>> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ . Safari
>>>> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>>>> >> VoiceOver on iOS 4 or later
>>>> >>
>>>> >
>>>> > This list reminds me of a similar list I wrote last year (in
>>>> > deliverable
>>>> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>>>> >
>>>> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3
>>>> > (older versions of Internet Explorer and JAWS have no support for
>>>> > WAI-ARIA),
>>>> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox 2
>>>> > also supported MSAA and early drafts of WAI-ARIA),
>>>> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
>>>> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack 3,
>>>> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack
>>>> > 3,
>>>> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
>>>> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
>>>> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
>>>> > ("Hardy Heron").
>>>> >
>>>> > This list was intended for creating accessibility support
>>>> > documentation ("accessibility support" as defined by WCAG 2.0), hence
>>>> > JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in countries
>>>> > with refund schemes for assistive technologies, e.g. Belgium.)
>>>> >
>>>> > Best regards,
>>>> >
>>>> > Christophe
>>>> >
>>>> >
>>>> > Full -- content for a high tech audience or must be dynamic by its
>>>> nature:
>>>> >> . IE8+ with JAWS 10+ (unfortunately there is no live region support
>>>> >> in
>>>> >> NVDA+IE)
>>>> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>>>> >> VoiceOver on Lion or later . Mobile browsers: to be determined
>>>> >>
>>>> >> (...)
>>>> >>
>>>> >> Thoughts?
>>>> >>
>>>> >> Aaron
>>>> >>
>>>> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White < = EMAIL ADDRESS REMOVED = >
>>>> >> wrote:
>>>> >>
>>>> >> > Hi All,
>>>> >> >
>>>> >> > I have a client who is doing some excellent work on creating an
>>>> >> inclusive
>>>> >> > and engaging website. In order to do so they are drawing on the
>>>> >> > features provided in WAI-ARIA. This leads to some difficulties
>>>> >> > regarding browser
>>>> >> and
>>>> >> > screen reader compatibility and we discussed how to address this.
>>>> >> > My personal opinion is to use part of the accessibility statement
>>>> >> > to
>>>> >> highlight
>>>> >> > the efforts but point out the need for users to upgrade but I was
>>>> >> curious
>>>> >> > to understand how people view this?
>>>> >> >
>>>> >> > My opinion is based on the idea that ARIA provides the opportunity
>>>> >> > to
>>>> >> help
>>>> >> > users of assistive technologies but in order to do that there is a
>>>> >> > need
>>>> >> to
>>>> >> > use a modern browser. User may not know this and by providing
>>>> >> information
>>>> >> > around this there is an opportunity to provide wider help.
>>>> >> >
>>>> >> > I would be interested to hear any other views on this,
>>>> >> >
>>>> >> > Thanks
>>>> >> >
>>>> >> > Kevin
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > Christophe Strobbe
>>>> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on
>>>> > Document Architectures Kasteelpark Arenberg 10 bus 2442
>>>> > B-3001 Leuven-Heverlee
>>>> > BELGIUM
>>>> > tel: +32 16 32 85 51
>>>> > http://www.docarch.be/
>>>> > Twitter: @RabelaisA11y
>>>> > ---
>>>> > Open source for accessibility: results from the AEGIS project
>>>> > www.aegis-project.eu
>>>> > ---
>>>> > Please don't invite me to Facebook, Quechup or other "social
>>>> > networks".
>>>> > You may have agreed to their "privacy policy", but I haven't.
>>>> >
>>>> >
>>>> >

From: Kevin Chao
Date: Sun, Nov 06 2011 6:09PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Hi Birkir,

I shared your concerned/inability to switch to NVDA and Braille support with:
NVDA screen reader development < = EMAIL ADDRESS REMOVED = >
and I've already received two very thought out, detailed, and
comprehensive responses. One of the many things i absolutely enjoy
about NVAccess/NVDA. The thing i enjoy even more than this is when an
issue ticket is filed with sufficient info, it's addressed very
quickly, and I've seen several issues I've filed closed within 3
hours.

James Teh
Vice President, Developer

First, as always, significant work requires funding. I'm doing what I
can to work on this regardless, but we haven't really found anyone
willing to fund extensive work on braille. If anyone has any ideas,
please let us know.

Please have the user provide more details. Only one example was given,
which is hardly enough to justify "not sufficient".

What is meant by "mouse simulation"? If a cursor routing key is
pressed on an object, it will activate that object. In an editable
text field or document, it moves the cursor to that position.

As Mesar noted, if enhancements or fixes are desired, tickets should
be filed with detailed explanations (after first searching to see
whether one has already been filed, of course).

http://www.nvda-project.org/wiki/Development#IssueTracker

Mesar Hameed
I am pretty sure that the features the person is speaking of work, and
if not its a question of remapping the buttons/wheels to the
functionality that they want.

I have had to do this for some people on the arabic mailing list.

I suspect that they didnt read the remapping gestures section of the
userguide (advanced topics)

If they have a problem with a particular display they are more than
welcome to report it and of course we will all try to help.

The first step is to request for information or to read the manual,
sadly too many people have a lot of presumptions, not understanding that
the system is flexable. Of course there are things that are outstanding,
but we will only improve by people opening tickets and describing the
problem in detailed and explaining how they wish the issue to be solved.

Thanks,

Kevin

On 11/6/11, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> Kevin
>
> Agreed for the most part, in fact nearly completely.
> Cool to know that Chrome is coming around when it comes to accessibility.
> I've been waiting to try it out because I knew there were significant
> issues in the past, but it seems now the time has come to try it out.
> I am a little more conservative when it comes to A.T. and NVDA specifically.
> There are two reasons for this:
> a. Non-technical users (and let's face it, they are probably a
> majority of users). I did not realize how much you need to hold their
> hand until I started working part time for a resource center, in
> charge of A.T. and training. There is a lot of people out there who
> will not download and install browsers, updates and A.T. by
> themselves. They have a fixed set up taylorred to what they want to do
> with computers, and specific training and instructions on how to get
> those things done. We have to keep them in mind to some degree, even
> as the web moves forward. We can significantly simplify their learning
> curve by doingmore work on standardizing ARIA implimentations,
> keyboard accessibility etc, by utilizing technical users first, making
> it easier for non-technical folks to make the switch.
>
>
> b. NVDA braille support is sadly still lacking significantly, which is
> the reasonI still stick with Jaws as my main screen reader. This is
> getting past the topic of this list, but I believe the OpenBraile
> project failed, and there won't be a universal API access to
> supporting braille displays in the near future on the Windows
> platform, which is a crying shame. Regardless of that, NVDA needs to
> do more when it comes to braile support. There is progress, but it's
> not sufficient. Many users in Europe, who are fortunate enough to get
> significant budgets towards purchasing A.T. hardware, rely heavily on
> braille for a lot of computer activities, for instance the mouse
> simulation keys whih NVDA does not support, at least not on the
> displays I have tested (Focus, Alva Satellite, Seika and Baum). I hope
> this can be fixed.
>
> Cheers
> -B
>
> On 11/6/11, Kevin Chao < = EMAIL ADDRESS REMOVED = > wrote:
>> There's no excuse or reason at all one should not be running the
>> latest web browser and assistive technology, such as screen reader.
>> There's performance, security, accessibility, usability, support, etc.
>> benefits. Vendors/industry should not be limited due to users refusing
>> to update.
>>
>> I think that HTML5 and ARIA should only be applied when needed, such
>> as rich, interactive, and dynamic sites. If a website is a fairly
>> static site and standard HTML4 markup will work, there's no need to
>> add additional complexity by adding in ARIA. However, if in the road
>> map of a company/site has plans on adding more rich, interactive, and
>> dynamic components; it's best to build in the HTML5 and ARIA support
>> during the R&D stage.
>>
>> When it comes to web browser and assistive technology support, the web
>> is moving very quickly, and in order for companies/websites to keep
>> up; the minimum requirement and support must be very strict. It should
>> be forced to current and previous version, nothing more.
>>
>> Firefox+NVDA, specifically 10 Nightly and 2011.3 Snapshot has the most
>> fastest, solid, accurate, and rich support for the web, specifically
>> HTML5 and ARIA.
>> NVDA works very well with Chrome 17 Canary and Google is actively
>> working on fixing a lot of accessibility support in many areas,
>> including HTML5 and ARIA.
>>
>> Chrome+ChromeVox on Windows or Mac has very good support for the web
>> (rich, dynamic, and interactive), but ARIA support is a work in
>> progress.
>>
>> Internet Explorer 9/8 does not have proper, robust, and rich
>> accessibility API's for ARIA and HTML5. Any AT/screen reader who
>> claims support for it is hacking support in, which results in poor
>> performance, instability, and buggy/inaccurate results.
>>
>> iOS 5, VoiceOver, and Safari made a lot of great strides, especially
>> over iOS 4.3.X in improving HTML5 and ARIA accessibility support.
>>
>> OS X Lion, Safari, and Voiceover just added ARIA support, it's quite
>> weak, and has a ways to go still. However, its support for HTML5 and
>> ARIA is far better than Window-Eyes, who has very weak web support,
>> and no HTML5 or ARIA.
>>
>> I'm not sure how well SuperNova and System Access HTML5 and ARIA support
>> is.
>>
>> Opera web browser should not even been considered at all or mentioned
>> until it's fully accessible with various assistive technologies.
>>
>> As a user myself, I don't think it's unreasonable at all to ask the
>> end-user of a website to upgrade to the latest web browser and AT to
>> fully utalize, leverage, and benefit from the Web 2.0 features of the
>> website. This should not be provided in a hidden link, but a visible
>> link, which when viewed provides the best combination, which on
>> Windows is Firefox+NVDA. NVDA, which is free and open source has the
>> best support, which results in the cost factor/excuse being thrown out
>> the window.
>>
>> Most of the paid commercial screen readers are ones that I don't use
>> as their bloated, buggy, slow, and don't have great support for the
>> web, such as HTML5 and ARIA.
>>
>> Kevin
>>
>> On 11/6/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>>> We definitely all need the compatibility list!
>>>
>>> Also, as far as inconsistent implementations of ARIA and how it affects
>>> older users ... If ARIA is implemented well the user should not have any
>>> trouble, because on almost l cases the accessibility behavior should be
>>> what
>>> they are already accustomed to. The inconsistency really points to the
>>> need
>>> for the ARIA developer portal where proper ARIA techniques are discussed
>>> and
>>> documented. We need aria testing tools, and we need a community that is
>>> more
>>> involved. We need to Identify and document the techniques and issues or
>>> inconsistencies in key implementations, and get after developers to fix
>>> their bugs.
>>>
>>> I believe this is all possible.
>>>
>>> Aaron
>>> -----Original Message-----
>>> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
>>> Sender: = EMAIL ADDRESS REMOVED =
>>> Date: Sun, 6 Nov 2011 03:36:27
>>> To: WebAIM Discussion List< = EMAIL ADDRESS REMOVED = >
>>> Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>>> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>>>
>>> Two minor thoughts on this (apart from me being outright impressed
>>> with the wealth of useful info on here, and discovering Henni's blog,
>>> which is excellent).
>>> 1. It seems to me that it might make sense for someone like webAIM, or
>>> a relatively objective and well respected third party to create and
>>> maintain a compatibility page for browsers and assistive technologies
>>> with regards to accessibility support (all the info is basically here
>>> in various blogs and in these discussions), and it might act as a
>>> disclaimer or source that people could link to in their own
>>> accessibility disclaimers. This would enable a somewhat generic
>>> accessibility statement and ensure a central page where changes can be
>>> made consistently as Assistive Technology is upgraded, or better info
>>> is available. Of course there could be issues, political or otherwise,
>>> why WebAIM per se, would not want to do this, but it seems to me like
>>> it would be a nice idea if some organization maintained a page with
>>> this info, allowing those who want to put browser and A.T. version
>>> support information on their websites (which I think is a great idea).
>>> If it is not centralized these statements will differ, be fragmented
>>> (not all people are aware of all screen readers, I see that
>>> Hal/Supernova support is absent in most lists for instance, something
>>> I could definitely help clear up), and out of synch, as it is not
>>> clear when each of these statements was updated and, hence, valid with
>>> regards to A.T. support for accessibility.
>>>
>>>
>>> 2. Perhaps I am somewhat alone in this opinion, I have certainly seen
>>> divided opinions on this. I think that when there is a free and open
>>> source screen reader out there, with navigation very similar to the
>>> Windows screen readers, that we can reasonably expect users who have
>>> older screen reading solutions, but require a more updated
>>> accessibility support, to go out there, download NVDA and learn how to
>>> use it. This is exaggerating the point certainly, especially when ARIA
>>> definitely is not as consistent in its implementation (for instance
>>> with keyboard support for flyout menus) as we'd wish it to be perhaps.
>>> There is a lot of users, who have recently lost their sight or are
>>> older and less computer savvy users, who simply can't deal with the
>>> complexities of ARIA, and are unlikely to frequent pages where ARIA is
>>> used aggressively. But, I think the availibility of quality ARIA
>>> support in a free and open source screen reader is a huge benefit, and
>>> can allow us to be a little more aggressive as developers utilizing
>>> these recent technologies to enable accessibility where other
>>> traditional means of A T support are not available. In short, whereas
>>> we need to preserve a balance, I wuld hate to avoid using ARIA because
>>> users of Jaws 7 can't utilize it. At this point, these users have the
>>> option to upgrade,and they need to.
>>>
>>> In my screen reader testing I have given a green light to features
>>> that NVDA 2011.2 supports, and also try to test two major versions
>>> back for the traditional major screen readers (now I test Jaws 12 and
>>> 13, with Jaws 11 testing being phased out).
>>> Perhaps this is overly aggressive, but there is definitely some
>>> responsibility for users to be up-to-date with their assistive
>>> technology, as long as it does not impose undue financial hardship on
>>> them.
>>>
>>>
>>> Cheers
>>> -B
>>>
>>> On 11/4/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>>>> I agree Randy, although at least we can start to proceed conservatively
>>>> for
>>>> most content, using the fallbacks. And with the friendly message in
>>>> place,
>>>> we can start to be aggressive with ARIA for the high tech crowd. We'll
>>>> find
>>>> out what's appropriate for the middle ground as we go -- and it will
>>>> change
>>>> (although not as fast as we'd like!)
>>>>
>>>> Aaron
>>>>
>>>> On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>>> HI Aaron,
>>>>>
>>>>> I'm in agreement with your thoughts. For many people with
>>>>> disabilities,
>>>>> updating or updating their assistive equipment and software pose a
>>>>> financial hardship. But again,,,it's very difficult to please
>>>>> everyone.
>>>>>
>>>>> With Warm Regards,
>>>>> Randy Pope
>>>>>
>>>>> -----Original Message-----
>>>>> From: = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron
>>>>> Leventhal
>>>>> Sent: Friday, November 04, 2011 3:02 PM
>>>>> To: WebAIM Discussion List
>>>>> Subject: Re: [WebAIM] Browser version advice in accessibility statement
>>>>>
>>>>> Hi Christophe, I agree that every effort should be made to support
>>>>> older
>>>>> versions of JAWS and IE, and screen readers w/o ARIA support (like
>>>>> Windoew-Eyes). However, in dynamic content it's not always feasible. In
>>>>> many
>>>>> cases, depending on the audience and type of content, it simply makes
>>>>> sense
>>>>> to use ARIA.
>>>>>
>>>>> To make things better for users of JAWS 7 or IE7, etc., I advocate a
>>>>> few
>>>>> things:
>>>>> - Use "safe" ARIA techniques as a progressive enhancement when feasible
>>>>> - When "full" ARIA support is necessary, inform users with older
>>>>> technology
>>>>> of the need to upgrade and what their options are -- via the fancy
>>>>> automatic
>>>>> approach if we can get that to work well.
>>>>>
>>>>> As far as WCAG 2 compliance in that case, a strict reading of
>>>>> accessibility
>>>>> supported indicates we just need a free alternative -- such as Firefox
>>>>> +
>>>>> NVDA. Unfortunately as much as we'd all like to, we can't support five
>>>>> year
>>>>> old screen reading solutions in modern web content. We need to start
>>>>> educating users of the need to refresh their technology.
>>>>>
>>>>> Aaron
>>>>>
>>>>> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
>>>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>>>
>>>>> > Hi Aaron,
>>>>> >
>>>>> > At 16:54 4-11-2011, Aaron Leventhal wrote:
>>>>> >
>>>>> >> (...)
>>>>> >>
>>>>> >>
>>>>> >> Target audience:
>>>>> >> 1. If targeting the broad public (e.g. a government website), it
>>>>> >> seems necessary to stay on the safe side.
>>>>> >> 2. If targeting advanced technology users (e.g. a high tech
>>>>> >> company),
>>>>> >> it seems reasonable to use ARIA a lot more, and to require a more
>>>>> >> advanced browser - screen reader combo for content outside of the
>>>>> >> basics (documentation, support, etc.)
>>>>> >>
>>>>> >> Safe -- content for the broader public, or is primarily static HTML:
>>>>> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>>>>> >> (version?), System Access (version?), etc.
>>>>> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ .
>>>>> >> Safari
>>>>> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>>>>> >> VoiceOver on iOS 4 or later
>>>>> >>
>>>>> >
>>>>> > This list reminds me of a similar list I wrote last year (in
>>>>> > deliverable
>>>>> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>>>>> >
>>>>> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack 3
>>>>> > (older versions of Internet Explorer and JAWS have no support for
>>>>> > WAI-ARIA),
>>>>> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3 (Firefox
>>>>> > 2
>>>>> > also supported MSAA and early drafts of WAI-ARIA),
>>>>> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack 3,
>>>>> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service Pack
>>>>> > 3,
>>>>> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service Pack
>>>>> > 3,
>>>>> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
>>>>> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
>>>>> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
>>>>> > ("Hardy Heron").
>>>>> >
>>>>> > This list was intended for creating accessibility support
>>>>> > documentation ("accessibility support" as defined by WCAG 2.0), hence
>>>>> > JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in countries
>>>>> > with refund schemes for assistive technologies, e.g. Belgium.)
>>>>> >
>>>>> > Best regards,
>>>>> >
>>>>> > Christophe
>>>>> >
>>>>> >
>>>>> > Full -- content for a high tech audience or must be dynamic by its
>>>>> nature:
>>>>> >> . IE8+ with JAWS 10+ (unfortunately there is no live region support
>>>>> >> in
>>>>> >> NVDA+IE)
>>>>> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>>>>> >> VoiceOver on Lion or later . Mobile browsers: to be determined
>>>>> >>
>>>>> >> (...)
>>>>> >>
>>>>> >> Thoughts?
>>>>> >>
>>>>> >> Aaron
>>>>> >>
>>>>> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White
>>>>> >> < = EMAIL ADDRESS REMOVED = >
>>>>> >> wrote:
>>>>> >>
>>>>> >> > Hi All,
>>>>> >> >
>>>>> >> > I have a client who is doing some excellent work on creating an
>>>>> >> inclusive
>>>>> >> > and engaging website. In order to do so they are drawing on the
>>>>> >> > features provided in WAI-ARIA. This leads to some difficulties
>>>>> >> > regarding browser
>>>>> >> and
>>>>> >> > screen reader compatibility and we discussed how to address this.
>>>>> >> > My personal opinion is to use part of the accessibility statement
>>>>> >> > to
>>>>> >> highlight
>>>>> >> > the efforts but point out the need for users to upgrade but I was
>>>>> >> curious
>>>>> >> > to understand how people view this?
>>>>> >> >
>>>>> >> > My opinion is based on the idea that ARIA provides the opportunity
>>>>> >> > to
>>>>> >> help
>>>>> >> > users of assistive technologies but in order to do that there is a
>>>>> >> > need
>>>>> >> to
>>>>> >> > use a modern browser. User may not know this and by providing
>>>>> >> information
>>>>> >> > around this there is an opportunity to provide wider help.
>>>>> >> >
>>>>> >> > I would be interested to hear any other views on this,
>>>>> >> >
>>>>> >> > Thanks
>>>>> >> >
>>>>> >> > Kevin
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Christophe Strobbe
>>>>> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on
>>>>> > Document Architectures Kasteelpark Arenberg 10 bus 2442
>>>>> > B-3001 Leuven-Heverlee
>>>>> > BELGIUM
>>>>> > tel: +32 16 32 85 51
>>>>> > http://www.docarch.be/
>>>>> > Twitter: @RabelaisA11y
>>>>> > ---
>>>>> > Open source for accessibility: results from the AEGIS project
>>>>> > www.aegis-project.eu
>>>>> > ---
>>>>> > Please don't invite me to Facebook, Quechup or other "social
>>>>> > networks".
>>>>> > You may have agreed to their "privacy policy", but I haven't.
>>>>> >
>>>>> >
>>>>> >

From: Kevin Chao
Date: Sun, Nov 06 2011 6:21PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Hi Patrick,

Of course, if one's using a corporate/work/office or educational
institute computer, one's limited by the central IT department, which
is usually using very limited, dated, and not very accessible
combination of web browser and AT, especially when it comes to WEB 2.0
(HTML5, ARIA, etc.). If the intranet were to deploy rich interactive,
and dynamic sites for everyone else in the office/institute, the
technology would have to be updated, especially the web browser and
AT.

Most sites are killing off support for IE6, which most companies and
educational institutes are still using, Internet Explorer's usage has
dropped below 50%, and people are switching to Firefox and Chrome.

Thanks, I do understand that users are not always in full control, but
I was expressing thoughts more on users who are in full control of
their own technology.

Kevin

On 11/6/11, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 06/11/2011 22:23, Kevin Chao wrote:
>> There's no excuse or reason at all one should not be running the
>> latest web browser and assistive technology, such as screen reader.
>> There's performance, security, accessibility, usability, support, etc.
>> benefits. Vendors/industry should not be limited due to users refusing
>> to update.
>
> Sadly, the reality in many companies is that central IT departments
> often prevent updates for various reasons...sometimes because the
> enterprise intranet systems were designed to only work in IE6 (my
> previous employer, a university, had this issue, with our internal
> accounting and personnel systems refusing to even work in IE7), other
> times because certain browsers don't play well with distributed profiles
> (I seem to remember older versions of Firefox had this issue) or because
> they simply don't want the strain on the network when every day a new
> fast-release-cycle version is being downloaded across thousands of
> installs around the organisation.
>
> However, the employers should provide modern versions that play well
> with AT under their duty (where applicable...section 508, DDA, etc) to
> make reasonable adjustments for their employees.
>
> But yes, just wanted to point out that users aren't always fully in control.
>
> P
> --
> Patrick H. Lauke
>

From: Birkir R. Gunnarsson
Date: Sun, Nov 06 2011 8:12PM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

Kevin

As this is getting very far from the realm of web accessibility, I'll
shoot you, or NVDA, an email later on to continue this discussion.
Thanks
-Birkir

On 11/7/11, Kevin Chao < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Patrick,
>
> Of course, if one's using a corporate/work/office or educational
> institute computer, one's limited by the central IT department, which
> is usually using very limited, dated, and not very accessible
> combination of web browser and AT, especially when it comes to WEB 2.0
> (HTML5, ARIA, etc.). If the intranet were to deploy rich interactive,
> and dynamic sites for everyone else in the office/institute, the
> technology would have to be updated, especially the web browser and
> AT.
>
> Most sites are killing off support for IE6, which most companies and
> educational institutes are still using, Internet Explorer's usage has
> dropped below 50%, and people are switching to Firefox and Chrome.
>
> Thanks, I do understand that users are not always in full control, but
> I was expressing thoughts more on users who are in full control of
> their own technology.
>
> Kevin
>
> On 11/6/11, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>> On 06/11/2011 22:23, Kevin Chao wrote:
>>> There's no excuse or reason at all one should not be running the
>>> latest web browser and assistive technology, such as screen reader.
>>> There's performance, security, accessibility, usability, support, etc.
>>> benefits. Vendors/industry should not be limited due to users refusing
>>> to update.
>>
>> Sadly, the reality in many companies is that central IT departments
>> often prevent updates for various reasons...sometimes because the
>> enterprise intranet systems were designed to only work in IE6 (my
>> previous employer, a university, had this issue, with our internal
>> accounting and personnel systems refusing to even work in IE7), other
>> times because certain browsers don't play well with distributed profiles
>> (I seem to remember older versions of Firefox had this issue) or because
>> they simply don't want the strain on the network when every day a new
>> fast-release-cycle version is being downloaded across thousands of
>> installs around the organisation.
>>
>> However, the employers should provide modern versions that play well
>> with AT under their duty (where applicable...section 508, DDA, etc) to
>> make reasonable adjustments for their employees.
>>
>> But yes, just wanted to point out that users aren't always fully in
>> control.
>>
>> P
>> --
>> Patrick H. Lauke
>>

From: Shuttlesworth, Rachel
Date: Mon, Nov 07 2011 8:00AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | Next message →

My two cents:

I agree that staying as current as possible is an excellent goal, but I think it is much more feasible for me to install the latest update on my home computer to work with certain web sites than it is for a university/college/business/other entity with a bunch of machines and applications to manage and coordinate. The choice to be on the latest release in order to use a site's features may make it so that I cannot use other applications.

I work in an area that supports 10 or so campus-wide instructional technology tools. We are continually faced with issues like "This release of this browser doesn't work well with that release of that tool". We are also dealing with the inability to roll out new images for classroom and lab computers mid-semester, which doesn't even come close to addressing the challenge of enterprise tool updates, like a new OS on the application servers for the LMS, which would in turn make it so we could install the latest release of the LMS, which would in turn offer our users support for the latest updates to various browsers.

Rachel


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Rachel Shuttlesworth Thompson
Director, Emerging Technologies and Research, Center for Instructional Technology
University of Alabama
Box 870346 * Tuscaloosa, AL 35487-0346
205.348.0216

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Kevin Chao
Sent: Sunday, November 06, 2011 4:24 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Browser version advice in accessibility statement

There's no excuse or reason at all one should not be running the latest web browser and assistive technology, such as screen reader.
There's performance, security, accessibility, usability, support, etc.
benefits. Vendors/industry should not be limited due to users refusing to update.

I think that HTML5 and ARIA should only be applied when needed, such as rich, interactive, and dynamic sites. If a website is a fairly static site and standard HTML4 markup will work, there's no need to add additional complexity by adding in ARIA. However, if in the road map of a company/site has plans on adding more rich, interactive, and dynamic components; it's best to build in the HTML5 and ARIA support during the R&D stage.

When it comes to web browser and assistive technology support, the web is moving very quickly, and in order for companies/websites to keep up; the minimum requirement and support must be very strict. It should be forced to current and previous version, nothing more.

Firefox+NVDA, specifically 10 Nightly and 2011.3 Snapshot has the most
fastest, solid, accurate, and rich support for the web, specifically
HTML5 and ARIA.
NVDA works very well with Chrome 17 Canary and Google is actively working on fixing a lot of accessibility support in many areas, including HTML5 and ARIA.

Chrome+ChromeVox on Windows or Mac has very good support for the web
(rich, dynamic, and interactive), but ARIA support is a work in progress.

Internet Explorer 9/8 does not have proper, robust, and rich accessibility API's for ARIA and HTML5. Any AT/screen reader who claims support for it is hacking support in, which results in poor performance, instability, and buggy/inaccurate results.

iOS 5, VoiceOver, and Safari made a lot of great strides, especially over iOS 4.3.X in improving HTML5 and ARIA accessibility support.

OS X Lion, Safari, and Voiceover just added ARIA support, it's quite weak, and has a ways to go still. However, its support for HTML5 and ARIA is far better than Window-Eyes, who has very weak web support, and no HTML5 or ARIA.

I'm not sure how well SuperNova and System Access HTML5 and ARIA support is.

Opera web browser should not even been considered at all or mentioned until it's fully accessible with various assistive technologies.

As a user myself, I don't think it's unreasonable at all to ask the end-user of a website to upgrade to the latest web browser and AT to fully utalize, leverage, and benefit from the Web 2.0 features of the website. This should not be provided in a hidden link, but a visible link, which when viewed provides the best combination, which on Windows is Firefox+NVDA. NVDA, which is free and open source has the best support, which results in the cost factor/excuse being thrown out the window.

Most of the paid commercial screen readers are ones that I don't use as their bloated, buggy, slow, and don't have great support for the web, such as HTML5 and ARIA.

Kevin

On 11/6/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
> We definitely all need the compatibility list!
>
> Also, as far as inconsistent implementations of ARIA and how it
> affects older users ... If ARIA is implemented well the user should
> not have any trouble, because on almost l cases the accessibility
> behavior should be what they are already accustomed to. The
> inconsistency really points to the need for the ARIA developer portal
> where proper ARIA techniques are discussed and documented. We need
> aria testing tools, and we need a community that is more involved. We
> need to Identify and document the techniques and issues or
> inconsistencies in key implementations, and get after developers to fix their bugs.
>
> I believe this is all possible.
>
> Aaron
> -----Original Message-----
> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> Sender: = EMAIL ADDRESS REMOVED =
> Date: Sun, 6 Nov 2011 03:36:27
> To: WebAIM Discussion List< = EMAIL ADDRESS REMOVED = >
> Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Browser version advice in accessibility
> statement
>
> Two minor thoughts on this (apart from me being outright impressed
> with the wealth of useful info on here, and discovering Henni's blog,
> which is excellent).
> 1. It seems to me that it might make sense for someone like webAIM, or
> a relatively objective and well respected third party to create and
> maintain a compatibility page for browsers and assistive technologies
> with regards to accessibility support (all the info is basically here
> in various blogs and in these discussions), and it might act as a
> disclaimer or source that people could link to in their own
> accessibility disclaimers. This would enable a somewhat generic
> accessibility statement and ensure a central page where changes can be
> made consistently as Assistive Technology is upgraded, or better info
> is available. Of course there could be issues, political or otherwise,
> why WebAIM per se, would not want to do this, but it seems to me like
> it would be a nice idea if some organization maintained a page with
> this info, allowing those who want to put browser and A.T. version
> support information on their websites (which I think is a great idea).
> If it is not centralized these statements will differ, be fragmented
> (not all people are aware of all screen readers, I see that
> Hal/Supernova support is absent in most lists for instance, something
> I could definitely help clear up), and out of synch, as it is not
> clear when each of these statements was updated and, hence, valid with
> regards to A.T. support for accessibility.
>
>
> 2. Perhaps I am somewhat alone in this opinion, I have certainly seen
> divided opinions on this. I think that when there is a free and open
> source screen reader out there, with navigation very similar to the
> Windows screen readers, that we can reasonably expect users who have
> older screen reading solutions, but require a more updated
> accessibility support, to go out there, download NVDA and learn how to
> use it. This is exaggerating the point certainly, especially when ARIA
> definitely is not as consistent in its implementation (for instance
> with keyboard support for flyout menus) as we'd wish it to be perhaps.
> There is a lot of users, who have recently lost their sight or are
> older and less computer savvy users, who simply can't deal with the
> complexities of ARIA, and are unlikely to frequent pages where ARIA is
> used aggressively. But, I think the availibility of quality ARIA
> support in a free and open source screen reader is a huge benefit, and
> can allow us to be a little more aggressive as developers utilizing
> these recent technologies to enable accessibility where other
> traditional means of A T support are not available. In short, whereas
> we need to preserve a balance, I wuld hate to avoid using ARIA because
> users of Jaws 7 can't utilize it. At this point, these users have the
> option to upgrade,and they need to.
>
> In my screen reader testing I have given a green light to features
> that NVDA 2011.2 supports, and also try to test two major versions
> back for the traditional major screen readers (now I test Jaws 12 and
> 13, with Jaws 11 testing being phased out).
> Perhaps this is overly aggressive, but there is definitely some
> responsibility for users to be up-to-date with their assistive
> technology, as long as it does not impose undue financial hardship on
> them.
>
>
> Cheers
> -B
>
> On 11/4/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>> I agree Randy, although at least we can start to proceed
>> conservatively for most content, using the fallbacks. And with the
>> friendly message in place, we can start to be aggressive with ARIA
>> for the high tech crowd. We'll find out what's appropriate for the
>> middle ground as we go -- and it will change (although not as fast as
>> we'd like!)
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> HI Aaron,
>>>
>>> I'm in agreement with your thoughts. For many people with
>>> disabilities, updating or updating their assistive equipment and software pose a
>>> financial hardship. But again,,,it's very difficult to please everyone.
>>>
>>> With Warm Regards,
>>> Randy Pope
>>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron
>>> Leventhal
>>> Sent: Friday, November 04, 2011 3:02 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Browser version advice in accessibility
>>> statement
>>>
>>> Hi Christophe, I agree that every effort should be made to support
>>> older versions of JAWS and IE, and screen readers w/o ARIA support
>>> (like Windoew-Eyes). However, in dynamic content it's not always
>>> feasible. In many cases, depending on the audience and type of
>>> content, it simply makes sense to use ARIA.
>>>
>>> To make things better for users of JAWS 7 or IE7, etc., I advocate a
>>> few
>>> things:
>>> - Use "safe" ARIA techniques as a progressive enhancement when
>>> feasible
>>> - When "full" ARIA support is necessary, inform users with older
>>> technology of the need to upgrade and what their options are -- via
>>> the fancy automatic approach if we can get that to work well.
>>>
>>> As far as WCAG 2 compliance in that case, a strict reading of
>>> accessibility supported indicates we just need a free alternative --
>>> such as Firefox + NVDA. Unfortunately as much as we'd all like to,
>>> we can't support five year old screen reading solutions in modern
>>> web content. We need to start educating users of the need to refresh
>>> their technology.
>>>
>>> Aaron
>>>
>>> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> > Hi Aaron,
>>> >
>>> > At 16:54 4-11-2011, Aaron Leventhal wrote:
>>> >
>>> >> (...)
>>> >>
>>> >>
>>> >> Target audience:
>>> >> 1. If targeting the broad public (e.g. a government website), it
>>> >> seems necessary to stay on the safe side.
>>> >> 2. If targeting advanced technology users (e.g. a high tech
>>> >> company), it seems reasonable to use ARIA a lot more, and to
>>> >> require a more advanced browser - screen reader combo for content
>>> >> outside of the basics (documentation, support, etc.)
>>> >>
>>> >> Safe -- content for the broader public, or is primarily static HTML:
>>> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>>> >> (version?), System Access (version?), etc.
>>> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ .
>>> >> Safari
>>> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>>> >> VoiceOver on iOS 4 or later
>>> >>
>>> >
>>> > This list reminds me of a similar list I wrote last year (in
>>> > deliverable
>>> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>>> >
>>> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack
>>> > 3 (older versions of Internet Explorer and JAWS have no support
>>> > for WAI-ARIA),
>>> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3
>>> > (Firefox 2 also supported MSAA and early drafts of WAI-ARIA),
>>> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack
>>> > 3,
>>> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service
>>> > Pack 3,
>>> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service
>>> > Pack 3,
>>> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
>>> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
>>> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
>>> > ("Hardy Heron").
>>> >
>>> > This list was intended for creating accessibility support
>>> > documentation ("accessibility support" as defined by WCAG 2.0),
>>> > hence JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in
>>> > countries with refund schemes for assistive technologies, e.g.
>>> > Belgium.)
>>> >
>>> > Best regards,
>>> >
>>> > Christophe
>>> >
>>> >
>>> > Full -- content for a high tech audience or must be dynamic by
>>> > its
>>> nature:
>>> >> . IE8+ with JAWS 10+ (unfortunately there is no live region
>>> >> support in
>>> >> NVDA+IE)
>>> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>>> >> VoiceOver on Lion or later . Mobile browsers: to be determined
>>> >>
>>> >> (...)
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> Aaron
>>> >>
>>> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White
>>> >> < = EMAIL ADDRESS REMOVED = >
>>> >> wrote:
>>> >>
>>> >> > Hi All,
>>> >> >
>>> >> > I have a client who is doing some excellent work on creating an
>>> >> inclusive
>>> >> > and engaging website. In order to do so they are drawing on the
>>> >> > features provided in WAI-ARIA. This leads to some difficulties
>>> >> > regarding browser
>>> >> and
>>> >> > screen reader compatibility and we discussed how to address this.
>>> >> > My personal opinion is to use part of the accessibility
>>> >> > statement to
>>> >> highlight
>>> >> > the efforts but point out the need for users to upgrade but I
>>> >> > was
>>> >> curious
>>> >> > to understand how people view this?
>>> >> >
>>> >> > My opinion is based on the idea that ARIA provides the
>>> >> > opportunity to
>>> >> help
>>> >> > users of assistive technologies but in order to do that there
>>> >> > is a need
>>> >> to
>>> >> > use a modern browser. User may not know this and by providing
>>> >> information
>>> >> > around this there is an opportunity to provide wider help.
>>> >> >
>>> >> > I would be interested to hear any other views on this,
>>> >> >
>>> >> > Thanks
>>> >> >
>>> >> > Kevin
>>> >>
>>> >
>>> >
>>> > --
>>> > Christophe Strobbe
>>> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group
>>> > on Document Architectures Kasteelpark Arenberg 10 bus 2442
>>> > B-3001 Leuven-Heverlee
>>> > BELGIUM
>>> > tel: +32 16 32 85 51
>>> > http://www.docarch.be/
>>> > Twitter: @RabelaisA11y
>>> > ---
>>> > Open source for accessibility: results from the AEGIS project
>>> > www.aegis-project.eu
>>> > ---
>>> > Please don't invite me to Facebook, Quechup or other "social networks".
>>> > You may have agreed to their "privacy policy", but I haven't.
>>> >
>>> >
>>> >

From: Bourne, Sarah (ITD)
Date: Mon, Nov 07 2011 8:39AM
Subject: Re: Browser version advice in accessibility statement
← Previous message | No next message

Kevin said, "There's no excuse or reason at all one should not be running the latest web browser and assistive technology, such as screen reader." I used to think that, too, until I started with working with actual users.

For instance, I recently was working to help a woman who was using and ancient operating system, and software to match. She is adamantly opposed to letting the IT support folks upgrade anything, because it all works for what she needs to do. She is just not interested in having to learn a whole lot of new things when her job itself hasn't changed. She also has a lot of custom JAWS scripting, and she is fearful that it will stop working correctly when things get upgraded. Fortunately, her employer is more interested in making sure she is a productive and happy worker than in making her upgrade to make their IT support work easier.

I suspect there are many home users with the same fears and concerns, but it's worse because they don't have IT staff for assistance.

sb

Sarah E. Bourne
Director of Assistive Technology &
Mass.Gov Chief Technology Strategist
Information Technology Division
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502 fax 617-626-4516
http://twitter.com/sarahebourne
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/itd


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Shuttlesworth, Rachel
Sent: Monday, November 07, 2011 9:59 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Browser version advice in accessibility statement

My two cents:

I agree that staying as current as possible is an excellent goal, but I think it is much more feasible for me to install the latest update on my home computer to work with certain web sites than it is for a university/college/business/other entity with a bunch of machines and applications to manage and coordinate. The choice to be on the latest release in order to use a site's features may make it so that I cannot use other applications.

I work in an area that supports 10 or so campus-wide instructional technology tools. We are continually faced with issues like "This release of this browser doesn't work well with that release of that tool". We are also dealing with the inability to roll out new images for classroom and lab computers mid-semester, which doesn't even come close to addressing the challenge of enterprise tool updates, like a new OS on the application servers for the LMS, which would in turn make it so we could install the latest release of the LMS, which would in turn offer our users support for the latest updates to various browsers.

Rachel


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Rachel Shuttlesworth Thompson
Director, Emerging Technologies and Research, Center for Instructional Technology University of Alabama Box 870346 * Tuscaloosa, AL 35487-0346
205.348.0216

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Kevin Chao
Sent: Sunday, November 06, 2011 4:24 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Browser version advice in accessibility statement

There's no excuse or reason at all one should not be running the latest web browser and assistive technology, such as screen reader.
There's performance, security, accessibility, usability, support, etc.
benefits. Vendors/industry should not be limited due to users refusing to update.

I think that HTML5 and ARIA should only be applied when needed, such as rich, interactive, and dynamic sites. If a website is a fairly static site and standard HTML4 markup will work, there's no need to add additional complexity by adding in ARIA. However, if in the road map of a company/site has plans on adding more rich, interactive, and dynamic components; it's best to build in the HTML5 and ARIA support during the R&D stage.

When it comes to web browser and assistive technology support, the web is moving very quickly, and in order for companies/websites to keep up; the minimum requirement and support must be very strict. It should be forced to current and previous version, nothing more.

Firefox+NVDA, specifically 10 Nightly and 2011.3 Snapshot has the most
fastest, solid, accurate, and rich support for the web, specifically
HTML5 and ARIA.
NVDA works very well with Chrome 17 Canary and Google is actively working on fixing a lot of accessibility support in many areas, including HTML5 and ARIA.

Chrome+ChromeVox on Windows or Mac has very good support for the web
(rich, dynamic, and interactive), but ARIA support is a work in progress.

Internet Explorer 9/8 does not have proper, robust, and rich accessibility API's for ARIA and HTML5. Any AT/screen reader who claims support for it is hacking support in, which results in poor performance, instability, and buggy/inaccurate results.

iOS 5, VoiceOver, and Safari made a lot of great strides, especially over iOS 4.3.X in improving HTML5 and ARIA accessibility support.

OS X Lion, Safari, and Voiceover just added ARIA support, it's quite weak, and has a ways to go still. However, its support for HTML5 and ARIA is far better than Window-Eyes, who has very weak web support, and no HTML5 or ARIA.

I'm not sure how well SuperNova and System Access HTML5 and ARIA support is.

Opera web browser should not even been considered at all or mentioned until it's fully accessible with various assistive technologies.

As a user myself, I don't think it's unreasonable at all to ask the end-user of a website to upgrade to the latest web browser and AT to fully utalize, leverage, and benefit from the Web 2.0 features of the website. This should not be provided in a hidden link, but a visible link, which when viewed provides the best combination, which on Windows is Firefox+NVDA. NVDA, which is free and open source has the best support, which results in the cost factor/excuse being thrown out the window.

Most of the paid commercial screen readers are ones that I don't use as their bloated, buggy, slow, and don't have great support for the web, such as HTML5 and ARIA.

Kevin

On 11/6/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
> We definitely all need the compatibility list!
>
> Also, as far as inconsistent implementations of ARIA and how it
> affects older users ... If ARIA is implemented well the user should
> not have any trouble, because on almost l cases the accessibility
> behavior should be what they are already accustomed to. The
> inconsistency really points to the need for the ARIA developer portal
> where proper ARIA techniques are discussed and documented. We need
> aria testing tools, and we need a community that is more involved. We
> need to Identify and document the techniques and issues or
> inconsistencies in key implementations, and get after developers to fix their bugs.
>
> I believe this is all possible.
>
> Aaron
> -----Original Message-----
> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> Sender: = EMAIL ADDRESS REMOVED =
> Date: Sun, 6 Nov 2011 03:36:27
> To: WebAIM Discussion List< = EMAIL ADDRESS REMOVED = >
> Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Browser version advice in accessibility
> statement
>
> Two minor thoughts on this (apart from me being outright impressed
> with the wealth of useful info on here, and discovering Henni's blog,
> which is excellent).
> 1. It seems to me that it might make sense for someone like webAIM, or
> a relatively objective and well respected third party to create and
> maintain a compatibility page for browsers and assistive technologies
> with regards to accessibility support (all the info is basically here
> in various blogs and in these discussions), and it might act as a
> disclaimer or source that people could link to in their own
> accessibility disclaimers. This would enable a somewhat generic
> accessibility statement and ensure a central page where changes can be
> made consistently as Assistive Technology is upgraded, or better info
> is available. Of course there could be issues, political or otherwise,
> why WebAIM per se, would not want to do this, but it seems to me like
> it would be a nice idea if some organization maintained a page with
> this info, allowing those who want to put browser and A.T. version
> support information on their websites (which I think is a great idea).
> If it is not centralized these statements will differ, be fragmented
> (not all people are aware of all screen readers, I see that
> Hal/Supernova support is absent in most lists for instance, something
> I could definitely help clear up), and out of synch, as it is not
> clear when each of these statements was updated and, hence, valid with
> regards to A.T. support for accessibility.
>
>
> 2. Perhaps I am somewhat alone in this opinion, I have certainly seen
> divided opinions on this. I think that when there is a free and open
> source screen reader out there, with navigation very similar to the
> Windows screen readers, that we can reasonably expect users who have
> older screen reading solutions, but require a more updated
> accessibility support, to go out there, download NVDA and learn how to
> use it. This is exaggerating the point certainly, especially when ARIA
> definitely is not as consistent in its implementation (for instance
> with keyboard support for flyout menus) as we'd wish it to be perhaps.
> There is a lot of users, who have recently lost their sight or are
> older and less computer savvy users, who simply can't deal with the
> complexities of ARIA, and are unlikely to frequent pages where ARIA is
> used aggressively. But, I think the availibility of quality ARIA
> support in a free and open source screen reader is a huge benefit, and
> can allow us to be a little more aggressive as developers utilizing
> these recent technologies to enable accessibility where other
> traditional means of A T support are not available. In short, whereas
> we need to preserve a balance, I wuld hate to avoid using ARIA because
> users of Jaws 7 can't utilize it. At this point, these users have the
> option to upgrade,and they need to.
>
> In my screen reader testing I have given a green light to features
> that NVDA 2011.2 supports, and also try to test two major versions
> back for the traditional major screen readers (now I test Jaws 12 and
> 13, with Jaws 11 testing being phased out).
> Perhaps this is overly aggressive, but there is definitely some
> responsibility for users to be up-to-date with their assistive
> technology, as long as it does not impose undue financial hardship on
> them.
>
>
> Cheers
> -B
>
> On 11/4/11, Aaron Leventhal < = EMAIL ADDRESS REMOVED = > wrote:
>> I agree Randy, although at least we can start to proceed
>> conservatively for most content, using the fallbacks. And with the
>> friendly message in place, we can start to be aggressive with ARIA
>> for the high tech crowd. We'll find out what's appropriate for the
>> middle ground as we go -- and it will change (although not as fast as
>> we'd like!)
>>
>> Aaron
>>
>> On Fri, Nov 4, 2011 at 4:27 PM, Randy Pope < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> HI Aaron,
>>>
>>> I'm in agreement with your thoughts. For many people with
>>> disabilities, updating or updating their assistive equipment and software pose a
>>> financial hardship. But again,,,it's very difficult to please everyone.
>>>
>>> With Warm Regards,
>>> Randy Pope
>>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Aaron
>>> Leventhal
>>> Sent: Friday, November 04, 2011 3:02 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Browser version advice in accessibility
>>> statement
>>>
>>> Hi Christophe, I agree that every effort should be made to support
>>> older versions of JAWS and IE, and screen readers w/o ARIA support
>>> (like Windoew-Eyes). However, in dynamic content it's not always
>>> feasible. In many cases, depending on the audience and type of
>>> content, it simply makes sense to use ARIA.
>>>
>>> To make things better for users of JAWS 7 or IE7, etc., I advocate a
>>> few
>>> things:
>>> - Use "safe" ARIA techniques as a progressive enhancement when
>>> feasible
>>> - When "full" ARIA support is necessary, inform users with older
>>> technology of the need to upgrade and what their options are -- via
>>> the fancy automatic approach if we can get that to work well.
>>>
>>> As far as WCAG 2 compliance in that case, a strict reading of
>>> accessibility supported indicates we just need a free alternative --
>>> such as Firefox + NVDA. Unfortunately as much as we'd all like to,
>>> we can't support five year old screen reading solutions in modern
>>> web content. We need to start educating users of the need to refresh
>>> their technology.
>>>
>>> Aaron
>>>
>>> On Fri, Nov 4, 2011 at 2:04 PM, Christophe Strobbe <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> > Hi Aaron,
>>> >
>>> > At 16:54 4-11-2011, Aaron Leventhal wrote:
>>> >
>>> >> (...)
>>> >>
>>> >>
>>> >> Target audience:
>>> >> 1. If targeting the broad public (e.g. a government website), it
>>> >> seems necessary to stay on the safe side.
>>> >> 2. If targeting advanced technology users (e.g. a high tech
>>> >> company), it seems reasonable to use ARIA a lot more, and to
>>> >> require a more advanced browser - screen reader combo for content
>>> >> outside of the basics (documentation, support, etc.)
>>> >>
>>> >> Safe -- content for the broader public, or is primarily static HTML:
>>> >> . IE7+ with JAWS 7+, NVDA 2011.1+ or Window-Eyes 5.5+, Hal
>>> >> (version?), System Access (version?), etc.
>>> >> . Firefox 3.6 + with JAWS 7+, NVDA 2011.1+, Window-Eyes 5.5+ .
>>> >> Safari
>>> >> 4+ with VoiceOver on Snow Leopard or later . Mobile Safari and
>>> >> VoiceOver on iOS 4 or later
>>> >>
>>> >
>>> > This list reminds me of a similar list I wrote last year (in
>>> > deliverable
>>> > D3.1.2 for the AEGIS project; PDF at <http://tinyurl.com/6jjw8pz>;):
>>> >
>>> > * Internet Explorer 7 with JAWS 9 on Windows XP with Service Pack
>>> > 3 (older versions of Internet Explorer and JAWS have no support
>>> > for WAI-ARIA),
>>> > * Firefox 3.0 with JAWS 9 on Windows XP with Service Pack 3
>>> > (Firefox 2 also supported MSAA and early drafts of WAI-ARIA),
>>> > * Firefox 3.0 with Window-Eyes 5.5 on Windows XP with Service Pack
>>> > 3,
>>> > * Internet Explorer 7 with MAGic 11 on Windows XP with Service
>>> > Pack 3,
>>> > * Internet Explorer 7 with ZoomText 9 on Windows XP with Service
>>> > Pack 3,
>>> > * Safari 3 on Mac OS X 10.5 with VoiceOver,
>>> > * Firefox 3.0 with Orca on Ubuntu 8.04 LTS ("Hardy Heron"),
>>> > * Firefox 3.0 with GNOME's built-in magnifiers on Ubuntu 8.04 LTS
>>> > ("Hardy Heron").
>>> >
>>> > This list was intended for creating accessibility support
>>> > documentation ("accessibility support" as defined by WCAG 2.0),
>>> > hence JAWS 9 instead of JAWS 7. (JAWS 7 is still in use, even in
>>> > countries with refund schemes for assistive technologies, e.g.
>>> > Belgium.)
>>> >
>>> > Best regards,
>>> >
>>> > Christophe
>>> >
>>> >
>>> > Full -- content for a high tech audience or must be dynamic by
>>> > its
>>> nature:
>>> >> . IE8+ with JAWS 10+ (unfortunately there is no live region
>>> >> support in
>>> >> NVDA+IE)
>>> >> . Firefox 3.6+ with JAWS 10+ or NVDA 2011.1+ . Safari 5+ with
>>> >> VoiceOver on Lion or later . Mobile browsers: to be determined
>>> >>
>>> >> (...)
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> Aaron
>>> >>
>>> >> On Fri, Nov 4, 2011 at 10:33 AM, Kevin White
>>> >> < = EMAIL ADDRESS REMOVED = >
>>> >> wrote:
>>> >>
>>> >> > Hi All,
>>> >> >
>>> >> > I have a client who is doing some excellent work on creating an
>>> >> inclusive
>>> >> > and engaging website. In order to do so they are drawing on the
>>> >> > features provided in WAI-ARIA. This leads to some difficulties
>>> >> > regarding browser
>>> >> and
>>> >> > screen reader compatibility and we discussed how to address this.
>>> >> > My personal opinion is to use part of the accessibility
>>> >> > statement to
>>> >> highlight
>>> >> > the efforts but point out the need for users to upgrade but I
>>> >> > was
>>> >> curious
>>> >> > to understand how people view this?
>>> >> >
>>> >> > My opinion is based on the idea that ARIA provides the
>>> >> > opportunity to
>>> >> help
>>> >> > users of assistive technologies but in order to do that there
>>> >> > is a need
>>> >> to
>>> >> > use a modern browser. User may not know this and by providing
>>> >> information
>>> >> > around this there is an opportunity to provide wider help.
>>> >> >
>>> >> > I would be interested to hear any other views on this,
>>> >> >
>>> >> > Thanks
>>> >> >
>>> >> > Kevin
>>> >>
>>> >
>>> >
>>> > --
>>> > Christophe Strobbe
>>> > K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group
>>> > on Document Architectures Kasteelpark Arenberg 10 bus 2442
>>> > B-3001 Leuven-Heverlee
>>> > BELGIUM
>>> > tel: +32 16 32 85 51
>>> > http://www.docarch.be/
>>> > Twitter: @RabelaisA11y
>>> > ---
>>> > Open source for accessibility: results from the AEGIS project
>>> > www.aegis-project.eu
>>> > ---
>>> > Please don't invite me to Facebook, Quechup or other "social networks".
>>> > You may have agreed to their "privacy policy", but I haven't.
>>> >
>>> >
>>> >