Form accessibility demystified
Web is open platform, thus any application developed for this open platform should be accessible for any users, irrespective of their disabilities. Accessibility must be treated as the core feature of the user experience. Quite often, a web application that is keyboard accessible is considered to be accessible compliant. How ever which is partially true. For example, ‘hasgeek login’ form. There are visual indication of the error in the page, however for visually challenged user there is no indication for error and teh experience is more like an infinite loop. Using aria-invalid and aria-described by solves the problem.
Developers mainly focus on the ‘look and feel’ along with performance. Is the awesome looking UI accessible via keyboard completely, accessible for a visually challenged user?
If not, how to achieve it? How to make visually challenged users aware of all the dynamic changes/updates the UI is going through?
Many a times we use custom elements instead of native. For example, using a custom drop down menu instead of native select/options. It is quite easy to visually implement a custom drop down menus using div(s), ul(s) and li(s). But, is it completely accessible, via keyboard, by a user who is visually challenged?
This presentation will mainly focus on ‘HOW’ rather than ‘WHAT’ with respect to web accessibility and real life use cases of accessibility.