I'm currently evaluating a lot of CSS frameworks on how accessible they are (for an upcoming blog post), so I'd like to give it a go:
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].
I went down the ARIA rabbit hole this year. Christ almighty. It's understandable why anyone who isn't specifically specialized in this fucks it up. The documentation is arcane, redundant and lots of it is inapplicable.
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.
> It's understandable why anyone who isn't specifically specialized in this fucks it up. The documentation is arcane, redundant and lots of it is inapplicable.
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.
The thing is, the WAI-ARIA page works well as a reference, but not as an onboarding process. You have to develop your ARIA chops elsewhere and then come back to the document to learn the finer points of each role. And roughly half of the document will never be useful, and slightly more of it is overshadowed with native HTML5 tags.
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.
Is there a live component showcase for your project? Just from the source code I see some requirements [0] not being followed:
* 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.
Not right now because I'm in the middle of integrating ansible into my servers and was waiting to get that finished, and I also need to make some changes with local storage.
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 would like to second this in some sense. I would love to learn more about WAI-ARIA, but have no idea how to go about doing so. More non-reference documentation would be fantastic, or surfacing whatever does exist better.
I definitely know this pain (and glory) from experience and can relate. It all began when Ontario started enforcing AODA and the brand I was working with at the time had to be compliant due to their business operating in the province despite primarily being a U.S. company.
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:
I've been considering evaluating the accessibility of my sites and I would like to see the impact of the changes I make with WAI-ARIA. Can I do this with a screen reader and are there FOSS or built-in screen readers you can recommend I test with?
There are free and built-in screen readers: NVDA[0] (Windows), VoiceOver[1] (Apple) and Orca[2] (Linux).
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].
Accessibility is one place where you'll invariably be forced to pay at some point because the 800lb gorilla of screenreaders (JAWS) is also what's used most often in both home and in most corporate environments.
Also worth mentioning that Chrome has a built-in stripped-down screen reader in the developer tools which will display and allow you to navigate through your elements. It's worked well enough for me.
For low hanging fruits I would recommend using Lighthouse, which is integrated into Chrome (DevTools → Audit). That's what web.dev is also using [0]. Under the hood "axe-core" is being used. Another option is pa11y [1]. All three tools offer CI integration, but you still have to do some work to fully automate it. If you're using React / JSX, there is also an eslint plugin available [2].
My intuition was clear, it's made from a Japanese company! While the style is of course inspired on old Japanese games, the clear clue was "SNS" (confirmed by visiting the company link). If the authors are here, this is an example of wasei eigo not used at all in international English, like "salary man" or "office lady".
I've never heard anyone in the US saying "office lady" and to be honest if I did hear that I would think it's being used in a derogatory fashion.
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".
Relevant is the scope ("Goods And Services"), which seems to be:
"Downloadable multimedia files, namely, video games; downloadable electronic game programs; downloadable electronic game software; electronic game programs; electronic game software; video game programs; video game software"
In this case the focus is pretty clear on games/computer programs ("multimedia files, namely, video games").
But agreed, it probably would not be worth it to stand against a giant as small dev/company for a fun project.
I think even if it wasn't trademarked, they'd likely look into Passing Off (or whatever equivalent laws are present in the country they would decide to proceed with legal action is available), given the exact same name and style of a Nintendo product is being used.
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.
There is no “NES interface”. It’s all just code written by each individual dev team, using assets created by their art teams. I don’t really think there’s anything that actually exists that could legally be called “the NES interface” when it comes to design rights
This kind of thing makes me wonder just how small (in terms of pixel count) a UI could be, while still being as intuitive as necessary and as complete as necessary to accomplish its goals.
I bet we're being super wasteful currently. Like REALLY super wasteful of screen space.
Even today I'm surprised that I was able to enjoy playing Sim City on an IBM PC Convertible's 640x200 monochrome non-backlit low-refresh LCD screen.
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.
One of my early cell phones (AMPS days) had a solitaire game, and it fascinated me that solitaire could be played in such a small screen.
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.
I once modified a traybar icon thingy to display download rates in a 16x16 pixel area, and I'm quite proud of what I came up with, though I'm sure this is a "thing", it just has to be -- if anyone knows "the official name" for this concept I would be very grateful:
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.
It's CSS-only, so works just fine with NoScript. That's kind of unexpected, compared to other modern web frameworks. Though using <i> tag for icons feels weird.
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.
> 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.
> 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.
> 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.
Sounds like you’re referring to Foundation and/or FontAwesome? Even though Foundation requires JS for some features, you can definitely use the CSS version only, even to get advanced features like the x-y grid.
This would be cool to be paired up with a site using a Konami code. Do the code ("Up Up Down Down Left Right Left Right B A Select Start"), and it changes your stylesheet to use this. Hahah Would be fun!
Author needs to redo the demo page in black on white. That will be much more in line with NES styles.. I can't think of any NES UI with black text on white background.
Shadowgate and the other MacVenture games were black text on a white or beige background but they were originally Mac games so that explains the design.
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.
Firefox on Android @ 1440p also does this. I'd say it is because they are using svg for the images and the "pixels" are each separate rects. Just a guess, cannot look at the source rn.
Fascinating! As a joke, I wrote a similar CSS stylesheet recently that simulated the look and feel of a greenscreen mainframe app, complete with bright green text and blocky containers (I spent maybe all of an hour on it over a few days of tinkering). I added it as an style option in a web app that was supposed to replace a legacy system and the customer absolutely loved it. Unfortunately I had to explain it was a joke.
At least the checkboxes and radio buttons could use some user-select: none. Currently a mouse click is enough to trigger accidental selection on Chrome.
Mixed pixel scaling and incorrectly offset items make this seem a little cheap and doesn't really give me the NES feel. Colours are also not necessarily so well picked either. Meh...
I’m not sure it is a toxic comment. The site looks bad in portrait, but it looks good in landscape. I only thought to rotate my phone after reading the comments. It certainly seems constructive to point out when something doesn’t look or feel right to you. Maybe it was only tested on a desktop?
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/
[1] https://www.w3.org/TR/wai-aria-practices-1.1/#alert
[2] https://moritzgiessmann.de/accessibility-cheatsheet/