NES.css: 8-bit style CSS framework
bcrikko.github.io
bcrikko.github.io
1. "Focus ring" (focus indicator) is completely missing for buttons. I cannot navigate the site with my keyboard if I don't see the currently focused element. Never remove the outline for focusable elements without providing a sufficient alternative.
2. The focus ring for the form elements is insufficient, especially for input fields.
3. The green, blue and red buttons have insufficient contrast ratio. Use something like [0] to find accessible color combinations.
4. Only native components are used (button, input) - that's great! This way, almost no ARIA is needed. Adding role="alert" [1] to the balloons is the only one I'm missing.
5. The mobile layout is broken for inputs.
Unfortunately, many CSS frameworks either partially or fully ignore the accessibility aspect. It takes a lot of experience and time to make a website fully WCAG-compliant, but it's quite easy to follow some basic guidelines, like in this cheatsheet [2].
[0] https://contrast-ratio.com/
However, it was a fantastic learning experience, and integrating ARIA roles into my Mithril [0] components meant I only really had to implement some boilerplate once. It still took months of reading and I'm still far from an accessibility "expert" but I feel like a much better developer as a result.
It's seriously staggering how many steps backwards we've taken in terms of accessibility with the advent of modern frameworks, which is why I was very happy that integrating ARIA into Mithril was a cinch. A lot of this stuff is supposed to come for free with modern browsers but JS templating engines completely destroy the expected state of the document, with the most prominent and immediate examples being the lack of handling live updates, keyboard navigation, and forms correctly.
I fully agree on the first sentence. For the last < 2 years, I was really fortunate to work on a project which is required by law to comply with WCAG 2.0. I've learned a lot, so I'm trying to share my lessons learned whenever I can. From my point of view, I cannot fully agree with your second sentence. If you know the basic WCAG and ARIA principles, the WAI-ARIA Authoring Practices is a highly useful and clear resource for implementing custom components. However, using this document without any prior experience will lead to the rabbit hole you described. We can definitely do better here, and fortunately accessibility has been gaining traction in the last few years.
I updated my comment with a sample project with some very basic accessiblity and aria roles, if you feel like giving me some pointers or critique.
* The element with role button has aria-haspopup set to either menu or true.
* When the menu is displayed, the element with role button has aria-expanded set to true. When the menu is hidden, it is recommended that aria-expanded is not present. If aria-expanded is specified when the menu is hidden, it is set to false.
I'd also use a native "button" instead of "div role=button". It's cumbersome to (un)style buttons, but you lose a lot of built-in functionality with a custom component, which you need to care for.
[0] https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton
Nice catch on aria-haspopup! I totally missed that. Also good tip on aria-expanded, thank you.
I can't remember why I went with a div instead of a button. I'd like to think there was a reason, but it was probably just oversight on my part.
I appreciate your feedback!
I've done enterprise-level a11y projects for major brands, and the problem isn't always understanding the WCAG Success Criteria or WAI-ARIA, it's the _how_ that gets you. Multiple times, I literally had IBM's a11y practice and that of another major accessibility vendor (both of whom were hired for validation of approach and certification of the product coming from my team) disagreeing on which UX direction actually fulfilled the Success Criteria. The grey area of accessibility integration is _vast_ and in many cases, outright subjective.
Oftentimes folks believe that just because you plunked ARIA roles and other a11y-specific best practices into a framework or design system, it actually works out to be a11y-compliant. While it gets you closer to the endgame, the complexity of the actual User Experience (e.g., running it through screen readers and other assistive devices, and not relying solely on static analysis like aXe or pa11y) is where the magic (and pain) actually happens. Accessible responsive patterns, contrast ratios, UX metaphors, affordances, etc.; all of that is yet another level of abstraction that'll keep a team with work for a very long time.
(For those that really specialize in a11y to the point of becoming a consultant, though, it's a very lucrative career path for the above reasons.)
So many gotchas, so much boiler plate, plus it's not just React you're learning. You're learning React-Router, Flux/Redux plus half a dozen other tools each with their own verbose way of getting simple things done.
Not only can you start developing meaningful Mithril components within an hour of reading documentation, you can more or less become an expert in a week or two. The only things that ever snagged me for considerable time always turned out to be Chrome bugs.
And routing is so simple! I remember getting caught up for a while figuring out how to simplify authentication routing in React in a more DRY manner than what the docs recommended.
This is what I came up with using Mithril's built-in router. Dead simple, yet expressive, and it supports dynamic imports as well as decoupling the path name from the routing method:
https://github.com/soulofmischief/feathers-mithril-webpack-p...
https://github.com/soulofmischief/feathers-mithril-webpack-p...
https://github.com/soulofmischief/feathers-mithril-webpack-p...
I've been only working with NVDA so far. I highly recommend this NVDA Cheatsheet [3] to get a quick overview. It's also important to test NVDA with Firefox, as it has a better compatibility and thus it is the more common setup for users relying on a screen reader. Look into the difference between "Browse Mode" and "Focus Mode" (briefly explained in the cheatsheet) and how to switch between them. In the Focus Mode you can just tab through all of your focusable elements and check if the announced texts are understandable and no information is missing. In Browse Mode you go through all of the non-focusable content, and again, check if the output is clear and no (implicit) information is missing. This applies especially to all custom components which may announce gibberish if not handled correctly. Finally, you can look into my slides and examples for my "Accessible Web" talk [4].
[1] https://www.apple.com/de/accessibility/mac/vision/
[2] https://wiki.gnome.org/Projects/Orca
[3] https://dequeuniversity.com/screenreaders/nvda-keyboard-shor...
- view your site in lynx
- try and navigate around it with only your keyboard
- try navigating around it using your OS' screen reader[0] https://web.dev/
I always liked this.
Relevant: https://ell.stackexchange.com/questions/10624/is-sns-social-...
I actually just looked up what "office lady" means and yeah... I can't think of a lot of offices in the US that would have such a concept, especially not where it has to be a female employee doing those tasks. It'd be more common to say "personal assistant" or "office assistant".
Nintendo does not take kindly to even the most casual use of their trademarks, even in FOSS projects.
So a CSS-framework named NES should be OK.
They don't have to be right to send the letter.
There is also copyright in the design and layout of the NES interface, which has obviously been copied (it's the whole point of the project!), there's likely another option there.
I bet we're being super wasteful currently. Like REALLY super wasteful of screen space.
A couple of years ago I loaded up GEOS on a C=64 emulator, and was surprised how usable a GUI could be in 320x200. My watch has high resolution than that.
So yes, we are.
A ti-85 graphic calculator had 128x64 and was very usable (with training/practice, given the domain of application)
I spent a while figuring out the minimum number of pixels needed to play a game of solitaire. Unfortunately, this was years ago so I don't remember the number. But it seems like as good a benchmark as anything else.
Let's say you have 16 arrays with N values each, each having their own pointer to the current element. It starts out with everything zero. On each tick, you take the current value and put it in the current element of the first array, and increase the current element pointer. When you reach N, you reset the pointer to zero, take the average of all values in the array, and put that into the current element of the next array to the right, and so on.
Then you draw the current average of all elements in each array as a 1 pixel bar, color according to preference, and the result is that you have near real-time values to the left, and a rather long, if very rough history to the right. Depending on how many elements each array has, you can basically fit the current frame, second, minute, hour, day, week, month, year and more all in 16x16 pixels, especially since each array doesn't have to have the same number of elements.
We like the <i> tag for brevity and for the fact that most folks are using <em></em> for emphasized/italicized semantic text these days. If that’s not your cup of tea, using a <span> is more semantically correct.
https://fontawesome.com/how-to-use/on-the-web/referencing-ic...
This frees their use for other things.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i
> represents a range of text that is set off from the normal text for some reason. Some examples include technical terms, foreign language phrases, or fictional character thoughts. It is typically displayed in italic type.
Typically, but doesn't have to be. It's just about stuff that's set off, but not necessarily more or less important, "just different" I would say.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em
> marks text that has stress emphasis. can be nested, with each level of nesting indicating a greater degree of emphasis.
Oh, I did not know it can be nested. At any rate, emphasis doesn't have to be bold, it can be anything that gets emphasis across.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/b
> is used to draw the reader's attention to the element's contents, which are not otherwise granted special importance. [..] However, you should not use <b> for styling text; instead, you should use the CSS font-weight property to create boldface text, or the <strong> element to indicate that text is of special importance.
Okay, to be perfectly honest, I can't think of a good example for something I would want to draw attention to without considering it more important. Maybe the names of persons in a news story? Hmmm. I don't know, but notice making something blink is a perfect and sensible way to draw attention to it... so the blink tag never went away, it just got shorter, so we can use it more liberally.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/st...
> The HTML Strong Importance Element (<strong>) indicates that its contents have strong importance, seriousness, or urgency.
So basically, this means flashing text in various bright colors while changing size rapidly. I know how to read standards, so nobody even pretend it could be otherwise; let's just fix our websites accordingly. A "call to action" with a big green button is way too tame, if it doesn't trigger a primal survival reaction, you might lose the client.
Final fantasy was white on blue. As was Crystalis.
I suspect the reason it's not more common is the NES pallets sharing a color for color0. You can use black to indicate lines or shadow depth on basically all objects, whereas white is less universal.
Yet another reason why perhaps NES isn’t the best title.
https://en.wikipedia.org/wiki/List_of_video_game_console_pal...
Looks alright tho.