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>
Related
I'm looking for any specific guidelines (from Apple or elsewhere - not opinions) on how much text I should make VoiceOver read when I tap on some text in the app I'm developing.
When I tap on a header, should it read only the header, or should it also read the section below that header? When I tap on a paragraph, should it read the header and then the entire section that contains this paragraph? In what situations should the spoken text provide more or different information than is actually displayed by the app?
(I'm not asking what it does, I'm asking what it should do, because as a developer I can set an item's accessibilityLabel to as much or as little text as I want.)
I don't see anything relevant in https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/iPhoneAccessibility/Making_Application_Accessible/Making_Application_Accessible.html#//apple_ref/doc/uid/TP40008785-CH102-SW5.
Your link seems clear enough, especially the section on Supply Accurate and Helpful Attribute Information which includes, among other details, the following:
A good way to determine what a label should convey is to think about what a sighted user infers about your application just by looking at it. If you’ve designed a good user interface, sighted users should know what a control or view does in the current application context by reading its title or understanding its icon. This is the information you need to make available to VoiceOver users in the label attribute.
If you provide a custom control or view, or if you display a custom icon in a standard control or view, you need to provide a label that:
Very briefly describes the element. Ideally, the label consists of a single word, such as Add, Play, Delete, Search, Favorites, or Volume.
Strive to design your application so that a single word identifies an element and makes its usage obvious in the current context. Sometimes, however, it might be necessary to use a brief phrase to properly identify an element. When this is the case, create a very short phrase, such as “Play music,” “Add name,” or “Add to event.”
Does not include the type of the control or view. The type information is contained in the traits attribute of the element and should never be repeated in the label.
For example, if you include the control type in the label of an Add button, VoiceOver users hear “Add button button” every time they access that control. This experience would quickly become annoying and might motivate users to stop using your application.
Begins with a capitalized word. This helps VoiceOver read the label with the appropriate inflection.
Does not end with a period. The label is not a sentence and therefore should not end with a period.
Is localized. Be sure to make your application available to as wide an audience as possible by localizing all strings, including accessibility attribute strings. In general, VoiceOver speaks in the language that the user specifies in International settings.
Each tappable view should provide its own accessibilityLabel. If a user can tap on the header and the user can tap on the section below the header, then tapping on the header should just read the header and tapping on the section below the header should just read the section below the header.
When you think about accessibility, you should be approaching it from the perspective of your end user. For example, if you have a heading entitled Hospital Name: with a subheading reading Massachusetts General Hospital, it would be a good idea to read the two together because they provide context for one another. If, on the other hand, you have a header entitled Hospitals: and then you have a long list of hospitals below, it would likely be better to allow the user to scroll through all of the hospitals at his/her own pace.
With larger blocks of text such as a paragraph on a UILabel or UITextView, the amount you read again depends on the context. If it is a description of something that should be read as a solid block without interruptions so the user can understand the content, then it is completely fine to set it as a single Voice Over block. If, however, there should be strategic pauses to allow the user to decide if he or she wants to hear more (e.g. End User License Agreement, paragraphs in an essay), then you should separate it into sections to allow the user to control the pace and select the location.
With larger blocks of text, I would recommend that you do not set the accessibilityLabel to the contents but rather the accessibilityValue. This will allow the user to hear a short description in the label of the object in the accessibility focus prior to deciding if he/she wants to hear more. Again, this gives the user context prior to continuing.
You're developing a native app and not an html webapp? In the latter case, the user can swipe left/right to navigate to the next element in the DOM and only the text that is associated with that DOM element is read. However, the text associated with the DOM element can be "enhanced" by associating additional text with the DOM element (aria-label, aria-labelledby, aria-describedby, class="sr-only", etc), if it's deemed necessary to help a VoiceOver user understand the context. For example, a "register now" button or "read more" link might need additional information so that the purpose of the button/link is clear. (Register for what now? Read more about what?)
The same principle can be applied to native apps too, which sounds like what you're asking about. If your app has a heading (ala <h1>, <h2>, etc, but however it's defined in objectivec), then those shouldn't need additional text associated with them. The heading should be worded so that it's context should be sufficient. The paragraph following the heading can be navigated to by the user swiping right. They'll know the paragraph is "under" the heading because it's the next element they swiped to.
Same if the user taps on the paragraph. The heading associated with the paragraph does not need to be read. The user can swipe left to get to it, or they can use the rotor set on "headings" to swipe up/down to get to the prev/next heading.
So the general guideline is to try to provide all the context that is needed in the text of the object itself, if possible. But you also have to balance that with succinctness. If the text needs additional context, then it sounds like you should use accessibilityLabel. Is there another attribute that provides additional information such as accessibilityDescription? (I just made that attribute name up. Not sure if it exists.)
jQuery mobile 1.2 alpha introduces Popups while it already has a similar widget, called Dialogs. They both seem very similar in nature.
What are the technical differences between Popups and Dialogs?
What Popups can do (any practical usecase as example preferred) that is impossible with Dialogs?
They are quite different beast. Here is my opinion based on my limited experience.
Dialogues
Dialogues take over the page, they contain a fullscreen dark background to make the "dialog" appear to have replaced the page.
Any page can be presented as a dialog by adding the data-rel="dialog" attribute to the page anchor link.
Like pages, you can specify any page transition you want on the dialog by adding the data-transition attribute to the link.
Can be chained.
Popups
Displays within the current page, and are probably more similar to the functionality commonly referred to as modals or lightboxes.
Can't be chained.
Popups are probably more suited for alerts, tooltips, small yes/no ok/cancel messages, making a thumbnail popup into a larger image, small ajax forms(newsletter, login, post a comment) etc. Useful when you don't want to overload the page with information, and only want to reveal certain functionality to users when they need or request it.
Dialogues on the other hand could be used in situations where you need to convey a lot of information (terms and conditions acceptance screen, etc), or when you really want to emphasis an alert, menu, the choice a user has, etc. Dialogues kind of break the flow of a page so should be used more cautiously.
One neat feature of the popups is that they can be used as overlay panels, which could be used to create a menu that slides in from the side of the screen, not too dissimilar to the menu in the Facebooks iphone application.
At the end of the day, either could be used, and neither is right or wrong, a lot of it comes down to personal preference, and how you want your application to flow.
One important difference is Popups appear in the same page as an element, where as dialogue is a different page in all and the background is blank.
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.
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.
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.