I also recommend our own Stefan Schnabel’s Accessible Rich Internet Applications (ARIA) – Part 2: ARIA as a deeper introduction. If you need more in the meantime, make sure you read the SAPUI5 SDK section SAPUI5: UI Development Toolkit for HTML > Developing Content > Developing SAPUI5 Controls > Accessibility Aspects for SAPUI5 > Screen Reader Support for SAPUI5 Controls.
I’ll leave it there for now as this is obviously a big topic worthy of it’s own blog, maybe even it’s own blog series.
Make sure the Properties and Associations of your control and mapped to the relevant ARIA attributes. ARIA Attributes are relevant to your control. ARIA States are set as your control changes state. Because when it comes to Fiori and Accessibility – good controls developers ROCK! They make the job of the designer and application developer easy.Īs a controls developer you decide which: If you are a controls developer consider this a first introduction into conceptually what you need to do. While I won’t dwell too much on the controls side in this blog, it’s helpful for application developers to understand what the controls developer provides. So at this point let’s clarify the difference between approaching Screen Reader provisions as an application developer and as a controls/framework developer – because some of you out there are both. Ok so in part 1 along with discussing WHY you should provide for Screen Readers, I also introduced the basic concept of HOW: Label (almost) everything. This blog will show a couple of examples … more detailed examples to follow in a later post (check in with the SAP Fiori – Accessibility collaboration document from time to time if you are looking for that). In part 2 I show the basics of HOW providing for Screen Readers works in Fiori, SAPUI5, and OPENUI5. In Part 1 I discussed WHY application developers should provide for Screen Readers. Understand the basics of why and how to provide Screen Reader capability for Fiori, SAPUI5, or OPENUI5 apps.
0 kommentar(er)
