We Keep Coding

RN accessibility on Android - order of how TalkBack reads through View

I am trying to use accessibility features in RN and have few questions. How would I get rid of green box in UI, without disabling TalkBack. And the second is - how to enforce the order in which screen reader reads through the elements of view that is composed from several components? At the moment I manipulate state depending on certain parameters and pass it to attributes: accessibilityLabel, accessibilityHint, importantForAccessibility to accomplish that. Is there a better way to do it?
Here is an example:
this.setState(function(){
if(<some condition>){
return{
accessibilityLabel: "press right to move to other item",
importantForAccessibility: "yes"
}
}else{
return {
accessibilityLabel: "something else",
importantForAccessibility: "no-hide-descendants"
}
}
)}
and then
render(){
return(
<View
accessibilityLabel=
{this.state.accessibilityLabel}
importantForAccessibility=
{this.state.importantForAccessibility}
/>
)
}

How would I get rid of green box in UI, without disabling TalkBack.
The green box is part of Talkback. It's an important feature which makes it clear where the screen reader's cursor is; useful for a variety of disablities including partial sightedness, dyslexia, memory impairments, and attention difficulties.
As a user, it can't be turned off as far as I know. (I have Android Accessibility Suite version 7.2 on Android 8.0). Some screen readers on other platforms offer user preferences to customize the appearance though.
As a developer you can't turn it off either - it's part of Talkback, not the application. This is a good thing; it's the user's assistive technology, not the developer's. Even if a developer could turn off the screen reader's visual cursor, they shouldn't. (It would be like styling a web page with * { cursor: none !important; } - mouse users wouldn't thank you for that!)
how to enforce the order in which screen reader reads through the elements of view that is composed from several components?
When using web browsers, screen readers read web pages in the DOM order, so the general principle which applies to web pages is to make the visual order match the DOM order. (Aside: this is also important for sighted keyboard users, because a tabbing order which differs from the visual order can be very confusing.)
I'm not so familiar with React-native applications, but I would imagine a similar thing applies. You should structure the application's content and controls in a meaningful order. If the application has several regions, mark these up in a way that allows the user to skip to a particular region (with headings, ARIA landmark roles, or possibly other grouping containers). Be aware that screen reader users are not necessarily blind, so the point about visual order and DOM order is important.
It's worth clarifying whether you mean enforcing the "reading order" of the entire application (say, while a user explores the application UI just to see what's there); versus managing focus in response to a particular user action inside a particular widget (like a date picker). Since React-native uses JS, I'd recommend reading ARIA - Managing Focus to see if this applies to your situation.

How to force mac screenreader to automatically read heading text in a div?

So I have a SPA angular 1.5 app and when the user navigates to a new page sometimes the page doesn't have any inputs that are autofocused, for example it is just a congratulations page saying the user was successful in registering. I've been able to come up with a slightly hacky solution by doing
$('.registration-confirmation').attr("tabIndex", 0).focus();
so the screenreader automatically reads out the text in the registration confirmation div, but then I also had to prevent the blue outline in the css from the focus
.registration-confirmation {
&:focus {
outline: 0; // remove webkit injected outline on focus
}
}
Is there a simpler way to do this? with maybe aria attributes?

Yeah, stop doing it like that - not good accessibility at all, especially since you've now confused me by messing with the focus indicator. ARIA roles are the correct way to handle this:
If you're trying to report an error, this should get ARIA role="alert", which will immediately get announced by the screen reader and is invasive so should not be used liberally.
For success reporting or other progress, you can use ARIA role="status"; however, still don't abuse it. If the user jumps to a successful registration screen with next steps, for example, applying it to anything but a simple "congratulations" would be inappropriate.
I suggest looking at the ARIA best practices document for various example uses.

JavaScript onKeyDown and Jaws Screenreader - Not working together

I cannot get JavaScript onKeyDown for keyboard keys 1,2,3,4,5,and 6 to work with Jaws Screenreader. Specifically, I have an html document that is automatically generated with links in it. The links are related in different ways (e.g., a series of links related to dogs, and another set of links related to cats). I want the user to be able to switch between the series of links they're navigating through simply by switching the key they are pressing down. This currently works, but not for users of Jaws Screenreader. For them, nothing happens when they press down on the keys.
Other notes: the keyDown event needs to be able to occur anywhere in the document, so it's not isolated to a small area within the document (e.g., a form or a drop-down menu).
Is there a relatively straightforward solution to allow JAWS screenreader users to press different keys to switch between modes? Any help is greatly appreciated!

Are you exiting the normal browsing mode in which 1-6 and other keys are set to jump to various elements? For example 1-6 jump to headings. If not, press INSERT+Space first.
I'm assuming this is an action where someone holds down 1 and then perhaps arrows through dog-related links, or holds down 2 for cat-related links? If so, it seems to me there's probably a more usable and accessible way to implement this. In general, there has to be a really good reason for me to want to learn your site's keyboard shortcuts, especially if I can do the task with approximately the same number of strokes with screen reader native commands.

bootstrap - how to replicate a Iphone "Scroll Wheel"?

I don't know that Scroll Wheel is the right name for what I want, but I'll try to explain it.
On my I phone there are text boxes I can click on. Once you click on that box, you are presented with a scrollable list of items, for example numbers 1-10.
When you choose the number 1-10, either that value is placed in the text box and the list view is closed or you can "submit" that choice.
Is it possible to replicate this scrolling list of preset values in bootstrap? Ideally I want to have a list of times to choose from (1:00-1:30, 1:30-2:00) that an end user can scroll through on their phone and make a decision.

The answer to your question
Like others have mentioned in the comments, this is just how iOS renders <select> elements. Different browsers will render this differently, i.e. Android browsers come up with a slightly more conventional list, and desktop browsers will render it as a standard drop down list (albeit styled to fit with their UI, which can be frustrating).
Other things to be aware of
Bear in mind that if you try and override the default select elements with a plugin such as Chosen you will lose the various browsers default rendering of these elements, which can be one hell of a headache. There is also currently no easy way to detect whether your browser will render a select in a special way (such as the iOS style spinner) or use a dropdown, so its not like you can use something like Modernizr to apply your select plugin only when you're not using iOS/Android. If you want to do that you're in the murky world of user agent sniffing. (If anyone wants to correct me on this please do!)
Further reading
As a bit of an aside make sure you check out the new HTML5 input types. These provide things like native datepickers with no need for plugins (if the browser supports it) and many other types that have varying degrees of usefulness. For example, the type="tel" input is a nice one, that will render a normal text box in most desktop browsers, but on most phones/tablets/devices with virtual keyboards it will bring up a dial pad style keyboard, making it much easier for the suer to type in a phone number and giving them a strong indication of what you want. Just something that is very much worth thinking about if you are making forms for mobile and desktop, as it can make the mobile experience much more fluid. Browsers that don't support these elements will continue to render as they normally do as well, which is doubly nice. You can also use the likes of Modernizr to detect whether any of these input types are available to you, and do things differently. For example we have used Modernizr to detect if there is a native datepicker available, if there is, we just leave our <input type="datepicker/> alone, but if there is no datapicker we load in the jQuery datepicker, therefore making sure everyone has a datepicker.
This might be all obvious stuff to some of you but since this question had been pretty much answered in the comments I thought it would be useful to include some extra information about input types and different browsers rendering. If anyone wants to expand on my answer or correct anything (I'll be the first to admit to not being a complete expert on these things) please feel free.

Determine the 'Overtype' mode using Javascript

We are creating a web app to replace an old-school green-screen application. In the green-screen app, as the user presses the Insert key to switch between overtype and insert modes, the cursor changes to indicate which input mode the user is currently in. In IE (which is the official browser of the company), overtype mode also works, but there's no visual indication as to whether overtype mode is on or not, until the user starts typing and possibly over-writes existing information unexpectedly. I'd like to put some sort of visual indicator on the screen if in overtype mode.
How can you determine if the browser is in 'overtype mode' from Javascript?
Is there some property or function i can query to determine if the browser is in overtype mode? Even an IE-specific solution would be helpful, since our corporate policy dictates the browser to use as IE7 (pure torture, btw).
(I do know that one solution is to do check for key presses of the Insert key. However, it's a solution that I'd prefer to avoid since that method seems a bit flaky & error-prone because I can't guarantee what mode the user would be in BEFORE he/she hits my page. )
The reasoning behind this question:
The functionality of this portion of the green-screen app is such that the user can select from a list of 'preformatted bodies of text'.
crude eg.
The excess for this policy is: $xxxxxx and max limit is:$xxxxxx
Date of policy is: xx/xx/xxxx and expires : xx/xx/xxxx
Some other irrelevant text
After selecting this 'preformatted text', the user would then use overtype to replace the x's with actual values, without disturbing the alignment of the rest of the text.
(To be clear, they can still edit any part of the 'preformatted text' if they so wished. It's just that usually, they just wish to replace specific portions of the text. Keeping the alignment is important since these sections of text can end up on printed documents.)
Of course, the same effect can be achieved by just selecting the x's to replace first, but it would be helpful (with respect to easing the transition to the web app) to allow old methods of doing things to continue to work, while still allowing 'web methods' to be used by the more tech-savvy users.
Essentially, we're trying to make the initial transition from the green-screen app to the web app be as seemless as possible to minimise the resistance from the long-time green-screeners.

In IE you can use document.queryCommandValue("OverWrite").
For IE only:
function isOverwriteEnabled() {
try {
// try the MSIE way
return document.queryCommandValue("OverWrite");
} catch (ex) {
// not MSIE => not supported
return false;
}
}
Firefox, Chrome, and Safari:
Because Mac does not have nor support the "insert" key, Safari will never ever support "insert" mode.
For Chrome and Firefox, "insert" mode is not encouraged for support as Mac does not have it. (Also, see "Furthermore")
That also means, since Windows supports "insert" mode, that IE will more than likely always support it.
Furthermore:
Firefox has a bug report classified as "WontFix" for years, so the "Insert" key will probably never be supported.

The problem is that if the user presses the insert key after entering your page then you can track down it easily.
But when the user has already pressed the insert key before entering your page then it seems to be a difficult task.

I suggest careful consideration of the 'overtype' feature. Does this behavior make sense in the web context, at all?
What utility does the 'overtype' feature provides in the old ANSI presentation which is unavailable through the web?
Unless I'm fully misunderstanding your question (apologies if so), I feel like the development intent may not align well with user expectations and typical web conventions.
If the goal is to produce a page where:
by default 'insert' mode is disabled
user can trigger 'insert mode' for editing purposes
...then why not use dynamic form inputs?
When a user clicks on a particular segment of HTML, a JavaScript is used to present the content as an element whose default value matches the chosen HTML tag.
Once editing is completed the input is parsed, the page updated, and form input removed from display.
Would this method suit your needs?