When in the iOS settings I activate the "Bold Text" in "General -> Accessibility", some texts get cropped because they become larger and thus exceed their intended display area.
Also, if I enlarge all the texts in "Accessibility -> Large Text", suddenly, my app becomes completely unusable because everything is cropped in all directions, the texts take a lot of space.
However, when I enable these settings and go to applications like TikTok, Wishbones, ... I notice that they don't seem to be affected by these system changes.
Having no time to set everything up now to make my application respond to these settings, I was wondering how those applications do to "ignore" those settings?
Preword
I think this is a valid question and I welcome questions like the above as that is partly how I got into accessibility (trying to work around an accessibility error instead of fixing it), but the below 'rant' will probably explain why you got the downvotes.
I also explain a way that you could fix your problem going forward in the section titled 'Proper use of allowFontScaling = false;' so I hope that is helpful to you / others.
Why should you never do as OP asked.
For anyone who stumbles across this question in the future, please read the following before doing the above.
I understand deadlines are deadlines and sometimes you need to push the product live, and if the above is purely to get your Minimal Viable Product to market as a short term fix then go for it, you have to be realistic about your goals and if accessibility wasn't on your radar until the last second then the fix may take too long, but make it priority before stage 2.
However, experience tells me that if you follow the example of TikTok, a company who deliberately suppresses disabled users videos, you have chosen a very bad role model. (I cannot comment on Wishbone as never seen it)
Now never mind the moral reasons of excluding people and disabling a feature they may require to use your App, instead let's talk numbers and lawsuits and see if we can't persuade you to add some time into the development budget to fix this.
Market Size
Globally, at least 2.2 billion people have a vision impairment or
blindness, of whom at least 1 billion have a vision impairment that
could have been prevented or has yet to be addressed.
Source: World Health Organisation (WHO)
With a world population of 7.8 Billion, that means that up to 28% of your user base could require larger text in order to see your App clearly. (The numbers seen high the WHO published but who am I to argue with them!)
If you are disabling font scaling the odds are you also haven't considered the size of tap targets, icons, screen readers etc. so your app is probably completely useless to someone who is blind or partially sighted, as well as people who have accuracy issues (tap target size, often influenced by font-size) such as people with Parkinson's Disease or Cerebral Palsy.
Excluding a quarter of the world's population does not seem like a good idea if you want an App to grow, unless of course you are building the next TikTok and have a good marketing budget to reach the other 75% of the population.
If this is the case then ignore accessibility, unless the law in your country leaves you open to a legal nightmare.....
Legal
Oh this one is going to be the biggest commercial reason to do this, large companies are getting battered by lawsuits in America where their websites aren't accessible, Apps are not going to be far behind.
Now I am not sure which country you are from, but depending on where you live you may actually find that your App is breaking the law.
I myself am from the UK and although the risk of a lawsuit is much lower here I am aware of at least two lawsuits being put together on behalf of people with disabilities against companies whose websites are inaccessible to blind people. We are following America and I have no doubt others will too.
Oh and legislation is in progress for the whole of Europe called the European Accessibility Act, so every EU country will have the same laws soon.
It isn't just people with disabilities.
I work on a 43" monitor positioned about a meter away. Now if Windows decided they would stop font-scaling I would have to completely change my setup as the font size would be too small and i would not be able to read anything.
I have no vision impairment, but the accessibility features built into Windows, web browsers, applications etc. really allow me to work the way I want to.
If I am on a train I often switch accessibility features on to make tap targets bigger so I can press them accurately when the train is buffeting around, contrast better (for glare from the sun so I can see the screen better) etc.
Tried the new 'dark theme' yet? Dark themes started for people who have issues with screen brightness and contrast perception problems. See that thing in front of you that you write on, typewriters / keyboards were invented for blind people and I cannot imagine a world without my keyboard.
Accessibility = a better experience for everyone = happier customers / users = better reviews and recommendations = more customers = more profits = more development work for us devs = everybody wins.
Proper use of allowFontScaling = false;
allowFontScaling = false; is a very useful thing to add to your toolbelt.
As OP has discovered sometimes a layout does not work when someone changes the font size in their system settings.
Obviously you should design your layout to accommodate larger text, but this will often ruin a pretty design if it hasn't been considered from the start.
Educating your design team takes time so it is often left to us as developers to fix these problems until company policy changes (which is easy to do if you point out the legal implications, directors tend to wake up when you mention multi-million pound lawsuits and a larger audience!)
Instead if you encounter the same problem as OP and there is no way to fix your layout you could do the following and still comply with WCAG 2.1 and offer your users a feature they may require to comfortably use your App / Website.
Disable automatic font scaling as suggested in the answer given.
Add an accessibility settings section to your App / Website.
Add an option to control font size, font weight etc. there
If the font size / weight is adjusted to a size that does not work with your 'default' layout, enable a secondary layout that will accommodate this font size / weight. Allow up to 200% font scaling in this secondary layout (it can actually be quite fun trying to accommodate such large fonts on a small screen - requires some creativity!)
While the secondary layout may not be as nice it does at least mean that people can use your Website / App if they require a larger font size / heavier font weight. It increases your potential customer base and helps you comply with relevant laws.
Conclusion
Put accessibility on your roadmap today.
If you build into your design process you won't have to resort to terrible ideas like disabling font scaling, ignoring accessibility errors etc. It will also save you a lot of effort later trying to reverse-engineer your App / Website in order to accommodate features that people need.
If you are near the end of development like OP, add it to your development plans as a priority item going forward to increase the number of potential users of your App and to avoid legal issues.
/End Rant
I hope it helps at least one person see the benefits of accessibility.
One thing you can do is to disable font scaling for Text like below which will make sure that your font size is not affected by Accessibility changes.
Text.defaultProps = Text.defaultProps || {};
Text.defaultProps.allowFontScaling = false;
Related
We are creating a big project that will live and be improved for approximately 10 years.
Already in our code base, there is a lot of code for specific browser incompatibilities, workarounds for different bugs in browsers, 3rd party tools and libraries and so on. The code itself usually works fine, but in time, it will become harder to debug, read and refactor.
Is there some standard way to manage the issues and remove the code once it is not needed?
Ideas that come to my mind:
Manually maintain a table of workarounds with links to issues -> instructions how to remove them. Possibly with some metadata.
Set up a task that will create low priority entry in the company issue tracking system if:
Status changes on the Github issue page.
Browser usage drops below a threshold (to identify workarounds that are no longer necessary).
Code coverage detects that the "if branch" is no longer visited.
The issue was not revisited in a long time.
Generally speaking, opening a defect for every (significant) piece of technical debt is a good idea. A product owner can prioritize them based on the other priorities in the backlog.
There are two important aspects to add:
Make sure that technical debt defects are integral part of the backlog grooming process;
Make sure that you establish an information radiator that allows the programme steering committee understand the importance of removing those technical debts. What is the penalty, in terms of added cost, decreased efficiency, increased risk, etc. that they are stacking up because of all these shortcuts?
Technical Debt needs a steering committe. In programmes of such size, Enterprise Architecture normally chairs that.
I need machine-readable descriptions for Multi-Monitor and VR Setups, like simple dual-screen computers, Powerwalls, and Caves. This description must include the sizes and placements of all outputs (displays or projections) in the physical space.
The far goal is to combine User-(Head)-tracking, device tracking for mobile devices, etc. with multi-display environments.
The simplest issue is to be aware of the gap between the screens of a multi-monitor setup because of the borders of the display cases.
The most complex setup would probably be caves with polygonal or curved projection surfaces.
My impression is that every VR-Software out there defines it's own setup-config-crackpot-text-file-format. Is there a common standard or common practice I am missing?
There are no common standards in VR (yet) especially the type you take interest in, but you might want to check out vrui.
The author of that project understands the need for middle software that would do what you want to do: http://doc-ok.org/?p=123. He also has a great article where he considers that for VR the standard camera model could be changed with great benefits, in a way similar to what you seem to ask for in your question: http://doc-ok.org/?p=27
Maybe, once VR gets some popularity and traction thanks to Oculus and all, a need for standaristaion will rise - there already is one for HMDs, check out the OSVR project. But I dont really see it very probable - CAVEs and Powerwall setups won't be so widespread due to costs involved and space required. Using HMDs will probably be a lot cheaper and more portable/handy.
EDIT: I also found this - http://www.middlevr.com/
I am testing an application and need to test it with different screen resolutions with windows form applications.
What is the common resolution tested for now days?
That depends a great deal on your market/target audience.
I think your safe minimum 1024x768 for desktop apps but don't forget that mini PCs are taking off and they have smaller screens than traditional. If you're gonna run on one of these you need to consider "funkier" resolutions as well.
As far as maximum resolutions... the sky's the limit. Though i think if you look good in 1280x1024 you'll be fine in anything larger too.
This will depend on how the Windows forms is laid out, in relation to aspect size and resolution, the fonts used. Before when I developed WinForms applications, I used to rigidly stick to the minimum size of resolution 640 x 480, knowing and having the confidence that it will be fine in resolutions higher then that.
Sadly as it seems, it would make the form look a tad small when under a resolution such as 1,024 x 768!
This is something you need to be aware of.
Another angle of looking at is this - internationalization, yes that flaming international lingo for each label, this could disrupt the flow and layout of the winform itself, suppose you used a label that had a common word such as:
+-----------+
|First name |
+-----------+
Now, suppose this was translated to German (via babelfish.yahoo.com) for an example that label would be
+--------+
|Vorname |
+--------+
Wait! It gets smaller in Spanish (again via babelfish.yahoo.com)
+-------+
|Nombre |
+-------+
Yes, the label has shrunk and the end result, there could be potential gaps or labels flowing into one another because of the internationalization.
Sure, is'nt it great that we all have big fancy screens with resolutions up to 1,920 x 1,0768, on flat 24" screens, but even more so, the readability of the winforms can vary as well depending on whether ClearType is used or not! Even netbooks have a resolution of 1,024 x 600...
This is an interesting question that can underhandedly open up a can of worms as to BEWARE! Ok, I know I made it sound like as if internationalization was the big point behind it, you just do not know until you ask yourself and your superiors, who is the audience and what scope?
You will also earn bonus points if you target accessibility as well, big fonts, small fonts, how are the fields laid out, there is no hard or fast rules involved in this, it would be beneficial to do a small amount of research. Sure, it would be darn handy to drop on a component that will automatically resize the layout of the form scaling upwards for different resolutions, but what about the potential for internationalization...?
Good question worthy of a +1 from me!
That depends entirely on your application. For the last kiosk application I coded, the resolution was part of the specification, and was set to 1280x1024. If you're making a game, you'll need to support a wide range of resolutions, both fullscreen and windowed.
You will also want to take aspect ratio's into account (ie: wide vs. normal, etc.).
I usually design my windows forms, so that when you resize the form, everything resizes correctly. This usually means setting a reasonable minimum size for the form. I find that this works better than designing for 1 specific resolution.
Web users:
http://www.w3schools.com/browsers/browsers_display.asp
http://www.screen-resolution.com/common-screen-resolutions.php
See Google Browser Size.
Edited to add: That labs feature may be going away, to be added to Google Analytics.
The question
Is there a known benchmark or theoretical substantiation on the optimal (rendering speed wise) image size?
A little background
The problem is as follows: I have a collection of very large images, thousands of pixels wide in each dimension. These should be presented to the user and manipulated somehow. In order to improve performance of my web app, I need to slice them. And here is where my question arises: what should be the dimensions of these slices?
You can only find out by testing, every browser will have different performance parameters and your user base may have anything from a mobile phone to a 16-core Xeon desktop. The larger determining factor may actually be the network performance in loading new tiles which is completely dependent upon how you are hosting and who your users are.
As the others already said, you can save a lot of research by duplicating the sizes already used by similar projects: Google Maps, Bing Maps, any other mapping system, not forgetting some of the gigapixel projects like gigapan.
It's hard to give a definitive dimension, but I successfully used 256x256 tiles.
This is also the size used by Microsoft Deep Zoom technology.
In absence of any other suggestions, I'd just use whatever Google Maps is using. I'd imagine they would have done such tests.
There are lots of non-image-based CAPTCHA ideas floating around. But what about the old-fashioned way?
What are the elements of a good image CAPTCHA? What visual elements are hard for computers, but easier for humans? What about mistakes, elements that are easier for computers than they are for humans? What are good techniques for increasing the speed of a CAPTCHA generator?
Here's an example of a CAPCHA I've been working on. It generates the functions for two sine waves, then stretches a text between them. It lays that over a background drawn from a pool of images.
How could this be improved? (Specifically, I'm using PHP GD.) Things that come to mind are:
Change the color of the text, possibly making it multicolored.
Add "scratches" or marks that mildly obscure the text.
Add to the distortion so that it's affected by sine waves horizontally as well.
What goes into a superb image CAPTCHA?
Edit:
I know that there are some very worthy third-party CAPTCHA resources. I'm looking for attributes that make them good. I'd like to use my own CAPTCHAs, just for the purpose of self-improvement. So, you can talk about reCAPTCHA, but it's not exactly what I'm looking for.
Also, it has been brought up that not only the image, but also the experience matters, so feel free to comment on that.
Make each letter/number out of a pattern, I.E. unconnected dots. Meaning the computer has no way of knowing that a dot is part of a letter other than pattern recognition (which they don't have yet.) Then the usual distortions and random lines.
How you do this is the challenge.
EDIT: Also, bonus points for patterns of different shapes, and try alpha transparency on the characters (on the edges or the whole character), so they merge with the background.
Make letters difficult to separate. Use handwriting-like font or add lines that join letters. Decrease and randomize spacing between letters.
Add wave distortion in other axis too. Distortion in one axis only can be relatively easily analyzed and reversed.
Don't bother with color background at all. It's super-easy to automatically filter black from other colors. Your background hinders only humans.
Don't add scratches or other noise unless it has the same thickness as letters. Noise-removal algorithms can easily remove things that are thinner than letters.
What if the color of the letters faded into other colors... for instance the 5 can start off as yellow on top and fade into blue or something. The colors chosen should be random.
With the multicolored background it might make it hard for the computer to pickup where the background ends and the character begins.. and hopefully it would not be too difficult for the human to actually pick up the pattern.
Instead of generating captcha you can create a captcha table in your database and you yourself create the table by search on google for good captcha images.
So no need to worry "Will this generation method work?"
I really hate CAPTCHA on sites, they just annoy me, but if you want to try and make a robust one try the following:
Ability to get a new image without submitting
Spoken version for the visually impaired
Non-uniform characters
I've used Recaptcha on a few sites, it's a nice and robust solution.
Or if you want to be really funky about it check out this: http://research.microsoft.com/asirra/
Algorithms that try to break captcha are pattern matchers that work by a few different ways: scaling and skewing the symbols that they already know about, finding and tracing edges, and counting interior holes to help. If you can break the letter up into pieces, vary the letter quality, or add strong lines or “scratches” along the letters these techniques will help. However all of this is fairly moot considering we have recaptcha for this purpose and it’s a wonderful third party app for this. Additionally captcha will help the security of your site, but will not stop those who are truly enticed.
I like the idea of KittenAuth and Microsoft's Asirra project. The idea is that, while OCR will eventually evolve to break your traditional captcha, the ability to distinguish a kitten from a dog is many orders of magnitude more complex a problem, while absolutely trivial for humans.
This solution, while probably the sexiest captcha idea ever, has the limitation of not being easily portable to hearing-impaired methods.
What about shearing and shuffling bands to mangle display and mouse-only input?
Start by taking your sine-wave morphed text, divide into horizontal bands or maybe even a grid.
That makes optical recognition harder and might allow you to avoid the kind of nasty background games that make some captchas hard for humans.
For a site where you can rely on local drag in the browser, instead of typing in an entry use shuffling requiring the user to re-order pieces (just in sloppy order, not like one of those puzzles). Or, if you wanted to use clicks alone, the classic sliding tile puzzle.
Note, I've run into a captcha where you had to identify which of N cartoons had an animal in them which succeeded in blocking me!
Wellington Grey sums up the AI CAPTCHA race nicely.
You could add a random array of fonts so that GD renders each character using a different one.
Be wary of suggestions of ReCaptcha. I have submitted incorrect input into it a couple few dozen times, and have had success each time. Several of those times I have submitted incorrect input for both words rather than just the most obscured word; the success rate, as I said, has been 100%.
I also think that image-based CAPTCHAs are user-hostile and should be avoided wherever possible. The advantage of text-based solutions is that you can tailor them to your site's audience, adding a level of obscurity that may trip up machines as they become more savvy with text-based solutions.
At the very least, don't use this all the time:
(source: codinghorror.com)