.net, Accessibility, Non-functional Requirements, Visual Studio, Visual Studio Plugin, Web Development

How to use the Web Accessibility Checker for Visual Studio to help conform to accessibility guidelines

I’ve previously blogged about assessibility a few times and I’d love to find a good way to identify accessibility issues from my development environment. So I was really interested to see that recently Mads Kristensen from Microsoft released the Web Accessibility Checker for Visual Studio 2015. This extension uses the aXe-core library for analysing code in Visual Studio.

The Visual Studio Gallery gives some good instructions on how to install and use this extension. It’s a pretty straightforward install – once you run your website, a list of non-conformances will appear in the Error List in VS 2015 (to see the Error List, go to the View Menu and select Error List from there).

Obviously this can’t identify every accessibility problem on your site, so fixing all the errors on this list isn’t going to guarantee your website is accessible. But one of the manifesto items from aXe-core’s github page states the tool aims to report zero false positives – so if aXe-core is raising an error, it’s worth investigating.

Let’s look at an example.

How does it report errors?

I’ve written some HTML code and pasted it below…ok, it’s some pretty ropey HTML code, with some really obvious accessibility issues.

<!DOCTYPE html>
<html>
<body>
    <form>
        This is simple text on a page.
 
        Here's a picture:
        <br />
        <img src="/image.png" />
        <br />
        And here's a button:
        <br />
        <button></button>
    </form>
</body>
</html>

 

Let’s see what the Web Accessibility Checker picks up:

screenshot.1460325884

Four errors are reported:

  • No language attribute is specified in the HTML element. This is pretty easy to fix – I’ve blogged about this before;
  • The <button> element has no text inside it;
  • The page has no <title> element.
  • The image does not have an alternative text attribute.

Note – these errors are first reported at the application runtime, don’t expect to see them when your writing your code, or just after compiling it.

If you want to discover more about any of these errors, the Error List has a column called “Code”, and clicking the text will take you to an explanation of what the problem is.

In addition, you can just double click on the description, and the VS editor focus will move to the line of code where the issue is.

I’ve corrected some of the errors – why are they still in the Error List?

I found that the errors stayed in the list, even after starting to fix the issues. In order to clear the errors away, I found that I needed to right click on the Error List, and from the context menu select “Clear All Accessibility Errors”.

screenshot.1460326466

When I hit refresh on my browser, and I was able to see the remaining issues without it showing the ones that I had fixed.

What more does this give me when compared to some of the existing accessibility tools?

Previously I’ve used tools like the HTML_CodeSniffer bookmarklet, which also report accessibility errors.

screenshot.1460326977

This is a great tool, but it will only point to the issues on the web page – the Web Accessibility Checker in VS2015 has the advantage of taking your cursor straight to the line of source code with the issue.

Conclusion

Obviously you can’t completely test if a website is accessible using automated tools. But you can definitely use tools to check if certain rules are being adhered to in your code. Tools like the Web Accessibility Checker for VS2015 help you identify and locate accessibility issues in your code – and when it’s free, there’s no reason not use it in your web application development process today.

.net, C# tip, nuget, Visual Studio, Visual Studio Plugin

What’s the link between C# 6.0 language specifications, .NET Frameworks and Visual Studios?

My current work project uses the .NET framework v4.5, and we’re developing using Visual Studio 2013. I’ve been reading about the new language features of C# 6.0 for a while, and I’m really interested in finding a way to use them.

I used Bing/Google to identify what the new language features are, read some blogs and fired up my personal copy of Visual Studio 2015 to try out a few examples. The one I was really interested in was Primary Constructors, but there were a list of new features I wanted to try:

  • Primary Constructors
  • Import of static type members into namespace
  • Auto property initializers
  • Default values for getter-only properties
  • String interpolation
  • nameof operator
  • Dictionary initializer
  • Null propagator

This isn’t a comprehensive list of the new features, they’re just the ones that I think I would use most in my day-to-day coding.

The first feature I decided to try was creating a Primary Constructor…but when I wrote the code in VS2015 and .NET 4.6, it showed the dreaded red squiggly line and didn’t compile. What went wrong?

After some more research, I found that the Primary Constructor feature has been removed (at least temporarily). So those articles (for example, this one) showing me how to do this are, for now, wrong.

This made me sit back and think a bit more.

  • When I look at the dropdown list of available .NET frameworks in Visual Studio 2015, there’s quite a few (at least in my system). Which one should I be using to compile C# 6.0 language features?
  • And what does C# 6.0 actually mean? Should I be assuming that .NET Framework 4.6 necessarily corresponds to C# 6.0?
  • Can I make Visual Studio 2013 compile code written using C# 6.0 language features?
  • And where does Roslyn fit into all of this?

Some Sample Code for C# language features

I wrote a simple class which contains each of the C# 6.0 features that I listed above (except Primary Constructors, obviously). It’s a bit of a silly example, but hopefully it illustrates the point. I’ve commented each of the features, and put some of the most relevant code in bold font.

namespace CSharp6SampleApplication
{
    using System;
    using System.Collections.Generic;
    using static System.Console;

    public class SuperCar
    {
        // Dictionary initializer
        private static readonly Dictionary<string, DateTime> _specialDates =
            new Dictionary<string, DateTime>
            {
                ["past"] = new DateTime(1985, 10, 26),
                ["current"] = new DateTime(1985, 11, 5),
                ["future"] = new DateTime(2015, 10, 21)
            };

        // Auto property initializers
        public string Manufacturer { get; set; } = "DeLorean";

        // Auto property initializers
        public int TopSpeed { get; set; } = 88;

        // Default values for getter-only properties - no need to specify a private setter;
        public double Power { get; }

        public Engine Engine { get; set; }

        public SuperCar()
        {
            // Default values for getter-only properties - possible to set in the constructor only
            Power = 1.21;
        }

        public override string ToString()
        {
            // String interpolation
            return $"Made by {Manufacturer}, Top Speed = {TopSpeed}";
        }
    }

    public class Engine
    {
        public string Manufacturer { get; set; }

        public bool IsEfficient(string engineType)
        {
            // nameof operator
            if (engineType == null)
            {
                throw new ArgumentNullException(nameof(engineType));
            }

            if (engineType == "Mr. Fusion")
            {
                return true;
            }

            return false;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var car = new SuperCar();

            // Import of static type members into namespace
            WriteLine(car.ToString());

            // Null propagator
            WriteLine(car.Engine?.Manufacturer ?? "No engine type specified yet");
        }
    }
}

How it works

There’s a difference between a language specification and the version of the framework that supports it.

C# 6.0 is a language specification that is supported by the Roslyn compiler for the .NET platform. This compiler ships by default with Visual Studio 2015 – however, Roslyn doesn’t ship with Visual Studio 2013 (obviously, because this came out before Roslyn).

So all of the above code will compile and works out of the box in Visual Studio 2015, and it works for .NET framework versions 2.0, 3, 3.5, 4, 4.5, 4.5.1, 4.5.2, and 4.6 (I just haven’t included version 1.0 and 1.1 because I don’t have them installed on my machine). It doesn’t matter about the framework – it’s the compiler that matters.

Can it work in VS2013?

I think the answer to this is “partly but not really”.

When I try the above code in VS2013, the environment looks like the screenshot below, with more of the red-squiggly lines and a bunch of compiler errors.

vs2013_code

But it’s possible to compile C# 6.0 features with Visual Studio 2013 – you just need to install a nuget package. Run the code below from the package manager console.

Install-Package Microsoft.Net.Compilers -Version 1.1.1

This will now compile, but the VS2013 development environment still thinks there’s a problem – it leaves the red squiggly lines and reports the errors in the Error List window. This is because Visual Studio 2013’s real-time compiler hasn’t been replaced, and the development environment doesn’t understand the new language features. So this isn’t really a long term workable solution to develop in VS2013 with C# 6.0 language features. But you can make the code compile if you need to.

.net, Clean Code, Visual Studio, Visual Studio Plugin

VS2013 Extension (#3) – Clean your imported namespaces with Productivity Power Tools

This entry in the ‘Visual Studio Extension’ series is not really going to cover all the power tools in the Productivity Power Tools suite (which you can get here). I might blog about some of these later, but today I just want to cover what I think is a hidden gem in the suite which just doesn’t seem to get enough exposure.

Oftentimes when you inherit a legacy code-base that hasn’t been shown the love/technical review it deserved, each class header will looks something like this:

using System;
using System.Collections.Generic;
using System.Linq.Expressions;
using System.Runtime.InteropServices;
using System.Web.Mvc;
using System.Web.Mvc.Html;
using System.Linq;
using System.IO;
using Microsoft.Web.Infrastructure;
using System.Web.Mvc.Html;
using Newtonsoft.Json;

How many of these are really used?
And how many were made redundant when during refactoring?
And why are they out of order?

Ok, it’s fair to comment ‘what’s the big deal’ – they aren’t doing any harm, and when you compile the code they are removed anyway. But these unused imports are actually a big bugbear of mine.

  • If you don’t need to import some namespaces, they shouldn’t be there
  • It looks sloppy
  • It hides whether your class is obeying the Single Responsibility Principle – meaning if you’re importing lots and lots of namespaces, your class is probably doing more than one kind of thing
  • It’s so easy to fix, especially with the power tools extension.

Obviously in the usual Visual Studio IDE, you can right click on each class and fix them individually with the “Remove and Sort Usings” context command.

But why do this when you can do it at a project level, and do it for every class in the project?

And once you’ve cleaned your legacy project up, you can configure your settings so that every time you save, it cleans it up for you automatically!

You can read the Visual Studio team’s blog entry announcing this extension here.

You can watch the Channel 9 introduction to using the extension here.

.net, Unit Testing, Visual Studio, Visual Studio Plugin, xUnit

VS2013 Extension (#2) – Xunit Test Runner (plus a few issues)

Normally I use NUnit to create my unit tests.  But after looking through the ASP.net core source code for vNext, I noticed that Microsoft are now using Xunit as their unit testing tool. I’d like to follow Microsoft coding standards and practices as much as possible, so I decided to try out a move from NUnit to Xunit.

Changing the Syntax

First, the [TestFixture] decoration is no longer needed – you don’t need to decorate your test classes. This is pretty nice – I can’t think of a good reason why I should be sorry this isn’t in Xunit.

But now you don’t use [Test] as the decoration for your unit tests – these are now decorated with [Fact]. This blog gives a good explanation of the arguments for and against the revised terminology – it comes down firmly on the side of staying with [Test], but it does present the Xunit team’s reasons for the change as well.

I don’t tend to use [Setup] or [Teardown], which is lucky, because they’re not in Xunit. There are few options if you really need an equivalent – the constructor to set things up, IDispoable implementation to tear things down, and the IUseTestFixture interface which allows you to pass in a data from a your custom type and process it.

Finally, the Assert method names have changed slightly. So, for example, rather than IsTrue from NUnit, the Xunit method is just True. You can read a full list of changes here, and most of the changes are pretty intuitive.

But I did find a few wrinkles in the transition – this might be issues with my particular set up, but I’ll document them in case it helps anyone else.

Running Xunit Tests through VS2013 Test Explorer

Installing Xunit using Nuget was simple – however, I wasn’t able to run the tests out of the box in VS2013. After some searching, I found this link which correctly told me I needed to use a test runner extension. But the details on that site are now out of date so don’t install the VS2013 extension.

The preferred solution is to install the Xunit runner as a Nuget package.  I found another issue here – when I tried to install this through the Nuget tool in Visual Studio, nothing (observable) happened. I certainly didn’t see any of my unit tests appearing in the built-in VS2013 Test Explorer.  Eventually the steps I took to get this to work were:

1. Make sure that the tests are in a project which has been created using the built in “Unit Test Project” template.

2. Install the runner through the Nuget Package Manager Console, with the command:

Install-Package xunit.runner.visualstudio -Pre

After doing these things, I saw my Xunit tests appearing in the VS2013 Text Explorer.

In case the package comes out of pre-release mode, here’s the direct link to Nuget so you can get the most recent information.

Running Xunit Tests through JetBrains dotCover v2.6

I’ve got dotCover v2.6 installed on my development machine, and it can’t see any Xunit tests. Ok – this version is a bit old now, but this is a big problem for me and really makes me want to go back to NUnit or MSTest. I’ve read some posts on xunitcontrib, but this is only up to v2.5 of dotCover. I’ve also read some posts saying that Xunit support comes with an extension from the Nuget gallery – but presently the gallery URL which is supplied with dotCover v2.6 is returning a 404 error.

So presently this is not working for me.

[Update: After writing this post, I contacted JetBrains and they got right back to me to say they had addressed the 404 issue from above. So now I can download the Xunit extension to allow dotCover 2.6 see my Xunit tests.]

(I should say I’ve also tried it with dotCover v3 and it works fine out of the box).

Final Thoughts

I don’t have any compelling reason to switch to Xunit right now. I agree with the Xunit team’s reasons for not implementing [Setup]/[Teardown], but I’m able to replicate that omission in NUnit by just not using that feature.

If I need/choose to switch to Xunit at some point, I think it’ll be trivial to change.

Primarily the reason why I’m staying with NUnit is economic – I’m licensed to use dotCover v2.6 and NUnit just works. I don’t want to pay for an expensive upgrade (just yet anyway, and ReSharper Ultimate looks great).

[Update – as mentioned above, with a little help from JetBrains, I’ve managed to get dotCover v2.6 to work with Xunit. So this has reduced a major barrier for me to the move across to Xunit.

So my updated conclusion is that for new projects, I will give Xunit another try, but I’m not going to retrospectively re-factor stable and mature tests written using the NUnit framework.]

.net, Visual Studio, Visual Studio Plugin

VS2013 Extension (#1) – Unit Test Generator

As part of the series on plug-ins available for Visual Studio 2013, I’ll write a little about the Unit Test Generator.

In VS2010, we had the ability to right click on a class or method, and make the IDE scaffold a unit test. That disappeared in VS2012, but the unit test generator extension adds the feature back in.

You can download the VSIX installer from here.

Once you’ve installed it and rebooted VS, it’s simple to scaffold unit tests for your class. Just right click on the class name, and select “Generate Unit Tests” from the context menu (see below).

context menu for generate unit test

A dialog window will appear where you can choose how your unit test project is scaffolded out.

generate unit test

I prefer to:

  • Add my unit tests to a separate project to the class implementation;
  • Use NUnit (actually I’d prefer Xunit given that I now know that’s what Microsoft are using to unit test the .net core, but the xUnit test-runner doesn’t play nicely with dotCover 2.6 so until I upgrade, I’m sticking with NUnit); [Edit: I’ve blogged about this here]
  • Create a test class with the same name as my implementation, but suffixed with “Test”;
  • Create default test methods with the same name as the method under test, but again suffixed with “Test”;

But the tool lets you customize how you want to see your test appear.

Obviously it’s really easy/trivial for a developer to do all of this by hand – it’s just a time saver. But it’s a good one – if you create unit tests (and you really should), this extension will save you the grind of creating a test project, downloading your preferred flavor of unit test framework from nuget, creating a test class, stubbing out tests for your public methods.

You can read the Visual Studio ALM Rangers blog entry announcing this extension here.

You can watch the Channel 9 introduction to using the extension here.