RESEARCH & PERSPECTIVES / AI & BRAND
Why should accessibility design begin at the product planning stage?
Start with real tasks, diverse conditions of use, and verifiable interaction requirements to make accessibility part of the shared planning for products, content, and services.

Start with user tasks instead of adding a feature at the end
Product teams often wait until the interface is complete to check whether text is clear, buttons are easy to activate, or content can be read by assistive technology. At that point, if important actions rely on a single gesture, color, or sound, changes may involve the information architecture and workflows, rather than just a style adjustment. Considering different conditions of use earlier makes it easier to incorporate accessibility into decisions about the product itself.
CES's introduction to accessibility at its 2026 event connects inclusive design with product usability. Taking this publicly stated direction as a starting point, this article discusses how businesses can organize work across planning, design, and delivery. It does not constitute compliance certification or a legal conclusion for any product.
Accessibility design serves more than one group of people. Differences in vision, hearing, movement, cognition, or device access can affect how people complete tasks. Situations such as temporary injuries, noisy environments, and one-handed use can also reveal similar issues. Specific needs should be confirmed through appropriate research and testing in real use.
First, identify key tasks and potential barriers
Choose the product's most important tasks, such as finding information, understanding product terms and conditions, submitting an inquiry, completing setup, or getting help. Record what users need to see, hear, understand, and do at each step, and check for steps that can only be completed in one way. Do not assume, without validation, that everyone in a particular group has identical abilities.
On a website, readers may be unable to access important information as text if it appears only in images. If a form uses color alone to indicate errors, some users may not understand what needs to be corrected. Videos with audio but no corresponding text may also cause some people to miss information. Improvements should reflect the specific content and context of use, rather than simply adding decorative icons.
Devices and physical spaces present similar issues at points of interaction: button placement, voice prompts, ambient noise, sightlines, and reach can all affect operation. Product, engineering, and experience teams should work together to identify constraints and validate them under actual conditions.
When planning research, avoid treating any participant as the sole representative of a group, and do not ask participants to disclose unnecessary personal information. Explain the purpose of the test, the tasks, and how feedback will be used. Provide communication channels that support participation, and arrange any necessary support according to the circumstances.
Include accessibility in requirements and design deliverables
Requirements can specify the tasks users need to complete, known constraints, interaction methods that must be supported, content owners, and acceptance methods. For example, an inquiry form needs clear field labels, understandable error messages, keyboard navigation, and visible focus indicators. The specific approach should be confirmed with the technical team and checked against applicable standards.
Design deliverables should include more than visual mockups. They should also describe the different states of components: default, focused, error, disabled, and complete. Text, image descriptions, prompts, and interaction order all require collaboration between content and development teams. If a state has not yet been designed, record it as an outstanding task rather than leaving developers to guess.
For AI features, specify how users can tell that the system is performing a task, how they can review or edit inputs, how they can understand uncertain results, and when the process should be handed over to a person. The system should not present unconfirmed results as established facts.
When procuring third-party systems or components, include key user tasks and accessibility requirements in the materials shared with suppliers. Before launch, validate them on your own actual pages and devices, rather than assuming the entire workflow is usable based solely on a supplier's brief description.
Involve real users in validation
Automated checks can help identify some issues, but they cannot, on their own, establish that the entire experience is usable. Based on the product's actual goals, invite participants with different usage experiences to complete tasks, observe where they struggle to understand or operate the product, and respect their privacy, time, and feedback. Agree on the scope, conditions, and participation arrangements in advance.
Do not simply ask participants whether they like a page. Ask them to find specific information, submit a form, or complete device setup. Record the step at which difficulties arise, whether existing alternatives are usable, and which tasks the issue affects. Situations that cannot be covered in the current round should be scheduled for further validation, rather than claiming that all users can use the product without difficulty.
When checking assistive technology, keyboard access, and different screen sizes, specify the devices and versions used. When issues are found, design, development, and content owners should jointly determine how to fix and retest them, avoiding changes limited to surface styling.
For images, charts, and downloadable files, establish who will convert the information into readable text, when it will be updated, and how descriptions will be kept in sync when the original visuals change. For visual elements that are purely decorative, avoid creating meaningless repetition for assistive technology users.
Maintain usability after launch
New website content, changes to third-party components, or adjustments to product workflows can all alter the existing experience. Assign owners to important pages and components, and include accessibility checks in update and regression testing processes. Make it easy for users to find a channel for reporting issues, and define how those issues enter the handling queue.
Businesses can begin with a workflow that receives significant traffic or supports a critical business function, such as finding product information or making a project inquiry. Establish a baseline across tasks, content, interaction, and technology, then expand gradually. For unresolved issues, record the impact, owner, and plan rather than making unverified claims of full compliance.
Qingmei Future can assist with information architecture, interface design, and content experience design. Applicable standards, legal obligations, and final conformity must be confirmed by the business and relevant professionals in the context of the specific product and region.
Discussion Background and Scope
CES · Accessibility at CES® 2026: From Specialized Solutions to Core Innovation · 2026-05-07. Official page date: 2026-05-07. The source discusses accessible design and inclusive innovation. It is background reading, not evidence for each practical recommendation in this article. The recommendations are Qingmei Future’s independent analysis.
Related Services and Content
Explore interface design services Explore website design and development Browse enterprise solutions Discuss your product experience needs
CONTINUE READING More insights
How can products for older adults be designed around real-life situations?
Observe specific everyday tasks and environments, and work with target users to test information, interactions, ways to get help, and recovery from errors.










