E-mail List Archives
Thread: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
Number of posts in this thread: 11 (In chronological order)
From: Snahendu Bhattacharya
Date: Mon, Aug 26 2013 6:07AM
Subject: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
No previous message | Next message →
Hi!
I have few questions on the process of accessibility remediation. I am not
sure, whether this is the right forum to discuss this questions. Still my
questions are as follows:
1. In my application, Table <caption> are not read out by JAWS while
testing in Chrome. Is that a expected behavior?
2. While testing an iPad application we have found "Skip to main content"
is not working on several occasion, though we have followed the standard
mentioned by WCAG or WebAIM. Surprisingly while we opened WebAIM site in
Tablet, all the instances of "skip to main content" didn't work as
expected. Is this a expected behavior?
3. We have used <br> tag in table column header for split the text in a
specific format. While reading with VO in iPad, it takes more than one
swipe to read the entire column header. Is it to be considered as potential
Accessibility bug?
It will be great help if you can respond to my queries or you can redirect
me to the proper forum.
--
Snahendu Bhattacharya
From: Jared Smith
Date: Mon, Aug 26 2013 7:49AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Snahendu Bhattacharya wrote:
> 1. In my application, Table <caption> are not read out by JAWS while
> testing in Chrome. Is that a expected behavior?
Screen reader support in Chrome is quite limited. Many things will not
work as expected.
> 2. While testing an iPad application we have found "Skip to main content"
> is not working on several occasion, though we have followed the standard
> mentioned by WCAG or WebAIM. Surprisingly while we opened WebAIM site in
> Tablet, all the instances of "skip to main content" didn't work as
> expected. Is this a expected behavior?
What is your anticipated behavior? A "skip" link is primarily intended
for keyboard users. Are you using a keyboard with your iPad? The skip
links on the WebAIM site do provide some utility for touch users with
VoiceOver. For example, you can navigate to the skip link, activate
it, and then begin navigating via rover actions directly at the main
content. In other words, it seems to be working as intended for me.
> 3. We have used <br> tag in table column header for split the text in a
> specific format. While reading with VO in iPad, it takes more than one
> swipe to read the entire column header. Is it to be considered as potential
> Accessibility bug?
If you're reading line by line, then yes, it would naturally take two
swipes to read two lines of header text.
Jared
From: Snahendu Bhattacharya
Date: Mon, Aug 26 2013 9:41AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Hi!
Thanks for replying. I will restructure my questions for further clarity.
Question 1. (Table caption in Chrome) Do we consider this as a potential
bug? This works fine with JAWS/IE. if yes, what can be possible solution
for this?
Question 2. ("Skip to main content" with Voiceover/iPad ) "Skip to main
content" is generally intended to Keyboard user. But if we consider screen
reader (here Voiceover), user, they are not able to activate the link by
double tapping while Voiceover is on. Screen reader is not reading from the
desired location. This happens for "webaim" website as well. if we open the
website in iPad and try to activate "skip to main content", we will find
the link is not taking to desired location for all the pages. same is
happening with my application as well. This works fine with JAWS/IE. What
might be possible issue for this?
Question 3. (<br> tag with Voiceover/iPad) Do we consider this as a
potential accessibility issue? This works fine with JAWS/IE.
Generally, if something is not working in specific browser/screen reader,
do we consider those as potential issues. or if the same is working with
any screen reader, should be considered as remediation?
Thanks & Regards,
Snahendu Bhattacharya
Snahendu Bhattacharya
On 26 August 2013 19:19, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> Snahendu Bhattacharya wrote:
>
> > 1. In my application, Table <caption> are not read out by JAWS while
> > testing in Chrome. Is that a expected behavior?
>
> Screen reader support in Chrome is quite limited. Many things will not
> work as expected.
>
> > 2. While testing an iPad application we have found "Skip to main content"
> > is not working on several occasion, though we have followed the standard
> > mentioned by WCAG or WebAIM. Surprisingly while we opened WebAIM site in
> > Tablet, all the instances of "skip to main content" didn't work as
> > expected. Is this a expected behavior?
>
> What is your anticipated behavior? A "skip" link is primarily intended
> for keyboard users. Are you using a keyboard with your iPad? The skip
> links on the WebAIM site do provide some utility for touch users with
> VoiceOver. For example, you can navigate to the skip link, activate
> it, and then begin navigating via rover actions directly at the main
> content. In other words, it seems to be working as intended for me.
>
> > 3. We have used <br> tag in table column header for split the text in a
> > specific format. While reading with VO in iPad, it takes more than one
> > swipe to read the entire column header. Is it to be considered as
> potential
> > Accessibility bug?
>
> If you're reading line by line, then yes, it would naturally take two
> swipes to read two lines of header text.
>
> Jared
> > > >
From: Trafford, Logan
Date: Mon, Aug 26 2013 10:06AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Jared (or others).
Pertaining to Chrome directly, is ChromeVox a viable screen reader? What is the general opinion?
Logan Trafford
From: Jared Smith
Date: Mon, Aug 26 2013 10:21AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
On Mon, Aug 26, 2013 at 9:41 AM, Snahendu Bhattacharya
< = EMAIL ADDRESS REMOVED = > wrote:
> Question 1. (Table caption in Chrome) Do we consider this as a potential
> bug?
Yes, it is a bug in Chrome.
> This works fine with JAWS/IE. if yes, what can be possible solution
> for this?
Don't use Chrome. There is such poor support for JAWS in Chrome that
it could hardly be considered a viable option for end users or for
testing.
> if we open the
> website in iPad and try to activate "skip to main content", we will find
> the link is not taking to desired location for all the pages. same is
> happening with my application as well. This works fine with JAWS/IE. What
> might be possible issue for this?
This is a VoiceOver issue. Again, there's nothing you can do to fix
this (except perhaps log a bug with Apple).
> Question 3. (<br> tag with Voiceover/iPad) Do we consider this as a
> potential accessibility issue? This works fine with JAWS/IE.
As above, there's nothing you can do to fix the screen reader quirks.
Nor should you try to. This certainly would not be a compliance
failure on your part.
> Generally, if something is not working in specific browser/screen reader,
> do we consider those as potential issues. or if the same is working with
> any screen reader, should be considered as remediation?
First of all, follow the guidelines. If you do things correctly,
there's a reasonable expectation that screen readers should support
your implementation of standards. When they fall short, it is
sometimes necessary to come up with workaround when the impact is
severe, but most of the time there's little you could or should do to
address screen reader bugs and quirks. In the cases you cite, the
impact of these bugs is relatively minor.
Jared
From: Jared Smith
Date: Mon, Aug 26 2013 10:25AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Trafford, Logan wrote:
> Pertaining to Chrome directly, is ChromeVox a viable screen reader? What is the general opinion?
I think this depends on what you mean by "viable". ChromeVox does web
page stuff only, so it couldn't be considered an alternative to a
full-featured screen reader (unless you do nothing outside the
browser). It's feature list is somewhat limited, but it's growing. A
primary concern is that nobody uses it. Our most recent screen reader
survey showed only .2% of respondents use it as a primary screen
reader - http://webaim.org/projects/screenreadersurvey4/#primary
Jared
From: Trafford, Logan
Date: Mon, Aug 26 2013 10:30AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Thanks Jared. You managed to surmise exactly what I meant by "viable".
Logan
From: Don Mauck
Date: Mon, Aug 26 2013 2:22PM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Having done some testing with the Chrome book, I'd agree that it use and list of features are very limited.
From: Alastair Campbell
Date: Tue, Aug 27 2013 2:37AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Snahendu Bhattacharya wrote:
> if we open the
> website in iPad and try to activate "skip to main content", we will find
> the link is not taking to desired location for all the pages.
Jared Smith wrote:
> This is a VoiceOver issue. Again, there's nothing you can do to fix
> this (except perhaps log a bug with Apple).
>
Is this the old webkit bug of not following within-page links?
I've had some success with using a small JS function to properly move the
focus.
In the HTML you'd have a skip to content link:
<a href="#main" id="skiplink">Skip to content</a>
Going to the main element (for example) which needs tabindex:
<main role="main" id="main" tabindex=-1>
Which JS/jQuery then assists VoiceOver to get to:
$("#skiplink").click(function() {
$('main').focus();
});
And since we don't want an outline around the main (usually), I tend to add
this to the CSS:
main:focus {outline: 0;}
I haven't found any issues with adding this, although hopefully it won't be
needed for much longer? Given that VoiceOver on iOS is probably the second
most used screenreader (according to WebAims survey!), we've been paying
more attention to it...
-Alastair
From: Snahendu Bhattacharya
Date: Wed, Aug 28 2013 7:38AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | Next message →
Thanks Jared for clarifying. This really helps.
Hi Alastair !
I also tried the solution you are referring to. But that didn't work for
me, probably because of some other code.
Can you confirm one point here. If the text is made hidden by the
following css, will the functionality still work?
font-size:0px;
line-height:0px;
opacity:0px;
link text is hidden here. But we can focus the text with voiceover on.
After the text receive focus, when we double tap, fucntionality doesn't
work. Do you think CSS is causing the issue here? because of the font size
and line height screen reader is not able activate the link functionality.
Would like to hear from you.
Snahendu Bhattacharya
From: Alastair Campbell
Date: Wed, Aug 28 2013 7:53AM
Subject: Re: Accessibility :: Issues with <br>, Issues with Chrome, Is it Skipping
← Previous message | No next message
Snahendu Bhattacharya wrote:
> Do you think CSS is causing the issue here? because of the font size
> and line height screen reader is not able activate the link
> functionality.
It is possible, but more likely to be something else, e.g. not targeting an
element that can take focus.
Can you share a the site or a test case as an example?
Also, don't forget about keyboard users who are not using a screen reader,
they should be able to see the link as well. We've an (old but I think
still valid) article on the topic:
http://www.nomensa.com/blog/2004/what-are-skip-links/
Regards.
-Alastair