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

Wed Nov 6 12:16:11 UTC 2013

Nicole,

If I understand what he is saying, that is his point.  Besides the numerous styles, there needs to be a standard way to pass the concept of the box being 
checked or unchecked.  At least that's how I understand what he is saying.

Best regards,

Steve Jacobson

On Tue, 5 Nov 2013 21:08:49 -0800, Nicole Torcolini wrote:

>Interesting  idea. One question, though. How exactly do you expect this to
>scale? There are a million different ways to style a checkbox so that it
>appears checked. Unless you have some huge library of possible style formats
>that could indicate checked, how is a screen reader going to understand
>this? The good thing about ARIA is that it is a common language.

>-----Original Message-----
>From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Kevin Fjelsted
>Sent: Tuesday, November 05, 2013 9:00 PM
>To: NFB in Computer Science Mailing List
>Subject: Re: [nfbcs] Google Accessibility was RE: evaluation display ofa web
>page

>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%40wave
>>>> c
>>>> 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.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/steve.jacobson%40v
>>> is
>>> 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%40waveca
>> ble.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.c
>> om

>_______________________________________________
>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/steve.jacobson%40visi.com