W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2014

Re: Ignore HTML elements in mobile devices

From: Rodrigo Prestes Machado <rodrigo.prestes@gmail.com>
Date: Tue, 9 Sep 2014 16:04:31 -0300
Message-Id: <BAAFBFDC-21E0-47DD-9269-A2DD1719D66B@gmail.com>
To: w3c-wai-ig@w3.org
Tank you Bryan!

I have put tab index and aria-hidden because the plan was to support the component in on tablet and a desktop, so, I dint know that it cause issues. Anyway, maybe I need to study more about ARIA =)

Best Regards!

Em 09/09/2014, à(s) 14:34, Bryan Garaventa <bryan.garaventa@whatsock.com> escreveu:

> Hi,
> In looking at the code, there are a couple of things that might help.
>  
> The use of tabindex on the label will cause issues for cross-platform implementation if this is seen on a desktop, so I removed it.
> Within the Input, the attribute role=textbox should be removed, since all text inputs are implicitly textboxes.
> Within the description, I removed aria-hidden since the CSS property of display:none or visibility:hidden will hide this content from ATs anyway, so it isn’t needed.
> Also in the description, I added role=”tooltip” to indicate its purpose.
>  
> <label aria-hidden="true" for="{{id}}">{{label}}</label>
>  
> <input
>     id="{{id}}"
>     type="{{type}}" 
>     label="{{label}}"
>     placeholder="{{label}}" 
>     name="nieeInput" 
>     value="{{value}}"
>     aria-label="{{label}}"
>     aria-describedby="{{descriptionId}}"
>     on-focus="{{showTipAction}}"
>     on-blur="{{hideTipAction}}">
>                        
> <p id="{{descriptionId}}" style="visibility: hidden" role=”tooltip” >
>             {{description}}
> </p>
>  
>  
> From: Rodrigo Prestes Machado [mailto:rodrigo.prestes@gmail.com] 
> Sent: Tuesday, September 09, 2014 5:29 AM
> To: w3c-wai-ig@w3.org
> Subject: Re: Ignore HTML elements in mobile devices
>  
> I have tested the aria-hidden=“true” and it works fine to hide HTML nodes in IPad with Safari. About my situation, I would like to hide some images used to style the pages and in this case below:
>  
> <label for="name">Name:</label>
> <input id="name" type="text" name="textfield"> 
>  
> I had to hide the label, because in mobile it is just a label without context and, add the placehold attribute in input tag. I`m trying to create some Accessible Polymer (https://www.polymer-project.org) Web Components for a project, so, in this moment, my solution was something like this:
>  
> <label tabindex="0" aria-hidden="true" for="{{id}}">{{label}}</label>
> <input
>     id="{{id}}"
>     type="{{type}}" 
>     label="{{label}}"
>     placeholder="{{label}}" 
>     name="nieeInput" 
>     value="{{value}}"
>     role="textbox"
>     aria-label="{{label}}"
>     aria-describedby="{{descriptionId}}"
>     on-focus="{{showTipAction}}"
>     on-blur="{{hideTipAction}}">
>                        
> <p id="{{descriptionId}}" style="visibility: hidden" aria-hidden="true">
>             {{description}}
> </p>
>  
> Best regards,
> Rodrigo
>  
>  
> Em 08/09/2014, à(s) 12:19, Mitchell Evan <mtchllvn@gmail.com> escreveu:
> 
> 
> Rodrigo,
> 
> Please paste a bit of the HTML for context.
> 
> I'd like to know: Is the decorative image nested inside a clickable element, such as a link (A with HREF) or a button element?
> 
> Or is the image just plain content, inline or in a block?
> 
> The advice already given is technically good and correct. However I've seen occasions in Android TalkBack, swiping to read in document order (DOM order), when arriving at a hidden node doesn't skip the node, but instead causes the screen reader to be silent for one swipe.
> 
> This is worst when the hidden node is the first child node of a link, causing the reader to announce "link" with no content. This happens even when the hidden node is followed by text content inside the link.
> 
> This behavior I described appears to be a bug in the Android browser or TalkBack, so you might not want to code around it. But it would be good if we can find code examples to help document it, and I'm wondering if yours is one of those examples.
> 
> Cheers,
> Mitchell
> 
> Mitchell Evan
> mtchllvn@gmail.com
> @mitchellrevan
> 
> On Sep 8, 2014 7:29 AM, "Patrick H. Lauke" <redux@splintered.co.uk> wrote:
> On 08/09/2014 15:16, deborah.kaplan@suberic.net wrote:
> How does VoiceOver  decide the "flick right to go to the next element"
> order?
> 
> Source order, I believe.
> 
> I would have assumed it used tabindex.
> 
> >From what I remember testing a few months ago, VoiceOver/Safari (and other WebView browsers) and Talkback/Chrome completely ignore tabindex (for instance setting a specific tabindex > 0 order for elements has no effect in these situations).
> 
> P
> -- 
> Patrick H. Lauke
> 
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> 
Received on Tuesday, 9 September 2014 19:05:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:52 UTC