As the title says, I accidentally clicked "Hide messages from {x}", though I don't know what x was, specifically. I was getting a React warning/error
"Warning: MyForm is changing an uncontrolled input of type text to be controlled. Input elements should not switch from uncontrolled to controlled (or vice versa). Decide between using a controlled or uncontrolled input element for the lifetime of the component"
I accidentally right clicked on that message and hid it(it's the top option on right click). Below is what that looked like(but with a different item that I'm definitely not clicking).
I've been through all the "how to unhide chrome console quests/answers I can find, and none of them have worked to get this message back.
I've tried:
clicking the "Default Levels drop down" and selecting every single option there.
tried every combination of those yellow check boxes
tried hitting F1 clicking "Restore defaults and reload"
clearing the text in the "Filtered" input box
restarted server
restarted chrome
It appears there used to be a right click option to "unhide all", but that was removed by chrome in 2018
As you can see there is still that 1 hidden (but crucial) React message, and once you accidentally hide it, it seems there is no way to get it back.
This is pretty much a showstopper for me, since it means I can't see React errors at all in Chrome. Please help!
Thanks,
Richard
You just have to clear the filter section in the chrome console (see image attached). This should bring you back to square one.
Related
I had implemented a dropdown select in my react/mui app using the Select component; however, there were often several thousand options to choose from and implementing react-window in Select turned out to be a nightmare. So I plumped instead to use Autocomplete.
However my client has complained that all of the options need to be available, even if an option has already been chosen — that is, if there is text in the input. Which is expected behaviour, of course, since it is an autocomplete.
So I have been wrestling for the last several hours to display all of the options, even if there is text in the input, trying lots of different things:
looking for some prop option to display all the options, not just those that match. Doesn't seem to exist
trying to clear the text input when it is focussed. Tried several methods of doing this, such as:
listening to open and clearing the text field itself
manually clicking the "clear" button on open. This is a problem because the open state of the dropdown changes and it really isn't very reliable to determine if it is open or not, and should be re-opened
Anyone had this problem?
I have a sign in form that when given incorrect credentials an error message pops up. I want this error message to be focused when loaded, that way the user can easily hear the message and then tab down to the fields. I am having trouble identifying the best solution to implement.
aria-live works perfectly in reading the error, but I would like if the error message also focused. What is best practice to read and focus the error message? Would it be to add a ref?
I'm not sure why you'd like to focus the error message since it's read out loud, it should be enough. Also it might be confusing to force focus, maybe the user is in the middle of something else - which is the benefit of using an aria-live "polite" value for instance. Additionally using both aria-live & auto focus may result in reading the error message twice, but this needs to be tested.
This being said, to focus a DOM element you need to use a ref. Create it with useRef and assign it to the element. If the element to focus is rather a React component, you might need forwardRef. If the element is non-focusable (like a div, a span or a paragraph) you will have to add a tabIndex={-1}. Call ref.current.focus() when you need to.
Using a negative value for tabIndex will make them temporarily focusable & will not break the natural focus order of the page.
Sources :
https://developer.mozilla.org/fr/docs/Web/HTML/Global_attributes/tabindex
https://reactjs.org/docs/hooks-reference.html#useref
https://reactjs.org/docs/react-api.html#reactforwardref
Any idea why NVDA reads clickable word when tabbing through text in html example:
<h1 tabindex="1"> testing </h1>
NVDA will read clickable testing
In first place remember that tabindex are not a good practice in a11y, and also headers don't need a tabindex NVDA provides a header navigation with the H key. About the clickable I can say from my experience is a known issue for NVDA, if you check that in other SR (Voice over or Chromebox) should be read properly
Short answer:
the tabindex attribute implies functionality to some screenreaders.
Long answer:
Two primary ways that a screen reader user will navigate your webpage are by skipping through interactive elements or by headings. Interactive elements are things like links, buttons, form fields and any other piece of functionality that the user will initiate on your page. These are navigated by using the 'tab' key.
The other primary way they will navigate your page is by headings. In fact, a survey from webaim lists headings overwhelmingly as the primary method of navigating a page to find information (source). In your example, you have given the heading a tabindex which will give the impression that it has some functionality or interactivity to it. To my understanding, both JAWS and NVDA will read out 'clickable' on elements that have a tabindex, as they could easily (and typically would) have some javascript click handlers that are not evident from the screenreader.
Answer:
It's because of attribute tabindex which makes this element keyboard focusable. One can focus it by pressing TAB key on a keyboard.
Hint #1: Attribute tabindex with value above 0 should be generally avoided!
Don't use tabindex="1", tabindex="2" and so on. Only tabindex="0" or tabindex="-1" can be useful in some cases. Otherwise you can create a complete mess for a user experience.
Read more:
Google: Using a tabindex greater than 0 is considered an anti-pattern.
WebAIM (accessibility): This is almost always a bad idea.
MDN: Avoid using tabindex values greater than 0.
Hint #2: Generally no need to make focusable elements that a user cannot interact with.
As in specific case no sense to make a heading element keyboard focusable if a user cannot interact with it.
If you are concerned about screen reader users have no worries as they read non focusable content just fine. A quote from Accessibility Developer Guide: As opposed to keyboard only users, screen reader users usually do not use the Tab key to read a page! Read the "Screen readers browse and focus modes" to know the difference between navigation using Arrow keys and Tab key.
But... Exception to the rule exists
Exception to the rule exists and it's probably a good idea in cases where developers set tabindex="-1" to headings which they want the focus to be moved programmatically for the purpose of accessibility. Such cases are for example fresh content update with AJAX in single page applications. The focus would be moved to a heading for a user to get aware of the content update and to be able to start from there. Also it can be useful when currently focused content is about to get removed from the DOM (a.g. deleting currently focused table entry) or moving a focus to an error summary heading after a form submit trial etc.
In my case (VoiceOver on MacOS), it seems that H1 is announced as clickable only on Firefox. On Chrome, it's announced correctly.
This leads me to believe it's a Firefox bug.
I've got a simple A tag:
Link Text
Every now and again IE gets confused the the link stops working. When the mouse hovering over the link, its a normal cursor, on mouse-down it changes to 'not-allowed' and on mouse-up nothing happens.
I can refresh the page and it works normal again for awhile, then it just stops working again.
How can I determine what is happening and fix it? There is no console output, there is script or events on the A tag or any of its parents. IE just borks.
This is an Angular application if it matters at all.
For clarification, I don't want any pointer changes at all, I don't want the link to randomly stop working. I just want the A tag to behave as normal. It does so in all browsers except IE.
I have reduced the length and width of IE browser window. The app loads properly for the first time. Now I have a form which opens on the click of a button on my Homepage. In the form, if I leave a field invalid and I click on save, the code is written such that if there is any field invalid, it will focus on the invalid field. So, with IE10 browser window small, when I leave a field in this form invalid and click on save, the whole app shifts towards left inlcuding the form and the fields inside the form. I have no clue why this is happening. I am using the following code to focus on the invalid field,
child.getEl().dom.scrollIntoView();
I am aware that there is some bug with scrollIntoView when using IE browser. Can someone suggest me the alternative to scrollIntoView()? Thanks in advance!
Used the foloowing instead of scrollIntoView(),
1) field.getEl().focus() to focus on invalid field
2) panel.body.el.scrollTo('Top',0,true) to scroll the form to the top every time we open it