lichess-org
Made "Learn from your mistakes" accessable in the NVUI.
Made "Learn from your mistakes" accessible in the NVUI.
I also made the tags that function as
Screen readers have trouble with tags controlled via js.
If the button element rendering is not desired, it can be fixed with css.
(A image of the Computer analysis before learn from your mistakes)
(A image of the Computer analysis post learn from your mistakes)
edit: https://github.com/lichess-org/lila/issues/17621
how it renders in typical ui
I am not offended by it, but can change it if requested.
a lot of unnecessary structure and remnants from the visual ui remain in the pasted nvui snabbdom. element classes for visual styling should be avoided here, and flatten the element structure when possible.
Yes, I am guilty of not really understanding snapdom, or what makes a good nvui.
When I return from camp I will give it another look.
Thanks for your time
no sweat. when you get back to it, take a look at the nvuiInsertHook function. i'm not sure why focus would be called there when el was the keydown/click event target. under normal conditions that would indicate el === document.activeElement. but i left it in case you were seeing something weird with screen readers and that was the fix. who knows with nvui.
Yes, the screen reader was focusing the top of the screen. When you toggled learn from your mistakes.
It was the a fix for that.
i think this was happening because you were first drawing the button in analyse.nvui.ts, and then you were having retroView draw it. so the original element disappeared and thus the focus changed. it might be safe to remove the focus call now.
I do not think the screen reader cares at all about javascript, right? It should only care about the rendered html, at least that is my understanding of the technology.
I will give it a try in the am. Good night.
I do not think the screen reader cares at all about javascript, right? It should only care about the rendered html
javascript is rendering the html.
Yes, I understand that.
But what I mean is that the rendering of the html should have referential transparency, no?
The rendering should not have any side effects, in my thoughts.
:. It should not matter what function renders the html.
I don't know if my assumption about the lack of side effects is true.
It should not matter what function renders the html.
you need to learn about snabbdom
long story short, it only creates new elements when it has to. like when the html structure changes, such as ~~a different class on a button or~~ a slightly different ancestor hierarchy.
when that happens, the old element is removed from the dom and the new ones are patched in. if a removed element had focus, then focus is reset. if it's still in the DOM then it will retain focus.
Edit: adding/removing a class will not trigger removal
Ok, I think I understand. I will work on it after I take a nap.
Are there any resources you can recommend for me to fix my understanding?
Thanks a bunch, sorry for assuming. You know what they say...
I had no understanding that the js was adjusting the elements in focus. So rendering does not have rt.
referential transparency is not a common expectation in front end land. javascript/html/css behavior is about as far from pure functional programming as one can get.
with snabbdom, every time we call redraw, we re-render the entire page as lightweight VNodes (short for virtual nodes) that correspond to the real DOM (which is expensive to modify). snabbdom then diffs the two and tries to do the absolute minimum to bring the real DOM into sync. if a property of a VNode changes, usually those changes can be carried over to the corresponding DOM element as modifications. but certain attributes, properties, and any ancestry change will cause removals and new elements to be patched into the DOM.
Thanks, I will try not to assume things work a certain way without justification. I want to have heading elements in my buttons but want the click events to bubble up. I want the headings due to screen reader users navigating by them. I will work on this tomorrow. GN.
you've changed a lot of things that aren't related to your feature. there's a lot of new assertives, asides, and <label>s have become headings now. i'm not sure how that will play, but is this in a state yet where ikrami1 can go over it? i can put it up on a test server that has a longer lifetime than gitpod.
you've changed a lot of things that aren't related to your feature. there's a lot of new assertives, asides, and
That was done in my possibly misguided attempt to ""improve"" the html to be more semantic.
If it is unwanted, I can quite easily change.
If is ready for testing by screen reader users. Thank you for your help, it is appreciated.
The label to heading is done to increase usability via screen reader. ikrami1 stated people often navigate via heading when using a screen reader. I started doing this in my testing, and found it quite useful. labels do not have a corresponding functionality in screen readers to my knowledge. That was my reasoning.
As for this PR I do not like the unorganized state. I would like to close and figure out how to organize and open a new pr.
This one is still useful for the discussion. etc.
The current state of nvui-learn-from-your-mistakes is ready for testing. I am sorry for my disorganization. If there are any changes ie: div -> aside that you would lika me to change, I would be happy to.
I tried to cleanup, with no avail. I integrated changes into my "wip" tree.