I'm aware of how to make invisible elements keyboard focusable and read by screenreaders, however for the purpose of a student-led survey - I would like certain elements to be invisible to screenreaders / keyboard focus to be less distracting, but have them visible for tutors to use using a mouse.
I've tried using iframes, however the keyboard can still 'tab' into them. I was considering a pop-up window that can control the parent window? - but might have some issues with blockers etc.
Many thanks! Mike
One of the simplest ways to get content ignored by a screen reader is to place it into an image and then set the alt text on the image to be "" in your HTML. This will cause the screen reader to skip this content since it can't interpret it. This will also eliminate any tabbing or keyboard focus since the web browser will treat it like any other image in your page.
Another way to do this, and a bit more complicated, is to detect if your page is being pulled into a screen reading browser and set the CSS properties of the content you don't want read by the reader to be have the following:
visibility: hidden; display:none;
Screen readers will ignore anything that is invisible and/or not displaying, thus it will not be read to the user. This is also a bit cleaner since you're not destroying the SEO ranking of the page but are just modifying the content displayed to users who don't need to see/hear it.
a good way to prevent screen readers from viewing an element is to apply the aria-hidden="true" attribute; this is fairly well supported by browsers, and will prompt JAWS and other screen readers to skip the content. You can also use role="presentation" - there's a good article on this here: http://john.foliot.ca/aria-hidden/
Applying tabindex=-1 will only only allow the element to be focused on by scripts and not keyboard input, so this will work too. Additionally, although I don't recommend it, I found while tearing my hair out over someone else's script, that if you don't have an 'href' attribute defined for a link element, (making it invalid) this also prevents focus.
Related
In one of our native iPad apps, there's a screen divided into a number of sections. For the most part, I think it works well with VoiceOver. But one of those sections is a UIWebView that displays web content related to the app, but provided by another vendor. It's essentially a black box to us. So I have no control over what that content is (or how accessible it is), it's incredibly dense with little nuggets of content, and it's on the left side of the screen, so it comes before a lot of the other content in (English) reading order.
As a consequence, if I ask VoiceOver to read through the contents of the screen, it quickly gets bogged down in this web content, and I can't imagine many people sticking it out to the remainder of the screen. But making them give up and scrub the screen to discover things seems obnoxious.
What I would love to be able to do would be to have the read-through treat that whole region as a single unit and use a summary label or heading, but still allow the user to point into it or toggle it somehow to allow interaction with the web content. Is there any way to accomplish this on iOS (without completely confusing the accessibility system)?
Of course, I'm sighted, so I'm also acting on speculation to some extent. Would the current UI be as confusing to users relying on VoiceOver as I think? Is what I'm describing as my solution going to be an even worse situation?
aria-hidden="true" would make a screen reader ignore the whole content (if this screen reader is modern enough to take into account WAI-ARIA. VoiceOver is).
That isn't what you're trying to achieve I guess, and most of the time it isn't desirable: why would screen reader users not able to read the same content as others, who are you to decide for them what they can/can't read that other people can't/can? Except in known cases of complete inaccessibility like a keyboard trap and this keyboard trap can't be fixed for now
a skip link before this content would allow SR users to jump to the content that is after this section.
if relevant, known ARIA landmark roles would allow to choose which part of the page they want to read (it would need this section to be the whole sidebar - complementary role - or the main one. Probably not the case)
SR can navigate through headings (as well as links and sequential reading and now landmark roles).
If this section and the next one begin with good headings, then it can be bypassed quickly.
Relevant WCAG 2.0 Techniques:
Providing heading elements at the beginning of each section of content (H69)
Providing descriptive headings (G130)
Using h1-h6 to identify headings (H42)
Organizing a page using headings (G141)
If there's no heading element and it can't be modified, but there's some text that could've been a relevant heading except it's a paragraph or item list or whatever, it could be marked as an equivalent with ARIA by using role="heading" and aria-level="N" (see role="heading")
if you've a good reason to modify the natural reading order of columns (I think this is the case here), you can modify layout with floats and flexible box layout (IE10+) (latter has had 3 different syntax throught the years, plugins like autoprefixer are welcome, or SASS/Compass...). Your left column would then appear last when tabbing but that requires modifying the layout of maybe a lot of templates.
aria-describedBy can probably be useful in some way but I've not enough knowledge about its uses, maybe somebody else will know more about it.
From comments Sixteen said:
Unfortunately, like I said, I don't have any control over that content at all. It comes from elsewhere, and is being displayed by our app
I agree with Felipe. I don't know what your code looks like, but say this in basic HTML. You probably either embed the code with an iframe, or inject the content into your code (example PHP include()).
Regardless on the method you use, you probably wrap a <div> around it. So you could do
<div aria-hidden="true">
//iframe/inject here
</div>
to make it not be seen by AT. Taking this basic model, we could pull out aria-hidden="true" and replace with role="complementary". You could put text in the div, push it off screen and say a nice line, and same for aria-described by, but you may want to tack on tabindex to it. Ex:
<div aria-describedby="ex" tabindex="-1">
<p id="ex" class="offscreen">Below is useless jargon by blah blah blah. It may
be more beneficial to jump to the main section instead.</p>
//iframe/inject here
</div>
Background/Context:
I am developing touch screen based kiosk application with JavaFX. The app integrates browser – WebView. The problem is that all user inputs have to be made through on screen keyboard (SW keyboard)
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
Even though I searched the Internet, I did not find this kind of feature.
My questions:
Does JavaFX / WebView provides any support for these cases?
If you were to tackle this problem, what would be your approach to that?
My solution so far:
I have a small button (at one corner of the screen) that allows user to show/hide on-screen-keyboard. Since they have to do that manually, it is quite annoying. Especially on sites where browsing (consuming information) and text inputs changes frequently.
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
A potential strategy for doing this:
Start with a jdk8 preview.
Run the application with -Dcom.sun.javafx.isEmbedded=true to enable the virtual keyboard.
Use a webengine.executeScript technique to embed jQuery into the target page.
Bind a jQuery focus handler to the relevant html elements.
In the jQuery focus handler make an Upcall from JavaScript to Java.
Upon receiving the upcall make use of JavaFX's Virtual Keyboard.
As the user enters values into the keyboard, make executeScript calls to set the value of the corresponding html field.
Some parts will likely be a bit (or totally) flaky, but perhaps other parts may prove useful to you.
In the future, if WebView is supported on touchscreen platforms on embedded devices, I'm guessing that out of the box it will work well with a virtual keyboard.
I am trying to get a inputtext area and a submit button attached just to the right of it.
Ideally, the two together will use 100% of the width and be just side by side.
I have been trying to play around with ui-grid-a and similar options but everything fails miserably. You can see some attemps there. They are all equally ugly but the most complicated thing is to get the two elements side by side with one that has a fixed width (the button) and one that should take the rest of the width (hence neither fixed nor a percentage).
Do you have any idea how to render this properly?
In a dream world jQuery would have some built-in function to group those controls (just like <fieldset data-role="controlgroup" data-type="horizontal" data-role="fieldcontain"> for grouping checkboxes. But it does not seem so.
Thanks a lot for your help,
Mad
Hidden within jQuery Mobile's own documentation I found an approach that worked just fine for my search box + search button implementation.
In that page, they are comparing things side-by-side by using a simple <table> layout which inspired me to rely on this as well. While tables are NOT the go-to resource for doing layout/design well, it is extremely effective, simple, and circumvents many of the hassles of the workarounds I'm seeing here. Here is what my approach can do for your jsfiddle you linked. See the fourth iteration.
In other words, due to the complicated nature of how jQuery Mobile builds a page, adds in divs and styling that aren't in your markup, etc., this might be your best option for this particular scenario:
Wanting two columns of items where the second column is a fixed width.
Where the first column expands to fill the width of the screen on resize.
Where you want the elements to encompass the whole width of the device.
(Notably, if you wanted to tweak any of these particular aspects, some simple CSS padding or aligning should do the trick starting with this base solution)
<table style='width:100%'><tr>
<td>
<input type='text' (or type='search') />
</td>
<td style='font-size:80%; width:7em'>
<input type='submit' value='Submit' />
</td>
</tr></table>
Obviously, you should name and give an id to these items if you want to post them somewhere or manipulate them in javascript. Hopefully this proves helpful to someone else who is not put off by the nature of <table>s. I have been unable to see a downside to this approach using jQuery Mobile's simple interface / theming.
Lastly, you may want to stop and ask yourself if a submit button is even necessary. In mobile devices such as mobile safari, there is a button on the keyboard labeled "Go" whenever form input elements are being interacted with. This operates the same as a return key and can submit the search term. I have not vetted this option on other browsers at this time.
(This is not a solution to rival your approach to shift the icon of the search box. That is very clever but doesn't seem to be what your original question was about.)
I found a new answer for those of you that are looking at this thread.
I find it much better in terms of integration with jQuery Mobile. However, it could be vulnerable to upgrades in jQuery Mobile since it relies on how the icon image file is organized.
I simply added this CSS rule :
.ui-icon-searchfield:after {background-position: -252px !important;}
And the icon magically turns into a data-icon="check". Exactly what I was looking for! You can pick whatever icon you want by changing the offset and looking into images/icons-18-white.png for the icon mapping.
Of course you will want to refine the selector so you only target the input boxes you want to change.
Enjoy the hack.
the way I solved this problem was to float the input box next to the button, then have pagebeforeshow set the size of the input box to window width minus the size of the button.
After a fruitful discussion with adamdehaven, it turns out that:
A validate button is most of the time unnecessary and against the logic of mobile applications. It is better to use <input type="search" /> for such problems
The framework does not allow to customize the icon for type="search" content.
To make for the latter, I put together an ugly hack that you can see there. Unless you zoom in quite a lot you won't see a difference with the regular type="search" besides the darker grey. However, I suspect this solution could be vulnerable to minor changes to the framework in the future.
Another solution would be to directly pull out the icon and manually overimpose an home made icon button over the input. It should be slightly more robust (because at least the button would not be based on the framework) but requires a few quick photoshop changes to pull out the icon and put it in a propper file.
As we all know, iPad do not support the <frame> element, but both Gmail and Ymail could do something similar by creating a 2pane style , and the navi pane (left one) could scroll (in ipad style). May I ask if anyone do have the idea how it created?
Thank you very much.
I don't actually know for sure how they've done it (I can't seem to reach mobile gmail in a desktop browser, and I can't find a view-source feature on my iPad) but I suspect that it's not as complicated as it looks.
Keep in mind that in a regular browser, when there is too much content we get a scrollbar. That's not how the iPad renders long pages. On the iPad, if there is too much content we never get a scrollbar, scrolling is achieved by sliding the content up and down. So what we should imagine is that this is two panes with scrollbars, because that's how it would show up in a normal browser.
From there, it's a much simpler problem. It's probably just two divs floated in a standard two-column layout, each with their overflow set to scroll. Something super-basic, like:
<div>
{the nav list of emails goes here}
</div>
<div>
{the currently-open email goes here}
</div>
<style>
div {
float: left;
width: 50%;
overflow-y: scroll;
}
</style>
There's probably something fancy in there to make each div consume 100% of the available height (it's probably not as simple as height: 100%) but already if either div contains enough content, we'll get individual vertical scrollbars which the iPad will hide, giving us that neat sliding-scroll gesture instead.
I've tested a few of my own apps which were build back in time with Frames. They all worked "normally" are you sure you didnt use the wrong Doctype for your HTML?
Individual block elements with overflow-y:scroll are only scrollable with two fingers on the iPad. That's just the way it is.
So how does Gmail do it differently? Manually, with JavaScript, reacting to various touch events.
Your best bet at the moment is to use iScroll. This used to be a bit un-smooth (compared to Gmail and others' implementations), but the latest version is really good. Try their demo.
It works on iPad/iPhone, Android, and you can even use it in a normal browser using your mouse. It has the nice elastic effect when you reach the top/bottom of a scrollable area, and it has the iOS-style scroll indicator thing that appears on the right during a scroll. It's almost as smooth as scrolling on a native app.
By the way, if you want to examine an iPad-specific website's source, the easiest way is using Safari (I've tried this on 5.0.3 for Mac, but probably works on other platforms too). Turn on the Develop menu (Safari>Preferences>Advanced), then you can set your User Agent to iPad.
You can do the same thing in Firefox, posing as an iPad, but I often find the websites look completely broken. I think this is because many iPad/Android-specific websites rely on Webkit features that aren't present in Gecko. In fact, Apple's iPad guide site, which also uses a two-pane scrolling technique, simply rejects you if you're not (a) sending an iOS User Agent string and (b) using Webkit. And Chrome doesn't have an easy way to change your User Agent string. So Safari is the easiest way to examine these kind of sites.
I hate default select control, that's because it can't be styled in IE using CSS.
This is why I developed a new select control from scratch, using HTML + CSS + JavaScript.
I did a great job in the past two days matching CSS and HTML together, but today I discovered a bug wich looks very hard for me to fix.
In IE 7, when I have tow controls on the same page, the one from top does not overlay the one from bottom.
See the image: coolrgb dot com/files/select-help.jpg
Download the demo page (HTML + CSS + Javascript): coolrgb dot com/files/select-help.zip
Please help me, this control looks so nice for me and I want to use it on all my projects from now on. This bug killed my hopes and lot of time.
Thank you.
If you give each control the same z-index, then you will not have control over the stacking order.
I would suggest modifying your control to behave more like a real SELECT element: only one can be open at a time, or losing focus causes it to close. Alternately, you can set a high z-index when the control has focus, and a lower one when it does not.
Another thing to look out for: try putting some other controls like radio, checkbox, and select under your control. You might find that IE also will not hover over those even if you give them a different z-index (as #grawity explained in his answer). This is why you'll typically see widget demos displayed on top of these elements, as shown here: http://jqueryui.com/demos/dialog/
A typical hack to fix this is to use an iframe, but that probably deserves a different question altogether.
Edit: After rereading the question, this answer now seems totally unrelated, but I'm keeping it here anyway.
Not really an answer, but an attempt to explain:
In Internet Explorer, <select> tags are implemented as simple windowed controls, while all other elements are windowless controls (this allows them to be styled). That's why these tags are always on top and don't follow the z-order rules. (The drop-down menu part must be styleable so it's a windowless control, and so it shows under the main part.)
In Firefox all elements are windowless, and in IE8 they should be too.