[4.0] Outline none is evil #27636
[4.0] Outline none is evil #27636
Conversation
|
@brianteeman Please provide testing instructions. A link to an article does not provide the instructions. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/27636. |
|
@jwaisner - Focus on any link. There should be an outline |
|
hmm... I am not seeing a change when focusing on any part of the frontend or backend. |
|
@brianteeman please don't provide a pr without clear testing instructions. |
|
I don't believe this is the proper "fix", this simply changes one problem for another. |
|
Can you not read the code? It's obvious where this applies |
Sure can. Perhaps you should follow the C.O.C. |
|
And blocked. Comment on code not on people |
|
Blocked? What or who is blocked? |
Good question... taking this to team chat.. |
|
We have rules for how to make a PR, @brianteeman can you please add the missing information. |
|
@brianteeman I'm failing on this to what the heck is the "warning_page" the css reverences, sure I can search and find it out but a hint would be great. And by the way, 2.4.7 WCAG 2.0 talks about "focus indicator" not necessary outline, so if someone can style something more consistent (each browser shows the outline different) and maybe not too aggressive like the monster glow around the element, I would appreciate that but can life with outline too ;-) |
|
description updated. I guess I was incorrect in assuming people knew the code base |
|
@infograf768 Blocked in the same way as I was blocked in last year. Troy now can't comment any of Brian's PRs. So Brian keeps a JBS member from doing his work. |
|
I had no idea I could block anyone from my PRs... |
|
BTW, |
|
@infograf768 No idea how that works with blocking. I never had the intention to do so. Is against the spirit of a community project in my opinion. And blocking a JBS member is in my opinion sabotage even. |
|
@infograf768 I onyl see it here and in the installation template but maybe I missed it. At a basic level as long as you are not removing it from focus you should be ok. its just bad practice to blindly set it as it is too easy to either not set the focus indicator or for it to be removed later without realising the consequences.. Its a minor issue in a minor page - not worth the time being spent on it. |
|
My grep shows there are 149 occurences of |
|
@richard67 that is absolutely not what a block on github does when a user blocks another user |
|
not wasting any more time on this - sorry for caring about accessibility |
|
@richard67
|
|
@infograf768 Am just curious now if I could block myself ;-) |
|
@wilsonge - irerspective of this being closed, please merge. Outlines should not be set to 0 |
|
@C-Lodder |
|
Have they been set to 0 in other places? |
|
@brianteeman If you block someone, that person can't comment or review or even test your PRs. Like you did with me in last year. |
|
Blocking a JBS member means keeping a JBS member from doing JBS work. |
|
Merged with 64b9025 |
|
Thanks @wilsonge @richard67 not true |
|
@brianteeman What's not true? That you blocked me last year? Or that it kept me from commenting and testing your PRs? I don't wanna argue, just am asking in order to understand what you mean. In my case it was like that in last year. |
|
|
|
Above screenshot from Troy. Was same for me last year. Issue tracker also failed to pass test result because that tries to add a comment on GitHub. |
|
@brianteeman Maybe you didn't know that blocking has the consequence shown in the screenshot in my 2nd last post? |
|
I can only go by the description provided by github which would not suggest that would happen |
|
@brianteeman Then the description is not complete. Believe me it was like this for me, too, in last year. |
|
If you want and if there is a way to unblock a user immediately again, we can test later. I could block you, then you could check the result, then i could unblock you again after some 1 hour or so, and then you could give feedback. What was funny to me was that on a mobile browser this message telling that commenting is impossible wasn't shown, and buttons were not deactivated. I did not want to try in last year if that would have worked on mobile client because I thought it could make you more angry on me. But on desktop it was like shown on the screenshot. |
|
https://medium.com/better-programming/a11y-never-remove-the-outlines-ee4efc7a9968
The build process 'Creates the error pages for unsupported PHP version & incomplete environment
The generated version of the files live in /templates/system
Look at the inline css in the generated files and you will see outline:0
outline:0 should never be used as it is a massive accessibility break. We are committed to providing an accessible experience with joomla 4 and this must include our error pages.
Apply the pr
Run the build scripts
either npm -i or node build.js --build-pages
check the generated files ans see that the inline css no longer includes outline:0
Irrespective of if you can observe the outline or not setting it to zero should always be avoided.