Michel Fortin is a Mac developer who writes about his apps, such as Sim Daltonism and Black Light, and about Swift and Markdown.
Commenters recommend Sim Daltonism for testing designs for color blindness and Black Light for screen color filters; his PHP Markdown also comes up.
There are so many great tools out there now. Lighthouse in Chrome Devtools has an Access audit built in which will give you a few hints. There's also a very useful auditor that just came out from Paciello Group called the Arc toolkit: https://www.paciellogroup.com/toolkit/. Chromevox and Voiceover can be turned on to get quick screenreader-ish feedback.
No Coffee: https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl is quite useful to get a non-scientific empathy hit for graphic decisions and how that interacts with common sight problems (98% of people by age 51 have presbyopia) and Sim Daltonism: https://michelf.ca/projects/sim-daltonism/ will give you a more accurate representation of all the most common colour blindnesses (1 in 12 men).
I also urge everyone to turn ON tabbing on their Mac (System Preferences > Keyboard > Shortcuts tab > All Controls) and tab into their sites (unplug your mouse). I also often do a run through with Vimium: https://vimium.github.io/ which gives me some aspects of a voice interaction type system.
These tools will get you some of the way there, though there are established ways to build components which will solve 90% of all known access problems. The main solution is simply to write native HTML. A major issue is how hard it is to style native form elements (like datalist) -- it means developers can't get it past design/clients.
I had the exact same issue and spent a lot of time figuring out why this was a problem for me, as I would alter between my old 15 inch and new 16 inch and feel the difference each time.
Long story short, I found a solution that removed all my issues;
- Use the accessibility «contrast» feature set to level 2
- Use an app[0] that applies a gamme filter to adjust the white level down to account for the contrast increase
- (optional) use an srgb color profile that disables temporal dithering of colors
This reduces you max brightness level to the same amount as the old 15 inch (I don’t need the extra brightness) but allowes you to keep the backlight at max output, minimizing the pvm strobing effect[0] that some people seem to be sensitive to.
[0] https://michelf.ca/projects/gamma-control/
[1] https://osxdaily.com/2021/05/14/workaround-pwm-oled-iphone-ipad/
> there is no movement to tighten the bolts on Markdown
Oh but there was one, and it was desperately needed!
Gruber's original implementation was absolutely riddled with logical inconsistencies, outright bugs, and even an escaping vulnerability that was exploited by an XSS worm to self-replicate on Reddit.
This project originally started as a PHP transliteration of Gruber's pile of regexes, and it's early version history is a nice summary of all the warts as they were discovered (and never fixed upstream): http://michelf.ca/projects/php-markdown/classic/#version-history
There are markdown parsers available for PHP (http://michelf.ca/projects/php-markdown/ as an example), but the websocket thing might be quite challenging. PHP's architecture doesn't lend itself well for many concurrent long-running connections.
Unless you want to run out of RAM very quickly, you are much better off to do everything involving long-running connections using node.js or any other environment that works in an event based fashion as threads (and in case of most safe PHP architectures, usually processes) are way too expensive for that.
Adding to the list of suggestions by other commenters, Sim Daltonism:
http://michelf.ca/projects/sim-daltonism/
I remember using it for a university project in 2007, in which we had to build a movie lookup website from scratch. I used Sim Daltonism to design 3 alternative CSS that would cater to the needs of people with different types of colorblindness (there's not just one type, although deuteranomaly (red/green colorblindness) is the most widespread).
The teacher thought it was superfluous and took points off. sigh :)
Kudos!
I am always glad to see more accessibility in software.
For regular (non-disabled user base) apps, it’s quite possible to make apps accessible, but it’s something that should be planned from the beginning (same with localization).
I do it with almost all my apps. Pretty simple, if you integrate it from the start.
One tool that I always suggest, is Sim Daltonism[0]. It’s a great way to ensure that we don’t rely on color alone, as a UI feedback axis.
[0] https://michelf.ca/projects/sim-daltonism/