I am working in a automation project for android application. Any idea on how to click specific text in a set of words in a textView?
The textView contains "By purchasing such item. Please be aware that there are certain guide or rules we need to read in order for the user to handle the product. The following link are Product Guide. Once you read the product please check out the terms and agreement."
I need to click Product guide and terms and agreement link, but the link has no indicator. So as of now I am using the coordinates of the text and I am working on one device. When switching to other device, the coordinates of the link is changed.
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.)
This may be a very stupid question but i can't seem to figure out how i can edit / update a banner created in google adwords. The only thing I am able to do is click the "View full size display ad" link. Am I missing something or is it not possible to edit banners created in google adwords.
Yep you can edit them! :-)
When you are in AdWords click through your campaigns to view your ad groups, then click on the ad group you're interested in to see a list of ads contained in that ad group.
When you're looking at the list of ads in your ad group, by default you only see the "View full size display ad" link. When you hover your mouse over the ad though, a small pencil/pen icon will appear.
When you click on that pencil/pen icon you get to edit the ad (you'll get a warning about what happens when you edit the ad - make sure you read and understand the consequences before editing!)
since i am developing a project on Exchange trade fund and in its first page layout
we are developing labels and we want that on clicking on that labels page related to that
label may appear on another vertical field manager on the same screen and on that very screen i want page control so that on tracking wheel we may obtain the next page following that page
thanking you
You can capture trackwheel (e.g. trackwheelClick, trackwheelRoll) events and update the textual contents of the page appropriately.
Just implement these functions as a part of your mainscreen class.
The goal is to 'soften' hyperlinks off to external content slightly by displaying an external link bar at the top of the window, that displays above the content on the external website - containing a line of text that reads something along the lines of "The content you are viewing is not owned by this site, close this browser window to return to site name".
I know there's a way to achieve this using frames, but as far as I understand it frames are bad news for accessibility. Furthermore, if the user then accesses a site which itself has a frame set, there can be all sorts of fun and games!
Would welcome any feedback. Could something like this be achievable with jQuery perhaps?
No, you need to use frames. You need to have some degree of control, and the only way you can do that with remote addresses, is by keeping the user on your server, and showing the remote pages in a frame.
That being said, if the remote sites have a partnership with you, you could discuss a javascript option which displays a bar on the top of their pages whenever a specific cookie is set indicating the traffic came from your site initially.