Category: Accessibility

Accessibility Resources

by Yawer Iqbal, posted in Accessibility, Customer Engagement (CE), Model Driven Apps, PowerApps

Accessibility is an essential consideration for a public sector or enterprise implementation. In this post I m sharing some resources generally about accessibility and also particularly about accessibility in Power Platform Projects. Some of the resources are from Microsoft and others are links to the work I have been doing in previous years. While preparing this list I m feeling very hopeful and excited, why ? because few years back there were not many resources available but now we have good collection, isn’t great 🙂

Resources

  1. Accessibility Fundamentals learning path at Microsoft Learn
  2. I presented ‘Accessibility in Power Platform Projects’ at Scottish Summit, here is link to recording
  3. Similar to above another session at our own “The Good Citizen Developers”, here is recording.
  4. In Oct 2020 I presented “Accessibility in PowerApp Projects” at Washington DC – User Group. Thanks to lovely organizers and supporters of UG Kylie Kiser, Aiden Kaskela, Nelson Johnson, Mike Ochs and others. I covered things like what accessibility is, why it is important and how to make a PowerApp project accessibility compliance. Here is recording https://www.youtube.com/watch?v=GdK2eV8oOLU
  5. Microsoft Accessibility Conformance Reports can be downloaded from here
  6. My blog posts on accessibility:

    “Accessibility” for D365 Projects
    “Accessibility” for D365 Projects 2
  7. Scottish Summit 2021 accessibility sessions

Let’s Connect

twIcon lnIcon fbicon

“Accessibility” for D365 Projects 2

by Yawer Iqbal, posted in Accessibility, Customer Engagement (CE)

accessibilitypart2 

This is my second post on this topic. In first post “Accessibility” for D365 Projects, I mentioned accessibility became part of our project requirements but it was not from the start of the project, it happened when multiple releases were already delivered and in production. So it was not straightforward to make everything accessible. This taught us two important lessons:

  •  Best time to decide if accessibility will be a consideration is the start of the project. Later it will be expensive.
  •  If it is going to be a requirement, it is worthy for the whole team to learn the basics of accessibility. By team, I mean everyone (developers, consultants, testers, leads, managers and product owner).

Web Content Accessibility Guideline (WCAG) is the draft about accessibility standards:

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.

WCAG provides comprehensive details to understand and implement these standards. A reader can find from there what a standard is, its purpose, why it is important and various techniques to meet a particular standard. Interestingly for us, accessibility testing raised around 100 defeats to fix. They were in web resources and also in D365 forms. Below are a few examples of defects and their respective WCAG details:

  1. For a form or web page, multiple ways to navigate are not available 2.4.5
  2. Keyboard navigation not provided or can’t input just using a keyboard 2.1.1
  3. Colour contrast is not as per accessibility standards 1.4.3
  4. Incorrect focus order 2.4.3
  5. HTML title missing on page success criteria 2.4.2
  6. Tooltip missing on UI elements 1.1.1
  7.  Missing attributes in UI elements (like name and role) which supports screen readers read 4.1.2
  8. Page zoomed to 200%, some elements didn’t render correctly or were not visible anymore 1.4.4
  9. Links, headings or other text is not readable by screen reader 2.4.4.

 Following guidelines, we were able to fix almost all issues reported in web resources but limitation with D365 forms was that we don’t have full control over mark up. We were able to fix issues where we have control like improving colour contrast or provide tooltip text but for many issues, we raised support tickets. Some of the reported issues were fixed and for others, the recommendation from Microsoft was to use Unified Interface. In the start of this post, I shared two important learnings from this experience. I will end this post by third major learning:

  • Accessibility is another important reason to start using Unified Interface.

Enjoy your D365 day 🙂

Links

Let’s Connect

twIcon lnIcon fbicon