What is blindness?

Many people imagine blindness as complete darkness. But that’s not entirely true.

The term “blindness” covers a broad spectrum of visual disability, from when your sight is impaired enough to interfere with daily activities like reading, cooking or driving, up to total blindness.

Legal blindness is a level of blindness that has been defined by law to limit some activities for safety reason, such as driving, or to determine eligibility for disability-related government programs and benefits.

Deaf-blindness

Deaf-blindness is a combined loss of hearing and vision that results in significant challenges accessing information. Some people are born with Deaf-blindness, while others acquire it later in life. 

Some of the Technologies that blind people use are,

Screen Readers

These are software tools used primarily by people with severe vision impairment. The screen reader software interacts with the HTML on the page to give audio feedback to the user. The structure of the HTML has a direct impact on the way the screen reader interprets the content on your site.

Design Considerations for Blindness

Here are some of the considerations for designing web content for people using screen readers.

Design Consideration
All content must be presented in text or via a text equivalent (e.g., alt text for images or other non-text objects). Screen readers cannot read non-text content (e.g., images) directly, but they can read alt text that you provide.
All functionality must be available using only the keyboard (Note: be sure to test with the screen reader turned on, because there are subtle differences in keyboard behaviors when the screen reader is on). Even though most blind users can physically use a mouse or track-pad, it doesn’t do them much good because they can’t see where the mouse pointer is. It is more effective for them to navigate by the keyboard.
The content must use markup with good structure and semantics (headings, landmarks, tables, lists, etc.). Screen reader users often pull up lists of headings, landmarks, and other semantic elements to help them understand what is on the page. They can also navigate by these elements (e.g., jump directly to the main content landmark, or to a specific heading).
All custom controls (e.g., expand/collapse buttons, media player volume control, dialogs, etc.) must have the correct name/label, role (either with HTML or with ARIA), and value, and must change value when appropriate (e.g. aria-expanded=”false” changes to aria-expanded=”true” after activating the button). Unlike native HTML elements, custom controls have no semantic parts natively, so screen readers can’t tell users what the widget is, and can’t update users on the properties of the widget unless you supply that information via ARIA names, roles, states, and properties.
Users must receive immediate feedback after all actions, via their screen reader. Silence after activating a feature is always bad! Examples of feedback: Expanded/collapse region, value changed on a control (e.g., on a slider, successful/unsuccessful form submission, notification that a new “page” has loaded in single-page applications, etc.).
Videos require audio descriptions (additional narration of visual content) if the video’s original audio track (dialog, sounds, narration) does not explain everything that a person who is blind would need to know to understand the video.
On mobile devices:All features require a click action. Custom swipe actions on web pages will not work with the screen reader turned on. When a blind screen reader user is on a mobile device, swipe actions are used by the screen reading software. All features (controls, widgets) on a mobile web page require a click action to work at all.

Let me know what you think.