|
Backend? ETLs?
There are no users.
|
|
|
|
|
I design for stupid people who spend half their work day with their faces in their phones.
Sometimes it appears that the reason there's so much impetus for Artificial Intelligence is there's too little Real Intelligence.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It's either that users here have never used the internet before, or don't want to take ownership and define how an application should look. Maybe both.
|
|
|
|
|
|
Design for accessibility is not limited to end users and physical differences.
Things like UI design and UX are not just for users. Writing reusable, and documented code helps the next developer and your future self for easier accessibility.
|
|
|
|
|
The tools that I write:
- Do not use sound
- Make very little use of colour - mostly success / warning / failure, but with differing shapes (e.g. success is a green tick, failure is a red X)
- Are used in a laboratory environment that would be difficult to remodel for use by the vision-impaired / blind
So why bother?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Some things you just do, because that's the way to do it. You drive on the right side of the road (which may be the left side in some countries) even if you are alone on the road. You get out of bed even in the weekend and you have no other plans.
In programming, you do a few things even if you don't "have to". Like in a Linux style CLI application, you handle the -v command line option even if you know which version you have installed, and --help listing all the command words (or whatever). Any "proper" Linux CLI application has these elements.
I can imagine a discipline of programming where it would be equally self-evident that you prepare for users with disabilities, even if you don't know of any specific case right now. Even for internal tools, you might next week have a new colleague who can't make use of all the internal tools, because they miss the universal access adaptations.
No Linux programmer writes from scratch a command processor for handling -v and --help; there are libraries for that. There are libraries for creating Windows Help pages as well. To make universal access universal, we would need tools at a similar level for creating UA user interfaces. Then we could teach and enforce a discipline where UA adaptations is as obvious as a command processor for parsing the --help option.
I am sure that many examples of such libraries & tools exist, but they are not being universally promoted. They are not being taught as a basic element of UI design and development. If they were, "We see no need for UA" would be like saying "We see no need for processing the backspace key".
|
|
|
|
|
I think that it is reasonable to say that a programmer who is writing an application with a user interface, that is to be used by anyone other than him/herself, should establish a habit of considering whether (s)he should make provision for accessibility by individuals with disabilities. However, if the application, by virtue of its known 'context' will not, in fact, be used by such individuals, the considerable extra time and effort that would be needed to build in such provision cannot be justified on any rational grounds. I disagree, also, that provision for disabilities is something that can be included as simply as adding a library and some text to handle -v or --help. To do it properly requires that the relevant issues be considered throughout the design and coding process.
|
|
|
|
|
Neither do I but...
Making things easy for use, reduces mistakes.
|
|
|
|
|
Far too many times have I seen developers claim that they design for accessibility, but without having a clue about how to do it. More or less of the kind: "If this text is too small to read, press this button to enlarge it", in dozen varieties.
Lots of developers have read checklists of how to design for this and that disability. When they sit down at their keyboards, they (vaguely) remember twelve of the twentyfour rules, implement the six that cost next to zero, and proclaim "We have made a serious effort".
The checklist should have had a second column, next to the "Do you design for...", to check "...and we regularly (e.g. for every major release) use people that actually have these disabilities as testers, to verify that the software actually works fine for them". If the developers were truly honest, that would reduce the percentage of those really designing for disabilities to a fraction.
There is a middle-between: You can do some testing yourself, simulating vision problems by smearing vaseline on your glasses, or covering the screen with a big board that has only a small hole that you can move sideways or up and down (tunnel vision), or turn off the screen (total darkness). You can get hold of a braille line - verifying that it shows the right text makes you feel like a first grader leaning his first letter! You can turn down the color saturation to grayscale as a (poor) simulation of color blindness. Use heavy gloves, or mittens, for keyboard input. Turn off the sound, or select e.g. sewage pipe acoustics on your sound card. ...
But few developers do even such testing. The better of them keep the list of twentyfour points to remember handy, and may actually use them as a checklist before release. Yet, for the great majority, it is plain theoretical work, never tested in practice. Compare it to making a major release of source code that has never been passed through a compiler before the release date.
Developers of software specifically aimed at a disabled group are of course different - they have testes with the disabilities in question. I am talking about developers who make software for the general market, with disabled users only as a small fragment of the user group.
|
|
|
|
|
Quote: they have testes
We do, we do. 
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Color blindness and for high contrast, being the top two.
|
|
|
|
|
Do you employ testers who are actually visually impaired to verify the usability before every major release, or are you just working through a checklist?
|
|
|
|
|
We use QA testers that use tools such as: WAVE and Siteimprove Accessibility Checker, etc. and we work off of test cases.
We also have been doing this a while now, and have a feel for what really works and doesn't work, based on feedback from users with visual impairments.
WAVE and Siteimprove are software tools that are based on official standards. They hook into the Chrome browser nicely, but WAVE I believe has a standalone package too. See: WAVE Web Accessibility Tool[^]
|
|
|
|
|
I wasn't aware of this tool - thanks a lot for the link.
It certainly looks as if you are doing things properly. So don't take my general critical comments to the way developers handle accessibility as aimed at you. Quite to the contrary: They could learn something from you!
|
|
|
|
|
So why bother?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I guess a lot of user access this software, but indirect with other layers of software.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I certainly hope that no blind or deaf man ever drives a car or pilots a plane. It works in comedies but in RL...
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
But higher software layer may do the job for providing some interface for it. Maybe the obvious Siri or Alexa may execute some commands for your ECU firmware. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
especially red/green as these signal colors are widely used.
we never design any red/green display (success/fail) without icons and/or describing text.
I often see apps that have a running progress bar and when finished the bar turns red or green with the text "completed". this is a problem for color blind people.
we try to avoid such things.
|
|
|
|
|
We do the red/green colour change thing but only with additional text cues for those who have difficulty with red/green - sometimes it is a different shaped icon altogether such as a red X vs a green tick/check mark.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
