Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
19 how to create real accessible aria
1. HOW TO CREATE REAL
ACCESSIBLE ARIA
Jan Vystrcil
Czech Technical University in Prague
2. SUCESS project
• Center of Excellence between CTU in
Prague and Sun Microsystems (Oracle)
• ARIA enhancement of 2 JSF based toolkits
– ICEfaces
– Apache MyFaces Trinidad
CTU in Prague AEGIS Workshop and International Conference, Brussels 2
3. Rich environment of RIA
• Modern RIA applications are build from
components
– Tree
– Tabs
– Accordion
– Grid
– etc.
CTU in Prague AEGIS Workshop and International Conference, Brussels 3
4. Rich world of RIA
• Web environment is extremely variable
• Accessibility depends on:
– Type of OS
• Windows, Linux, Mac, …
– Type of Web browser
• Firefox, IE, Safari, Chrome, …
– Type of Screen reader
• Jaws, NVDA, Orca, …
• No configuration is 100% ARIA compliant
CTU in Prague AEGIS Workshop and International Conference, Brussels 4
5. Three steps towards accessible RIA
1. Accessibility of RIA components
2. Accessibility of RIA applications
3. Testing of application accessibility
CTU in Prague AEGIS Workshop and International Conference, Brussels 5
6. Three steps towards accessible RIA
1. Accessibility of RIA components
2. Accessibility of RIA applications
3. Testing of application accessibility
CTU in Prague AEGIS Workshop and International Conference, Brussels 6
7. Offline component prototype
Server Web Browser User
CSS <HTML> ??
<HTML> ?
<HTML>
JS
JS
JS
CSS
<HTML>
<HTML>
JS
JS
CTU in Prague AEGIS Workshop and International Conference, Brussels 7
9. Accessibility of RIA components
1. Create offline component prototype
2. Simplify the component architecture
3. Add WAI-ARIA attributes into offline
component prototypes
– Implementing ARIA attributes
– Implementing keyboard navigation
4. Implement changes back to the server
– Test whether results are accessible
CTU in Prague AEGIS Workshop and International Conference, Brussels 9
10. Three steps towards accessible RIA
1. Accessibility of RIA components
2. Accessibility of RIA applications
3. Testing of application accessibility
CTU in Prague AEGIS Workshop and International Conference, Brussels 10
11. Issues to be implemented
• Navigation on the page
• Relationships between components
• Dynamic changes of presented information
• Created set of 11 heuristics based on
Nealson’s usability heuristics
CTU in Prague AEGIS Workshop and International Conference, Brussels 11
12. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
as possible
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
8. Define complete keyboard operation and where possible,
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 12
13. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
Screen readers and another assistive technologies
3. Use headings to mark important areas parts of
use several browsing modes. Make sure all
4. Handle hidden section appropriately “virtual
the web page are accessible at least with
5. cursor” and “forms mode”. In forms mode all
Communicate important information and feedback as soon
asinformation in the form area must be linked to one of
possible
the form elements as a label or description.
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
8. Define complete keyboard operation and where possible,
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 13
14. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
Icons and other similar visual elements that carry
4. Handle hidden section appropriately
information to the user should have a textual
5. alternative available. The only exception is when a
Communicate important information and feedback as soon
asnon-textual element is used for decoration or layout
possible
purposes.
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
8. Define complete keyboard operation and where possible,
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 14
15. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
Headings are the only elements with various levels of
5. Communicate important information and feedback as soon
importance. They are often used to scan the
ascontent and should be used when possible to denote
possible
sections.
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
8. Define complete keyboard operation and where possible,
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 15
16. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
When showing larger section move focus to the
assection. When showing a tooltip all content should
possible
6. Create proper as description.
be connected linkage of controls, labels and messages
7. Distinguish all components
8. Define complete keyboard operation and where possible,
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 16
17. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as
soon as possible
6. Create proper linkage ofwhere possible. Use live messages
Use on-the-fly validation controls, labels and
7. Distinguish communicate asynchronous messages.
regions to all components
8. Define complete keyboard operation and where possible,
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 17
18. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
as possible
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
Connect menus with corresponding dynamically
8. Define complete using aria-controls.
loaded sections keyboard operation and where possible,
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 18
19. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
as possible
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
8. Define complete keyboard operation and where possible,
All components that have their Roles identified in
standardize
WAI-ARIA should be marked using appropriate Role.
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 19
20. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
as possible
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
8. Define complete keyboard operation and where
possible, standardize
9. Define document structure with ARIA landmarks
Use design patterns defined in WAI-ARIA or DHTML
10. Provide a logical tab order proper keyboard
Style Guide to determine the
11. Use buttonsbefore implementing your own. linking
navigation for functions and links for
CTU in Prague AEGIS Workshop and International Conference, Brussels 20
21. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
as possible
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
Identify as many common structure parts as possible
8. Define complete keyboard operation and where possible,
and apply WAI-ARIA landmark roles to them.
standardize
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 21
22. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
as possible
6. Create proper be close of the means of tab order to
Menus should linkage in controls, labels and messages
7. Distinguish allthey are affecting. Tab order is
the sections components
8. Define completeused to quickly scan the page for possible,
important as it is keyboard operation and where
interactive components. If the tab order is faulty, the
standardize
mental model of the web page will likely be incorrect.
9. Define document structure with ARIA landmarks
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 22
23. Heuristics
1. Design with screen reader modes in mind
2. Provide text alternative for all non-textual elements
3. Use headings to mark important areas
4. Handle hidden section appropriately
5. Communicate important information and feedback as soon
as possible
6. Create proper linkage of controls, labels and messages
7. Distinguish all components
8. Define clear distinction between buttons and links. possible,
Make complete keyboard operation and where
standardize
For all functions that are available on the page use
buttons. For navigation purposes and for linking to
9. Define document structure with ARIA landmarks
other pages or anchoring, use links.
10. Provide a logical tab order
11. Use buttons for functions and links for linking
CTU in Prague AEGIS Workshop and International Conference, Brussels 23
24. Three steps towards accessible RIA
1. Accessibility of RIA components
2. Accessibility of RIA applications
3. Testing of application accessibility
CTU in Prague AEGIS Workshop and International Conference, Brussels 24
25. Testing of application accessibility
• Developer is typically NOT:
– Blind user
– Used to operate screen reader
• Need for accessibility testing with blind users
• Early stages of development means:
– Poor accessibility
– Need for support of accessibility testing
CTU in Prague AEGIS Workshop and International Conference, Brussels 25
26. View of blind user
• User see some components just partially or
they seems missing
E
A
B D
C
CTU in Prague AEGIS Workshop and International Conference, Brussels 26
27. View of developer
• Developer see all the components
E
A
B D
C
CTU in Prague AEGIS Workshop and International Conference, Brussels 27
28. View of user with description
Datepicker (E)
Tablist (A)
Tab 1
Collapsible panel (C)
E Panel 1
A Tree view (B)
Panel 2
B D Grid (D)
Tab 2
Grid
C
CTU in Prague AEGIS Workshop and International Conference, Brussels 28
29. Conclusion
• RIA accessibility is
complicated and complex
process
– Has to be treated in phases
• Valid testing is
complicated
– Support of blind tester
needed
CTU in Prague AEGIS Workshop and International Conference, Brussels 29
30. Thank you for attention
Jan Vystrcil
Czech Technical University in Prague
Faculty of Electrical Engineering
Czech Republic
CTU in Prague AEGIS Workshop and International Conference, Brussels 30
