html5

Web Accessibility Hacker Way

web accessibility meme

Have you heard about accessibility? Do you know what that is? Do you know what it takes to make your website accessible?

Making your website accessible means providing the ability for everyone – regardless of disability or special needs – to use it.

Unfortunately, if you put together all accessibility specifications and print it, the stack will be higher than CN Tower in Toronto:

CN Tower (Toronto)

This is not very encouraging. Many people think that it is not worth the effort because the customer base with special needs is significantly low. However, there is a thing called situational disability that applies to all of us. Moreover, when we are building our websites with accessibility in mind, we make them better for everyone. Why? Because everybody is more comfortable when allowed to fill out forms on a website using just a keyboard (without mouse) and able to switch between fields fast. Generally, everybody likes it when the focus is set on the search bar for sites because 99% of the time, the first thing you do is search for something. Everybody likes properly matched colors (accessible contrast).

How do you get started? How to survive without reading tons of specifications?

3 steps to fulfill 80% standards with 20% effort

  1. Make your website usable with keyboard only:
    • make sure that focus outline is visible all the time and user can determine which element is currently focused
    • no extra/unnecessary TAB stops
    • no tabstop traps (when you cannot get out of an element with the keyboard)
  2. Implement smart focus management:
    • set focus on appropriate elements after user actions (e.g., when a user navigates to a page with a login form – set the focus on the login text field; in 90% of the cases the next user action will be entering the login)
    • restore focus to appropriate elements after user actions (e.g., when a user closes a menu, focus should be restored to the element that was focused on before opening the menu)
    • make tab order user-friendly (remove non-actionable and non-informative tab stops)
  3. Make your website usable with screen reader:
    • When element gets focused, screen reader should provide meaningful information to the user (e.g., “image Satya Nadella” when focused on Satya’s image, or “menu collapsed” when focused on dropdown menu)
    • Min bar: make it good enough with one screen reader and one browser first. As of 2016-08-22 the best browser + screen reader combination is Firefox + NVDA (it has a text mode that prints output instead of converting it into speech: Tools -> Speech viewer)
    • Add aria tags to elements only when the screen reader cannot infer information from HTML (e.g., button element does not need role=’button’ as screen reader will infer it)

Good to know

  1. Don’t focus too much on “being compliant to the standards” at the beginning. Just use the common sense and your intuition. You can deep dive into the standards later on.
  2. Make your website’s most common scenarios work well first and focus on less popular pages later.
  3. Only 20% of accessibility requirements can be verified by tools. The rest has to be verified manually by:
    • yourself
    • user study
    • an accessibility expert

Resources to get started

Summary

If you are web developer you probably like when the tool you are using enables you to do everything without the mouse. This is thanks to keyboard accessibility, and smart focus management. If you play with color contrast analyzer you will notice that colors with good contrast are easier to read and simply just look better. Be aware that accessibility is about performance first. When your website is slow it can lead to unexpected focus behaviors, unwanted user actions, or moving content. How many times you tried to scroll to some part of website and it was moving because images were loading? I’m sure a lot.

What do you think? Is the website you are working on accessible? Have you ever even thought about it?

Accessibility all the things


Hi, I’m Jakub and I work for Microsoft

Blue badge

After I got my degree in August I moved to Redmond, WA to start my new job at Microsoft. I work for Azure App Platform Team. My official position is Software Development Engineer (SDE).

It has been a month since I started. So far, my team, work environment, the product and development process are great.

My team

MS team

My team (which is part of Azure App Platform) is working on the new Azure Portal. People in my team are smart. All of them. Moreover, they are really passionate about things they are doing, and they really care. I am working with Steve Sanderson, the creator of Knockout.js and one of the best technical speakers. The team is very diverse: people from many different countries all around the World, with a quite few girls among them.

My team is working in Agile.  The working culture is generally: “Get the job done”. People are in the office usually between 10am and 5pm. Some are coming later, and stay longer, others come early and leave early (there are also people who come early and leave late). If somebody feel the need to focus and don’t being interrupted then he/she is working from home, and it is not a problem.

What is the best, I am not implementing some spec written by somebody 5 levels above me. I need to implement an idea, add my contribution, suggest changes etc. When I asked a question what are the expectations from me, my lead and my manager told me that they expect me to suggest some ideas how to make the product better, how we can improve it, and what we are doing wrong. This is exactly what I was looking forward to!

Work environment

MS workspace

The building I am working in (Microsoft Building 44) is designed for Agile interactions. There are white boards everywhere. We work in Open Spaces (around 15 people per room). Microsoft is changing approach, and moving from private offices/cubicles to open spaces. What is cool, there are 3 conference rooms ‘attached’ to our Open Space (2 small, 1 big), and if somebody needs to work in peace, he/she can use one of them. If all are occupied (which does not happen very often), there are special ‘focus rooms’ (with desk and chair) in the building.

I have great machines to work on: HP Workstation Z420 (Xeon E5-1650 v2 3.5 GHz, 32 GB RAM, 128 GB SSD + 256 GB SSD + 1 TB SATA) with two 24″ monitors DELL Ultrasharp U2415, and Microsoft Sculpt keyboard and mouse. I have also ultrabook Lenovo ThinkPad X1 Carbon (i7-3667U @ 2 GHz, 8 GB RAM, 240 GB SSD). I have adjustable height desk, and very comfortable Haworth Zody Task chair.

The product

MS Azure Portal

The new Azure portal is a Single Page Metro Web Application. One of the main goals of the new portal is to make it easy for adding extensions. My team is working on the Framework, which is being used by other teams to create front-end for underlying Azure infrastructure. What is cool,  every extension is working as a standalone application in a separate iframe. Extension authors do not need to work with HTML and CSS a lot. They just use controls (e.g. list, combo box or checkbox) created by us, and communicate with them through TypeScript/JavaScript. Update of the view is performed by Knockout.js. Check Justin Beckwith’s post about the new Azure portal architecture. If you have not seen it yet, check the Overview of the new Azure Portal with Vishal Joshi and Scott Hanselman and Vishal and Scott create a new startup with the new Azure Portal. To get started with Azure, check my previous post, and get a free trial. Moreover, we need (and we appreciate) your feedback!

Technologies


MS technologies

We use HTML5 and LESS for our View layer. LESS is very handy in maintaining big style sheets.

We use TypeScript (which compiles to JavaScript). Strong typing, and abstraction over JavaScript inheritance (TypeScript classes) is very, very helpful in building large-scale application. To be honest, I do not know how we would be able to maintain the new Azure Portal using raw JavaScript.

Our main JavaScript Framework is Knockout.js. This allows us to prepare generic, reusable controls that can be used by other teams without the need of interaction with the DOM.

Our unit test framework is QUnit. For integration tests we use Selenium.

We use git for source control management. As Continuous Integration Server, we use Jenkins.

We have code review process supported by CodeFlow. It is required to have at least 2 reviews before code can be checked-in/pushed to the repository.

Building process is supported by MSBuild.

Behind the scenes, we use bunch of other JS libs, e.g. q.js, inject.js, d3.js, hammer.js or ZeroClipboard.js.

Summary

After 1 month I love it! There are many challenges, and interesting problems to solve. I am still new to the project, and I didn’t discover it entirely yet. What I can say now, I really like the people from my team, the software development process and work environment in my team.

Probably I will be writing about my work on this blog. Stay tuned!

MS sign


Single Page Apps (SPA): Rich Internet Apps with HTML5 and Knockout

A rich Internet application (RIA) is a Web application that has many of the characteristics of desktop application software.

We used to create Rich Internet Applications in Silverlight. Now, JavaScript frameworks (e.g. Knockout, Angular) are getting more popular for such purpose. Everything because of HTML5, which combined with them can easily provide nice development environment and rich experience.

However, all of those frameworks just take advantage of AJAX calls. So, what’s big deal?

There is a few reasons. First one is the fact, that HTML5 data-* attribute allows to bind variables to HTML elements. We do not need to select them using id or class attributes. Another reason is variety of frameworks, which makes all of those AJAX calls behind the scenes. Additionally they do lot of other work such us serializing, models binding etc. They are just higher level of abstraction than jQuery.

KnockoutJS

One of the most popular JavaScript Framework is Knockout. It applies MVVM pattern. Its key features are:

  • Declarative bindings (easily associate HTML elements with model)
  • Automatic UI Refresh (when data changes)
  • Dependency Tracking (chains of relationships)
  • Templating (easily generates UI depends on model data types) – e.g. we can use for loops in HTML

KnockoutJS is open source framework, created by Steve Sanderson.

If you want to get started with SPA I recommend you knockoutjs.com website and John Papa’s series at Pluralsight.net: Building HTML5 and JavaScript Apps with MVVM and Knockout and Single Page Apps JumpStart (in this course John is taking advantage of various JS libraries to create consistent Single Page Appliation).

The biggest advantage of all JS libraries from my point of view is the possibility to do more (functionalities) with less (code). In other words: avoid rewriting boilerplate code.

EDIT: You should also check John Papa’s HotTowel project template for Visual Studio, which gives you great start point for building SPA. It contains many JS libraries (e.g. Knockout and Durandal) for Rich Internet Apps development. More info on John’s blog. Thanks to nilphilus and Piotr Ptak for mentioning about it in comments.


The future of Mobile Apps

I think that in next 5 years Web Mobile apps will be more popular than classic Mobile apps we are using today.

Me, June 28, 2013

That is what happend in case of PCs. 10 years ago we were installing apps instead of just use them in the browser. Now we can edit Word documents, play games and even use IDE in Web Browser. I am not saying that it will be no classic Mobile apps at all, but e.g. apps like Calendar, gmail, Evernote, OneNote or games should be easilly accessible through Mobile Web Browser. The advantage of that would be lack of necessity to install bunch of apps.

What that means for developers? People who are currently working as Mobile Developers will need to learn Web Development. People who are currently working as Web Developers will need to learn Mobile Development. Additionally, future developers will not necessary need to know all different platforms (iOS, Android, WP), because they will be able to create apps in HTML5 and JavaScript (which should be well supported and compatible with Mobile Web Browsers in next 5 years).

This is my prediction. We’ll see what happens after 5 years.