[nfbcs] Google Accessibility was RE: evaluation display of a web page

Kevin Fjelsted kfjelsted at gmail.com
Wed Nov 6 14:17:35 UTC 2013 

I don’t think that the parallels with what was done with Java to date are the same. 

From what I can see Java is somewhat accessible when the bridge is run however the approach that was taken i.e., leaving that process outside the purview of the screen reader instead of integrating it is the real problem.
One only needs to look at the fruits.
I can make a list of at least ten web pages that are more accessible in Chrome than Jaws - IE-ff.
Why is this?
Although there are many technical reasons wouldn’t it be wise to put biases aside and just ask the question of why?

We can continue to discuss the technical side but the fruits are important to look at.
When I need access to my Moodl university web site and JAWS, Safari, FireFox, IE don’t work but Chrome does I am sure happy that I have chromevox.

Then I ask the next question which has already been discussed as to why does Chrome work.
Emphatically, the more that the traditional screen reader approach is taken as it pertains with browsers, the more quagmire will be experienced.

-Kevin
On Nov 6, 2013, at 6:14 AM, Steve Jacobson <steve.jacobson at visi.com> wrote:

> Kevin,
> 
> I agree in theory, but isn't that what was supposedly done with the JAVA programming language?  I do understand that JAVA and JAVA script are 
> completely different by the way.  Still, we can't use most JAVA programs and efforts to make that language accessible have been going on for fifteen 
> years at least.  Adobe has built some accessibility into FLASH, but it can be complicated to implement because you wouldn't want to dictate to FLASH 
> developers that their products should be accessible.  We just have a lot of trouble in general getting mass adoption of approaches that make software 
> and web sites accessible.  My contention is that we really need to explore approaches to accessibility that requires less from developers to succeed in the 
> long run.  This doesn't mean that I oppose any move to add API's, I just don't have the same confidence that it will really solve the problem even if it 
> makes some things better.  We seem to have never succeeded to get any built-in accessibility activated by default as there seems to always be too much 
> overhead for some, or it smacks of dimishing the freedom of developers to others.  
> 
> Best regards,
> 
> Steve Jacobson
> 
> 
> On Tue, 5 Nov 2013 22:59:32 -0600, Kevin Fjelsted wrote:
> 
>> My concern with Aria is that of the millions of web pages out there only a small minority will implement it.
>> I think that there needs to be a focus on implementing Aria where it can be done but the CSS analysis and Javascript and event analysis needs to be a 
> major focus. This can only be done if the accessibility interface or screen reading functions are deeply integrated with the browser or have a deep data 
> access.
>> -Kevin
> 
>> On Nov 5, 2013, at 9:41 PM, Nicole Torcolini <ntorcolini at wavecable.com> wrote:
> 
>>> Actually, no one should be getting mad at this question as it is a very good
>>> one. My opinion is that the answer is that it is the responsibility of all
>>> parties involved--the manufacturer of the screen reader, the manufacturer of
>>> the browser, and the producer of the websites.
>>> As there is a growing desire to make websites that are more complex than
>>> that which native HTML can support, there seems to be a movement away from
>>> native HTML, which is what most screen readers support the best. The way to
>>> make custom web controls now is to take a HTML element that does not already
>>> have functionality, such as a span or div, and attach one or more event
>>> listeners as well as decorating it with CSS. This clearly does not work for
>>> screen readers, though, as a screen reader has no way of telling that the
>>> element has functionality. The solution to this problem is Accessible Rich
>>> Internet Applications (WAI-ARIA). From http://www.w3.org/TR/wai-aria/:
>>> Accessibility of web content requires semantic information about widgets,
>>> structures, and behaviors, in order to allow assistive technologies to
>>> convey appropriate information to persons with disabilities. This
>>> specification provides an ontology of roles, states, and properties that
>>> define accessible user interface elements and can be used to improve the
>>> accessibility and interoperability of web content and applications. These
>>> semantics are designed to allow an author to properly convey user interface
>>> behaviors and structural information to assistive technologies in
>>> document-level markup. This document is part of the WAI-ARIA suite described
>>> in the WAI-ARIA Overview.
>>> 
>>> Okay, so why doesn't this solve all of the problems?
>>> 
>>> 1. Even though it is clearly defined how the roles and attributes are to be
>>> interpreted and presented to the user, not all screen readers follow these
>>> guidelines. For example, JAWS allows the user to specify how the accessible
>>> should be determined instead of following the ARIA spec.
>>> 
>>> 2. Even if ARIA is used, a screen reader only gets the information that the
>>> browser passes to it. This explains why there are often differences in how
>>> well the same screen reader will work on a particular website in different
>>> browsers. Chrome Vox actually does not really have this problem because it
>>> has direct access to the HTML without having to work with only what the
>>> browser gives it.
>>> 
>>> 3. Finally, even when the screen readers and browsers work correctly
>>> together, it still does not solve the problem unless the producers of the
>>> websites use ARIA. Not everyone knows about ARIA. Also, those who do
>>> sometimes inadvertently do not quite use it in the correct way or do not
>>> understand it. It is hard to visually test if ARIA is giving the desired
>>> result as ARIA, for the most part, does not modify the visual appearance.
>>> 
>>> -----Original Message-----
>>> From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Michael Babcock
>>> Sent: Monday, November 04, 2013 3:29 PM
>>> To: 'NFB in Computer Science Mailing List'
>>> Subject: Re: [nfbcs] Google Accessibility was RE: evaluation display of a
>>> web page
>>> 
>>> I'm going to go out on a limb and ask something that I've been curious
>>> about... Likely this message will make someone mad.
>>> Why is it google's responsibility to make there products accessible?
>>> Why isn't it freedom scientifics or GW Micro's responsibility to make there
>>> screen readers work better? I mean seriously we all fork out $800+ for our
>>> screen readers on top of the price of the computer, (or state departments
>>> do), and when something doesn't work the manufacture of the screen reader
>>> blames inaccessibility from the vendor of the software were trying to use?
>>> Sounds like someone is just pushing the blaim onto someone else to me...
>>> IMO, and this is why I just use a 40 minute demo of jaws, and narrator with
>>> nvda... I don't buy screen readers, and won't pay for one. Now, I understand
>>> that people who write software can do better to make there software more
>>> accessible, however, google is going to worry about making there stuff
>>> accessible with there screen readers (chromevox, talkback, etc), and
>>> honestly jaws and voiceover will take backburner. 
>>> michael
>>> I work from home, and you can to.
>>> http://myownpay.com/
>>> 
>>> -----Original Message-----
>>> From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Steve Jacobson
>>> Sent: Monday, November 4, 2013 4:00 PM
>>> To: NFB in Computer Science Mailing List
>>> Subject: Re: [nfbcs] Google Accessibility was RE: evaluation display of a
>>> web page
>>> 
>>> Jim,
>>> 
>>> One struggle I have is that I think in some cases Google is trying to do
>>> some leading edge stuff that perhaps could be accessible but isn't supported
>>> well by screen readers.  Our only choice to some degree is to ask companies
>>> like Google to slow down, but I really think we need to get a better handle
>>> on what the limits are to current accessibility and when we need to pressure
>>> screen readers and when we need to pressure companies to conform some to
>>> existing standards and good practices.  From what I know of screen reader
>>> development, the problem isn't simply that screen readers don't bother
>>> supporting what might be supported better but that they are having to try to
>>> support so much that is new that they can't keep up.  What I don't think
>>> people recognize is that the more resources one puts into a project, the
>>> more management overhead is also added.  I don't think it is even
>>> proportional, the ratio goes up faster.  By management overhead, I don't
>>> mean people as much as all that has to be done to track changes and test new
>>> features as well as making sure old features are not broken in the process.
>>> I have found, for example, that some of Google's pages work better when one
>>> turns off JFW's virtual cursor or Window-Eyes' Browse Mode.  Unfortunately,
>>> there are still gaps, but it causes me to unsure when I should be
>>> complaining to Google and when it is the screen readers.  I also don't know
>>> how to resolve this adequately.  I really think we as consumers need to
>>> somehow understand this better as we move forward.
>>> 
>>> Best regards,
>>> 
>>> Steve Jacobson
>>> 
>>> On Mon, 4 Nov 2013 13:47:25 -0800, Jim Barbour wrote:
>>> 
>>>> It is true that Google, and every other web application developer, 
>>>> releases code far more frequently than older PC based software did.
>>>> However, it's still a good idea to let google know when you find thuff 
>>>> that doesn't work.
>>> 
>>>> The same is true for Apple.
>>> 
>>>> I don't know why, but we blind folks seem especially unwilling to speak 
>>>> up and let companies know when stuff isn't working for us.  We seem to 
>>>> have the rather toxic idea that "they should know if accessibility is 
>>>> broken and if they don't want to fix it then I'm going to help them."
>>> 
>>>> Jim
>>> 
>>>> On Mon, Nov 04, 2013 at 01:40:37PM -0800, Mike Freeman wrote:
>>>>> The problem is that "fixes" may not stick. Google is tinkering with 
>>>>> its stuff constantly. The phrase "if it ain't broke, don't fix it" is 
>>>>> not in their vocabulary.
>>>>> 
>>>>> Mike Freeman
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Nicole 
>>>>> Torcolini
>>>>> Sent: Saturday, November 02, 2013 3:16 PM
>>>>> To: 'NFB in Computer Science Mailing List'
>>>>> Subject: [nfbcs] Google Accessibility was RE: evaluation display of a 
>>>>> web page
>>>>> 
>>>>> April and all, if you are having problems with Google products, 
>>>>> please let them know. They may not be able to fix it right away, but 
>>>>> they still want to know and might be able to tell you some kind of 
>>>>> work
>>> around.
>>>>> 
>>>>> -----Original Message-----
>>>>> From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of April 
>>>>> Brown
>>>>> Sent: Saturday, November 02, 2013 2:05 PM
>>>>> To: nfbcs at nfbnet.org
>>>>> Subject: Re: [nfbcs] evaluation display of a web page
>>>>> 
>>>>> Ten years or so ago, I learned HTMl and attempted to code accessible 
>>>>> from W3schools.  They do have Code check.  I don't think it's that 
>>>>> good.  In the last year I have lost most of my vision, and much of my 
>>>>> hearing, so it's even more important than ever!  And I always wanted 
>>>>> to
>>> code accessible.
>>>>> Though, knowing some varying issues, especially with vision, I'm not 
>>>>> 100% sure it is possible to code for every variation.  I may be wrong.
>>>>> 
>>>>> Hi *Susan Stanzel,  It would be wonderful if programs on both ends 
>>>>> could fix the issues to make websites more accessible.  And I agree.
>>>>> I have tried to learn NVDA, and well, learning keyboard workarounds 
>>>>> is ten times harder than HTML ever was!
>>>>> 
>>>>> Hi ***Mike Jolls - Since you evaluate websites for accessibility, can 
>>>>> I ask you a question?  For the last few years, my author website has 
>>>>> been on a Google site.  Are Google websites accessible?  I can change 
>>>>> some of the coding, though much of what I think would need to be 
>>>>> adjusted is not accessible to the page holders that I can find.
>>>>> 
>>>>> Thanks.  Still new to the world of mostly deaf and blind, and the 
>>>>> screen readers that confuse me when they don't just work when I open 
>>>>> the page.*
>>>>> 
>>>>> *
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> nfbcs mailing list
>>>>> nfbcs at nfbnet.org
>>>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>>>> To unsubscribe, change your list options or get your account info for
>>> nfbcs:
>>>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/ntorcolini%40wavec
>>>>> able.co
>>>>> m
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> nfbcs mailing list
>>>>> nfbcs at nfbnet.org
>>>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>>>> To unsubscribe, change your list options or get your account info for
>>> nfbcs:
>>>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/k7uij%40panix.com
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> nfbcs mailing list
>>>>> nfbcs at nfbnet.org
>>>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>>>> To unsubscribe, change your list options or get your account info for
>>> nfbcs:
>>>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/jbar%40barcore.com
>>>>> 
>>> 
>>>> _______________________________________________
>>>> nfbcs mailing list
>>>> nfbcs at nfbnet.org
>>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>>> To unsubscribe, change your list options or get your account info for
>>> nfbcs:
>>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/steve.jacobson%40vis
>>>> i.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nfbcs mailing list
>>> nfbcs at nfbnet.org
>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>> To unsubscribe, change your list options or get your account info for nfbcs:
>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/empoweringtheblind%40iclo
>>> ud.com
>>> 
>>> 
>>> _______________________________________________
>>> nfbcs mailing list
>>> nfbcs at nfbnet.org
>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>> To unsubscribe, change your list options or get your account info for nfbcs:
>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/ntorcolini%40wavecable.co
>>> m
>>> 
>>> 
>>> _______________________________________________
>>> nfbcs mailing list
>>> nfbcs at nfbnet.org
>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>> To unsubscribe, change your list options or get your account info for nfbcs:
>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/kfjelsted%40gmail.com
> 
> 
>> _______________________________________________
>> nfbcs mailing list
>> nfbcs at nfbnet.org
>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>> To unsubscribe, change your list options or get your account info for nfbcs:
>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/steve.jacobson%40visi.com
> 
> 
> 
> 
> 
> _______________________________________________
> nfbcs mailing list
> nfbcs at nfbnet.org
> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> To unsubscribe, change your list options or get your account info for nfbcs:
> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/kfjelsted%40gmail.com

More information about the NFBCS mailing list