![developer3 | Embarcadero RAD Studio Delphi C++Builder Blogs](https://i0.wp.com/blogs.embarcadero.com/wp-content/uploads/2020/08/developer3.jpg?resize=1140%2C694&ssl=1)
The advancement of technology over the years has made life more comfortable. Arguably, if we’re to have a truly inclusive society, one of technology’s priorities should be eliminating the lines of race, gender, ability, amongst others.
The same goes for application development. To get your products or services to the largest possible target audience, you must eliminate all usage barriers. This is where accessibility plays an important role.
With the mass adoption of mobile devices, many companies’ focus has shifted towards developing mobile-first applications, when, perhaps, the key to unlocking the treasure pot is accessibility-first. Here, your applications would not only be available to mobile users but to everyone that requires your products or services.
Mobility is not a condition for accessibility. If you’re to follow the accessibility-first initiative, you must aim for desktop-first application development. This is because accessibility support on desktops, especially in native desktop app development platforms like Delphi, is well established. Therefore, not only should the desktop be first, but accessibility should be first and is with native desktop apps!
Read on to find out more on why desktop-first rules accessibility. Or you can dive into our Desktop First UX Summit to learn more about building desktop-first applications.
Table of Contents
What Is Accessibility?
Accessibility refers to making your application suitable for use by everyone, including people with disabilities – for example, impaired vision, hearing, cognition, and other ways in which a user may be differently-abled. The world is filled with people of varying physical abilities and sensory challenges. In fact, according to a CNET article, at least 15% of the world’s population suffers from a disability.
The Center for Disease Control (CDC) also reports that 25% of Americans are considered disabled; in other words, one in every four Americans. Of this number of people affected by disability in the United States, the largest group are blind or suffering from a form of visual impairment, or deaf, or hearing impaired. Other challenges included those who suffer from mental disabilities or difficulties with either speech, mobility, or cognition.
Because of these individuals, the Americans with Disabilities Act (ADA) was put in place to ensure that companies offer general application accessibility. With most people still forced to stay indoors in some parts of the world due to the Covid-19 pandemic, accessibility has never been more imperative.
To this end, numerous desktop tools make it easier to access data and navigate through web and native applications. Some of which include;
- Voice commands
- Screen readers
- Alternative or specialized keyboards
- Trackpads and other adaptive pointing devices
- Screen magnifiers
- Eye-tracking tools.
It’s clear from this list that all these tools have something in common; while voice command is more common on mobile devices, they’re all easier to use and implement on desktop than than they are on mobile devices with a greater variety of unfettered hardware choices from a broader and more diverse selection of vendors. On the desktop, users are less constrained by the operating system and, in particular, the hardware manufacturer (of which there are only a handful for mobile devices) when reviewing options for assistive technologies.
Desktop Accessibility Features
All standard desktop applications, for example, mail app, internet browsers, office applications such as spreadsheets and word processors, photo manipulation software, and so on, are conscious of and are maximizing accessibility today to ensure their widest possible adoption. This has benefits not just for disabled users but any user.
Here are some of their UI design features;
The TAB Order
For easy accessibility using the keyboard, desktop-first applications’ controls are in the TAB order. In other words, a user can press the TAB key to switch the input focus between controls without needing to point with a mouse which can be challenging for many. Without this feature, you defeat the purpose of accessibility. A TAB keypress can be mapped to an assistive device such as a blow tube or head switch – without consideration of tab order, a user might be forced to select entry controls such as text boxes in an address form by moving the mouse cursor and then clicking to select it, which can be a Herculean challenge for some differently-abled users such as those with Parkinson’s Disease or ALS.
This is an example of where desktop-first shines. You can’t implement the TAB order or its equivalent on mobile devices as the TAB function is absent, and the user must directly select controls by clicking on them. If you wish to experience one tiny iota of how difficult this can be try using the tip of your nose to accurately type your address into a text message on your mobile phone. Now try it with your eyes closed. Disability comes in many forms, yet the methods we provide to enter and interact with our mobile devices are shockingly one-dimensional.
TabStop is False on Purely Visual Controls
While enabling user navigation using the TAB key is essential, standard desktop-first applications are mindful not to set TabStop to True on purely visual controls which convey information and do not require or expect user input. In other words, the focus must only land on controls users can interact with. For example, the TPanel is a purely visual control, and this desktop accessibility feature ensures that focus does not land there.
Control Labels
Another desktop accessibility feature is control labels, that is, label and static text controls. They are added in the tab and creation order immediately after the control. Therefore, helping screen readers to associate labels with their corresponding controls.
Focus Always On Active Controls
Some applications have dialog-dependent buttons that only become active when a dialog option changes and become inactive after a click. Desktop-first applications have a feature that ensures focus returns to an active control once the currently focussed control becomes inactive. This way, any user can continue navigating seamlessly and in an order which flows logically.
Mnemonics
Have you noticed underlined characters in any Windows dialog? Those are referred to as mnemonics. They’re also referred to as “accelerator shortcuts.” They are declared in a control’s caption to help users set focus on the control. Pressing the Alt key plus the underlined character changes focus to the control. With later versions of Windows, holding down the ALT key will get the operating system to show small highlight ‘hints’ with the mnemonic letter. This is particularly useful for some users with disabilities when using Windows accessibility features like Sticky Keys – where a key such as CTRL or SHIFT, which normally needs to be kept depressed in order for it to change the case of a character, instead acts as a toggle (think of how the CAPS LOCK key works).
Grouped Related Controls
Desktop-first applications group-related controls in the same group, for example, all radio buttons under the radio button group. This way makes it easier for accessibility tools to interact with these controls.
Keyboard Shortcut for Every Option
Desktop-first designs ensure that each option is accessible via a keyboard shortcut or menu item. An excellent example of where you can find this feature is the Microsoft Word standard toolbar. Here, you have the “New” option, but you can also achieve the same result with the keyboard shortcut “CTRL + N.”
Desktop Accessibility vs. Mobile Accessibility
In the world of application accessibility, mobile apps are often inadequate in addressing or entirely ignorant of accessibility legislation, increasingly common in many countries and states, as evident in the number of companies sued for inaccessible native mobile apps. While the usage and engagement on mobile are soaring, it is difficult – or inconvenient for the unwilling – to adhere to some accessibility checklists, rules, and regulations, for example, section 508 of the Rehabilitation Act of 1973. This puts specific guidelines in place to ensure that all electronics or information technology is accessible to people with disabilities.
To find out more on section 508, refer to the official Federal Government website here.
Other accessibility challenges are:
Screen Sizes and Custom Aspect Ratio
Mobile devices are known for their portability, that is, small screens and custom aspect ratio. Developers have to account for this during the application development process, as smaller screens mean users might only have to assimilate information in very small pieces. This can lead to inefficiency and reduced productivity as developers worry about screen size instead of building business solutions.
Desktops, on the other hand, have large screens. Developers can focus on developing business solutions rather than brainstorming how to represent information on portable devices with a limited screen area. Inevitably, at some stage, a compromise is made on what can be shown on the smaller screen and how easy that is to digest for the user. Your end-users can more easily see and digest your information on bigger screens. This helps improve efficiency, productivity, usability, and ultimately ROI due to happy end-users.
Inputs And Data Entry Methods
Other than voice commands, inputs and data entry can be difficult for most users on mobile devices due to the less comfortable data entry options available on this platform. It’s true to say that even wholly non-disabled users can struggle to access and enter some kinds of information on a mobile device’s touch keyboard and small screen. Add into that mix an impairment such as macular degeneration, double-vision, loss of motor control in the fingers and hands, uncontrollable or difficult to control head movements. Well, it’s not hard to understand how things can very quickly become a huge frustration at best and an impossibility at worst.
Super-intelligent AI assistants and voice control are utterly useless if you have no voice after it was stolen by cancer – or your tongue refuses to obey the instructions of your brain due to cerebral palsy or paralysis.
Life can be extremely challenging for some to carry out even the most simple tasks that the more able-bodied often take for granted. As designers, we have a moral, and in many cases legal requirement to design for users of every kind, and in this paper we’ve tried to make the case that desktop first really does mean we are putting accessibility first, too. For more information on how desktop applications are evaluated for accessibility, click here.
How can I learn more about building desktop-first applications with first class accessibility support?
The Desktop First UX Summit is in full swing. Join industry experts and thousands of developers and designers like you in this five-day open online conference and take your desktop UI/UX skills to new levels! The Desktop-First UX Summit will cover both the theory and practice of creating great desktop user experiences.
Join us at the Desktop First UX Summit for free right now!
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
Does that mean the VCL will add support for Windows UI Automation soon, then?
That’s a good question and right now I don’t know the answer. Is this something you have particular skills in? If so, can we contact you for more information about what would be helpful to people regarding UI Automation? (Note that we can get your contact details from the comment info so, to avoid you being spammed please don’t put them in body of any reply).