“Accessibility” for D365 Projects 2


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 🙂


Let’s Connect

 twIcon lnIcon fbicon

1 Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s