Improving accessibility in MAUI

 

.NET #MAUI has an ever-improving set of tools to help build apps that are accessible to as many people as possible.

However, I recently needed to add some accessibility-related features to one of my apps, only to find that there wasn't an easy way to do this. So, I made one.

Specifically, I created a library that means that it's possible to see if the device (Windows, Android, iOS, or Mac) that the app is running on has been configured to use reduced motion or to show text at a different size.

It means that I can easily make it so that my app doesn't show animations when a person has requested that the OS (& apps running on it) don't show motion.

Also, while the built-in MAUI text controls automatically account for OS-level text sizing, if I need to draw text myself (e.g. to add to an image), I can do this in a way that respects the needs and requests of the person using the app.

As these are both accessibility-related features, I called the library Plugin.Maui.Accessibility.

The library is available on NuGet, and the source is on GitHub.

It's an almost embarrassingly simple API exposed by the library. It just has two properties. One lets you know if the device is configured to use reduced motion. The other tells you the factor by which to scale any text.

The library is based on the great work that Gerald Versluis did with Plugin.Maui.Feature.

Originally posted on LinkedIn (Note. I currently accept all connection requests there)

What is involved in making XAML "better"?

I've talked to a lot of people about how to make XAML "better", and by that, I mean making it easier to read, understand and maintain.

Seeing the " better " principles in the abstract makes sense to most people, but how do you apply them to an existing code base?

My friend Joe had this question,  so we got together on a call to see how to make some changes to one of his apps.

And for the benefit of others, we recorded the conversations:

Part One - Helping Joe make XAML more maintainable

In the first part, we look at:

• Understanding existing inconsistencies
• Creating simple custom controls through inheritance
• Inheriting from an existing control and customizing the content
• Creating a simple User Control
• Applying standardization through styles.

Part Two - Helping Joe write maintainable XAML

In the second part, we focus on:

• Extracting complex nested XAML
• Using services to isolate logic
• Using messaging for simple communication scenarios between different parts of the app

I'd love to know if the is helpful, and if we should make a third part...

when "make it work, make it right, then make it fast" was wrong!

In a reflective mood today, I recalled a time when the "make it work, make it right, then make it fast" approach failed to work for me.

As part of a large-ish development team (about 20 developers, designers and testers,) I was tasked with building the data access component. It was a large, new application that was highly complex and also high profile. 

I was the first developer on the team and did some early experiments and research into the new platform we'd be building for and the new framework we were to use.

After a few weeks of R&D, I went on holiday (vacation.)

While I was away (and without my knowledge), work on the project started "properly". One of my POC/experiments was assumed to be good enough to start the work, and people were quickly added to the team. While all this was happening, the app's requirements were still being decided.

When I came back, I found people busy trying to implement the individual sections of the app they had been assigned and I was asked to work on the "common data layer" that would provide everyone access to the data they needed.

I was scrambling to provide the other developers with the data they needed while the other developers were also dealing with designs that kept changing and so needing new/different data.

I just about kept up, but as the requirements of the data retrieval and caching were still being decided and worked out, I focused on building a data access API that the other developers could use and could hide the caching such that no other parts of the code had to pay them much mind beyond being able to specify if and when cached data was or wasn't acceptable. (i.e. If the user has specifically forced/requested a reload of data, then don't rely on the cache.)

I repeatedly told people, "This is how you get the data. I know it's slow, but it will get faster. I'll add the caching once things get a bit more stable." 

I either didn't say this loud enough, or people didn't want to hear it.

One day, the project manager decided that I wasn't doing a good enough job with the data retrieval as it was too slow, so someone else was assigned to it. I was to work on something less important. The other person had already started making the changes and my opinion or thoughts on the decision were irrelevant. A decision had been made.

Very quickly, the other developer got the caching working. Things were stable by then, and the code was clearly laid out with comments and TODOs indicating what caching had to go where and how to implement it. I'd been leaving comments and notes for myself, so I knew what still needed to be done.

When the other developer showed what they'd done, they were praised as the savior of the data access code as they had done something I hadn't (and so it was assumed I couldn't.) My competence was also questioned: why hadn't I done something the other developer could do in a seemingly quick and easy fashion?

I had assumed that getting it right and then making it fast was the way to go. 

The powers that be wanted something faster, sooner.
They were also used to things having to be changed and reworked repeatedly until they were right. The idea that anyone could get the design right the first time was anathema to them.

What went wrong:

• We weren't clear about goals and expectations.
• Communication was incomplete.
• We were working off different assumptions about what was required and what was good enough at the current stage of development.

What I'd do differently today:

• Firstly, I'd try and avoid the situation where lots of people start working on a codebase where everyone is doing different things as we all try and learn a new platform, and while the requirements were still being established.
• Be clearer about requirements and deliverables.
• Be more transparent about my progress and expected deadlines.
• Possibly, try and show something that mimics the complete final experience as early as possible. ('This part of the code shows what the final user experience will be like, but as these other parts are still in development, we haven't flipped the switch on ')
• If there's more work than can be done in the time, establish prioritisation. ('I'm deliberately not focusing on the performance yet so I can ensure everyone has the data they need and isn't blocked. Once that's done, I'll add the caching. I know how to do it, and it won't take long, but I don't want to hold other people up. Is this Ok?')

The above all happened over a decade ago but still has relevance. ;)

"We don't write design docs, we write code"

If you "don't write design docs, [but you] write code", then:

How do you know what the code is supposed to do and if it does the right thing?

AI can't tell you why the code was written

I recently heard of a new "AI" based tool for developers that can explain both what a piece of code does and why.

The claim about "why" can easily sound appealing, but it is very open to misinterpretation.

It may be possible for the tool to explain why the code works, but it can't explain why the code exists.

It can't say why this code is the best way to solve the problem it exists to address or what the person using the software is trying to achieve.

It's necessary to know more than just the code to understand why software exists and what it does for the people who use it.

I know developers (and many companies) don't want to hear it, but it's necessary to record (document) more than just the code.