Build for keyboard and assistive technology

Name the purpose, not the appearance#

Use AccessibleName to tell the user what a control does or accepts, and AccessibleDescription for useful additional guidance. “Customer email” is more useful than “TextBox 4”. Leave the native role in place unless you have a specific supported reason to override it.

Keep focus predictable#

Set TabIndex by task order and test each container separately. Do not remove a focused control unexpectedly when a validation message appears. After rejecting input, return focus to the field that needs attention when that helps the user correct it. ReadOnly can preserve selection and copying; Enabled=False blocks interaction.

Do not communicate only through color#

A red border alone does not explain what is wrong. Pair field-level errors with text and a useful summary. A progress bar should have a textual state; a badge should have meaningful text. Avoid changing the entire Form state for a local recoverable error.

Test the actual task#

• Complete the workflow without using a mouse.
• Increase text size and inspect the layout.
• Check accessible names in the running application.
• Test disabled, read-only, busy and error states.
• Check that a hidden or collapsed area does not leave unreachable required input.