Insights and Technology

<div><p>Traditionally, clients of <a href="https://www.spiria.com/en/services/">software-services</a> firms don’t realize they need help with product strategy. They believe the relationship is simply providing the vendor with a specifications document according to which the vendor then delivers a product. But that mindset is changing because there are so many instances of really awesome product releases that just don’t take off, or that do, only to become another victim of market innovation and disruption.</p><p>There is no shortage of good ideas, but most of them struggle to get traction in the market. Product strategy helps bring clarity to this problem. Product strategy will help the client understand user-experience scores and whether product features are missing the mark. It also analyzes whether the product marketing plan matches the product or whether any recent innovation is disrupting the industry. Sound product management facilitates the assessment of the current situation and the development of strategies to grow business revenue.</p><p>Strategies to get feedback from the target market earlier in the development process help improve the quality of the product. A fast-paced production space yields the best time-to-market timeframe. Though product mistakes happen, the objective of good product management is to validate assumptions sooner and to develop strategies for continuously re-evaluating how well a product is meeting market needs.</p><p>Today, product strategists are tasked with designing the appropriate focus group strategy—when to hold them, what to ask, how to ask it; and with giving operational feedback—what data to collect, what to do with it, how to put it to the best use.</p><p>In many instances, customer satisfaction scores are lower than industry benchmarks. But to discover this, a business must know what the industry benchmarks are. Product strategists can help measure customer satisfaction by identifying and prioritizing features that will improve a product. They help clients get to a place where they can make measured decisions based on the available data.</p><p>For clients that serve a diverse group of customers, product strategists can help in two ways. They create user personas and scenarios in order to better identify features that will smooth the user’s conflict; and they work on requirements that address vastly different users’ content and timing needs (early adopters versus change-averse).</p><p>Customers expect feature upgrades more frequently than many businesses can deliver them, and if a business does not react swiftly, it faces the risk of losing market share. Product strategists help navigate the business and technical aspects of a situation. They are able to identify the technical problems that the business experiences and are able to recommend solutions that can improve top-line revenues and decrease costs.</p><p>Product management consultants can be great problem-solving partners. You just need to find the right match, and then trust them. As Warren Buffett says, <i>“Price is what you pay. Value is what you get.”</i></p></div>

<div><h2>Anyone can do testing!</h2><p><i>“When you know better, you do better.”</i></p><p>Or so they say. Yes, anyone can do testing, whether you’re a designer, a developer, a PM or even a CEO. But the question is, can you do QA the way professional testers do? Can you confidently say that the product will not fall apart when released? Can you measure and quantify your work as a tester? Can you guarantee that an overall system is in place to handle complex scenarios with multiple modules? No matter who you are or what role you play, when you don the tester’s hat, you also don the mantle of responsibility.</p><p>Top-notch companies in the IT industry have <a href="https://www.spiria.com/en/services/purpose-built-development/quality-assurance-test-automation/">dedicated QA departments</a> to make sure that their products hit the market on the right foot, with as few production issues as possible, and ensuring that clients receive the best quality service.</p><h2>It’s a blame game!</h2><p><i>“It’s not a mistake to make a mistake but it is a mistake to repeat a mistake.”</i></p><p>The job of testing is often misunderstood. When an issue is found, be it the design, the back end, the front end, or the platform that don’t match requirements, it can be taken the wrong way. A tester’s job is to find defects in the system so that they can be rectified before it goes to the market. To err is human, and no-one is fail-safe; we make mistakes in our understanding, in the way we work and the way we perceive information, in the way we develop things. <a href="https://www.spiria.com/en/services/purpose-built-development/custom-software-development/">Building a product</a> is an evolutionary process that improves over time. When issues are found, they shouldn’t be taken as a personal failure; the only goal here is to build the right product and build it as a team.</p><p>Sometimes testers make mistakes as well, like missing requirements, not understanding them clearly or just overlooking a few minor things while working on the bigger stuff. Blaming doesn’t help. When everyone knows the importance of their work, owns their mistakes as a team player and works towards improvement, only then can you achieve a common goal as a team.</p><h2>Testing is boring!</h2><p><i>“No job is boring if you really know what you’re doing.”</i></p><p>In the Agile development world, where the pace never slackens, there is no time to be bored. Testing in an iterative manner doesn’t give enough time to breathe through the sprints. Working for a service-based industry, where client requirements keep on changing, moving from one project to another within a month’s time (or within a few days) doesn’t allow room to grow unless one spends dedicated time learning new tools and trying to use the tools strategically to reduce the testing overhead. There is no end to learning and today’s industry, with its demands, requires extra effort to make the job less complicated.</p><h2>Testing eats up the budget!</h2><p><i>“You must have a game plan. If you aim at nothing, you’ll hit it every time.”</i></p><p>Testing should be a selling point for companies that have plans to grow and move forward. Delivering quantity is of no use when quality isn’t there. These days, the market sees it all: cheap labor, non-standardized products that don’t withstand the test of time, unethical promotions. To sell your product on the market and to grow it to a scale where it keeps on delivering every time, you must have the courage to sell it on the premise that it’s better and workable. Testing doesn’t eat up the budget, it stabilizes the product and increases its life expectancy on the market.</p><h2>Testing is a thankless job!</h2><p>Not very often do you hear someone say that their job is thankless, but sometimes you do come across people who think that way. Systematically destroying a product that is being built in order to make it stronger, until it becomes indestructible, takes much more fortitude than building it in the first place. Testers must withstand higher pressure and stronger forces, and have less time than the builders. Reaching those quality standards takes more strength than you’d think. But in the end, nothing is more fulfilling than watching your product work seamlessly while being used by hundreds or thousands of people, making their life easier one step at a time.</p><p><i>“A lot of people tell you it’s a thankless job. I never felt that way. It was an honor for me to serve.”</i></p></div>

<div><p>I started at Spiria Toronto, formerly known as DevBBQ, in October 2015, as a junior developer within a team of 10 people. It’s been a crazy roller-coaster ride, filled with amazing people, memorable experiences and plenty of self-growth. But most importantly, it’s how I learned to become a better developer, through incremental improvement and bringing value to the company with my specific skill set. This said, as the classic Rod Stewart <a href="https://en.wikipedia.org/wiki/Ooh_La_La_(Faces_song)">song</a> goes, “I wish that I knew what I know now, when I was younger”. Here are some lessons I have learned over the past four years.</p><h2>Don’t Be Afraid To Ask For Help</h2><p>At first, I was hesitant to ask my colleagues for help. I wanted to look competent and make it seem that I had the correct solution for any particular problem. But thanks to Kevin Zych, one of my mentors, I learned early on that this notion was fundamentally wrong. Instead, the right approach is to ask for advice from a senior developer, since it leverages their knowledge to speed up your own learning process. The input of a developer who has already seen it all helps solve a problem more efficiently. Another huge benefit of asking for help is the opportunity to look at the problem from a different perspective. It’s almost as if a new neural connection forms in your brain, helping you see a path to a solution you most likely would never have thought of on your own. I was very fortunate to learn through great mentors, and develop my skills faster than I would have on my own. More recently, I have been on the other side of the fence, helping other developers solve their problems more efficiently. This, in turn, has helped me become an even better developer, with the ability to explain solutions more clearly.</p><h2>Think About A Solution Beforehand</h2><p>Although asking for help is hugely beneficial, it isn’t optimally effective if you haven’t thought of a potential solution first. Doing this legwork is just being considerate and respectful of another developer’s time, by showing that you made an attempt to resolve the issue on your own rather than asking to be spoon-fed a solution. It actually makes other developers more willing to helping you. Before I start any coding whatsoever, I develop a well-thought-out solution ahead of time, making sure it takes care of the edge cases and any future issues. Then, it’s just a question of validating my solution and putting fingers to the keyboard.</p><h2>Communication and Collaboration</h2><p>I came from a job where one person made all the decisions, which didn’t leave a lot of room for collaboration among team members. In contrast, development should really be a team effort. The ability to communicate your ideas to a group of people or even to just one colleague is a very important skill to have. Everyone, no matter who they are, has valuable information to offer and should be encouraged to speak up, whether it be explanations of estimations, solutions, requirements, or even just opinions. Moreover, taking ownership of your solutions and focusing on your effort as part of a team really pushes you to work at a high level, especially when you know that your colleagues will be reading your solution at one point or another. Learning how to communicate, with the encouragement of my peers, has helped me provide better estimations and arrive at better solutions by explaining my problems and solutions concisely.</p><p>These are some of the lessons I’ve learned as a junior developer, and I am still building on them on a daily basis! They might not be applicable all of the time, but I wish I had known them when I started!</p><p>—</p><p>Need more advice? Discover this article written by Olivier Mageau-Pétrin of Spiria Gatineau: “<a href="https://www.spiria.com/en/blog/method-and-best-practices/how-graduate-being-junior-developer/">How to graduate from being a ‘junior’ developer”.</a></p></div>

<div><p>Nowadays, it’s getting harder and harder for companies to run businesses without applications, and most of them run on servers. Back in the days, every application needed a dedicated server to run it safely and without interruption. To do so, IT needed to purchase a server powerful enough to make sure of it. But before running the application in production, no one can be sure of how much power it actually needed. For that reason, IT ended up most of the time purchasing an overpowered server that will use only 10% or less of its resources. It was a total waste of money, space and time.</p><p>Then came the virtual machines. It makes it possible to safely run lots of applications in different environments on the same physical server. A new application is no longer a synonym of a new purchase. Servers that use only a small amount of their power can finally be used fully or almost. It was a huge step forward for the IT universe.</p><p>But nothing is perfect, and there is always room for improvement. Virtual machines take a large amount of the server resources just to run. They need to simulate a physical server with all its components: CPU, RAM, disk, network card, etc. And on top of that, every VM needs its own operating system that can be a source of not only a waste of performance but also vulnerabilities.</p><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3366/vm-container.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3366/vm-container.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3366/vm-container.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3366/vm-container.png" style="width: 100%;" alt="VMs vs Containers." title="VMs vs Containers."></source></source></source></picture></p><p>Virtual machine (VM) and container. Each container uses the operating system of the host server while each virtual machine hosts its own operating system.</p><p>Therefore, years ago, the Linux universe started working on a new technology that is cheaper and faster: the containers. They can isolate an application from the outside world without the need of a dedicated operating system and a heavy software to simulate the physical components of the server. That makes it faster to run and easier to maintain. And this is not the only good thing about containers. They are so fast and small that we can use them to divide the monolithic application in several smaller services that communicate with each other. Every small service can run in its own container, separately from the others so it can be fixed and maintained without fearing to break the other parts.</p><p>Finally, containers improved most of what the virtual machines have to offer and are more adequate to the modern micro-services software architecture. But they do not replace them, in most cases, we will find them living side by side.</p><h2>Containerization systems</h2><ul> <li><a href="https://linuxcontainers.org/" target="_blank">Linux Containers</a> <ul> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxc/introduction/" target="_blank">LXC</a></li> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxd/introduction/" target="_blank">LXD</a></li> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxcfs/introduction/" target="_blank">LXCFS</a></li> </ul> </li> <li><a href="https://www.docker.com/" target="_blank">Docker</a></li> <li><a href="https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/" target="_blank">Windows Server Containers</a></li></ul></div>

<div><p>To be clear, in this context, a technology services company is one like <a href="https://www.spiria.com">Spiria</a> – a firm that delivers modern digital strategy, design, and application development.</p><h2>A wide breadth of industry exposure</h2><p>In most services companies, developers are rarely stuck working in one particular industry. Healthcare, retail, fin-tech, ad-tech, among others, are all fair game and all come with their own domain-specific expertise, constraints, and challenges. It is true that you may work on one project or with a single client for months or years on end, but typically, developers have fluctuating work assignments. There isn’t so much fluctuation that you become annoyed by the constant switching of context, but just enough to gain a breadth of exposure to different industries, domain-specific expertise, and problems to solve. Besides your own personal work assignments, there are always other projects on the go elsewhere in the company, and opportunities to draw on the experience of other employees. This exposure allows you to become more informed about industry and business needs, which make you a stronger developer able to think outside the code and solve problems more effectively.</p><h2>Never getting stale</h2><p>As a developer, exposure to technology is important. Great (or soon to be great) developers seek it out through hobby projects – open source or self-startups. Many developers have a lingering fear of becoming irrelevant as they mature in their careers. Technology moves quickly and keeping up month after month, year after year can get old for some. Being in a services company places you in an environment where, every day, like-minded people with varied skills try to solve problems in new ways, using different technologies, and with different perspectives for different industries. You’ll always have help, inspiration, and motivation to keep it fun.</p><h2>Gratification beyond commits</h2><p>My first job after graduating from a 5-year software engineering program was a development role within a services company, where I was able to gain a significant amount of interpersonal experience in a very short time. While it’s great to sit down and get your head into code space, meeting clients and having the opportunity to listen to their needs in person can be refreshing and empowering. Seeing their faces on demo days and getting an unvarnished impression of your performance as a developer from their emotional response is a validating and rewarding learning experience, whether it’s positive or negative. Software is for people, and this kind of personal gratification can exceed that of solving an engineering problem and closing off tickets.</p><h2>Thinking differently</h2><p>Because services companies are always working against project budgets, and against the clock, developers are challenged to solve problems in ways that may not be immediately obvious. For example, there are times when the easy solution may not work within the budget, and developers must figure out an alternate solution to a problem that meets both project and business needs. Developers need to think “outside the box” of available libraries to plug in, or Stack Overflow code snippets. Too often, developers are kept in the dark about the business side of things and project performance managers simply dictate timelines, with poorly-communicated reasons for crunch times or delivery dates. In a services business, on the other hand, it is not uncommon for everyone to be aware of budget status and the client’s business KPIs. This transparency, as well as seeing the effects your performance and problem solving, is engaging and motivating.</p><h2>Networking opportunities</h2><p>If you’re the entrepreneurial type, you’ll love the fact that a services company allows you to meet many different companies as they come in with many different needs and ideas. If you so choose, you can interface directly with new people looking to form partnerships with the firm, and welcome them into your network.</p><h2>Yours for the taking</h2><p>Working as a developer for a services company provides an environment with so many benefits. But it’s up to you to seize them - they are not handed out automatically. As always, you get out of it what you put into it, i.e. whatever you feel is useful for your career. The services business is a dynamic and demanding business; if you take full advantage of it, you will gain a significant boost in your career satisfaction and personal growth.</p></div>

<div><p>This article will showcase the importance of the relationship between the Product Owner (PO) and the development team, especially when the PO is an external client. The differences between working with an internal PO and an external PO are numerous, but sometimes subtle. Note that I’ll make no distinction between internal and external end-users (internal tools vs software products) in order to avoid muddying the issue.</p><p>Full disclosure: for almost a decade before co-founding Spiria, in 2003, I worked on software products with internal POs, except that back then, we just called them “product manager” or “boss”. I’ve therefore experienced both situations, and can offer some perspective.</p><h2>Playing for the Same Team</h2><p>Generally speaking, a significant difference between an internal and an external PO is the feeling that everyone’s playing on the same team: it’s <i>us</i>, the product team, versus <i>them</i>, the barbarian hordes beating down the door. The smaller the company, the greater the feeling, especially for software products. With an external PO, there’s the risk of developing an <i>us</i> versus <i>them</i> mentality, with <i>“us”</i> being the PO-Client and <i>“them”</i>, the development team-Vendor.</p><p>In my experience working with external clients, the most successful projects always had the PO and development teams working closely together, with virtually no client/vendor separation. The product team, the <em>us</em>, made concerted efforts to improve the final product, including postponing features to concentrate on reducing the technical debt, or taking shortcuts when necessary.</p><p>On the other hand, when the PO and development teams do not work together seamlessly, there’s a constant tug of war between the two. In time, the development team will become less engaged in the project’s success and will start simply following the PO’s orders. On long-term projects, quality will suffer, and project members may request to be moved to other projects, creating project waste.</p><h2>Opinions Matter</h2><p>One of the biggest misconceptions I’ve heard about working with an internal PO is that you get to work on whatever you wish. Want to switch from PHP to Node? Why not. Add a new widget? Sure! We really need admin reporting before user logins? You got it.</p><p>If the PO says yes to everything, it means they’re not doing a very good job. They should be steering the project in the right direction, truly prioritizing ideas and keeping a tight rein on the budget. Some people may find it easier to influence an internal PO because they are <i>on the same team</i>, but in well-managed companies, even internal POs have <i>budgets and deadlines</i>.</p><p>On the other hand, if the PO says no to every suggestion, they may also be doing a poor job. Of course, sometimes you need to keep the <a href="https://www.spiria.com/en/blog/custom-development/mvps-your-most-valuable-plan-to-hit-the-market-swiftly/">MVP</a>’s features under strict control, for example when a trade show is coming up. But that is the exception. Listening to the development team’s ideas goes a long way towards meshing everyone into a functioning product team.</p><h2>No Technical Debt</h2><p>I’ll admit that a younger me would have had a fit reading what follows. I used to believe that all technical debt was bad. Everything had to be engineered to be future-proof, everything had to be optimised just right, and everything had to be handcrafted just so.</p><p>In an ideal world, that may be possible. But we sure spent a lot of time refactoring code on seldom-used features! With time, I’ve come to realize that sometimes it’s okay to take shortcuts to test a feature out. It may not be as pretty as it could be, but it’s safe and won’t give you cancer – so let it go, add a refactoring story to the backlog and move on.</p><p>Once again, it’s a balancing act. In my experience, external POs tend to be a lot less forgiving about technical debt than internal POs: <i>“Why did you create this debt in the first place?”</i> I can’t stress it enough: this is near-sighted, and can result in every feature taking an inordinate amount of time to complete. If you only get one chance to code something, then you’ll want to make it squeaky-clean from the outset. Which can create waste if all you needed to do was test a feature.</p><h2>Flexible Budgets and Deadlines</h2><p>With an external PO, there’s this sense of having a finite budget, whereas when the PO and the development team are on the same payroll, there’s the feeling that the budget can somehow be more elastic. Likewise, with an external PO, arbitrary deadlines magically turn into hard dates.</p><p>It’s sad, but true. It may stem from the fact that external POs, when receiving a copy of the invoice from the development team, track projects against dollar amounts, whereas internal POs track projects against time. And because internal (arbitrary) deadlines can be changed, internal budgets appear to be more flexible than external ones.</p><p>This may have been true in the past, but nowadays, there’s increased pressure on internal POs to manage their projects with greater rigor.</p><h2>In Conclusion</h2><p>Regardless of the project, a key factor to ensure success is to have the product team (PO and development team) work together, as a single unit. Everyone needs to be aware of the deadlines, the constraints and the goals of the project.</p><p>When product teams collaborate well, technical debt is kept at a reasonable level, features are prioritized appropriately, deadlines are met, and the budget is kept in check. And this holds true whether the PO is internal or external.</p></div>

<div><p>All this makes things so much easier and convenient for automation test engineers. But does this mean that we can automate everything we want?</p><p>Yes and no: very often, automation is easier said than done. Test scenarios that were impossible to automate a few years ago can be automated now, but often at the cost of significant effort, expertise, and maybe even the developer team involvement. These factors can make it impractical to automate all testing, hence the importance of determining what test cases can and should be automated, i.e. when it’s worth it. Indeed, for some types of projects, like short-term projects, automated testing just doesn’t make sense. However, it is the driving force behind continuous delivery and agile practices.</p><p>Which brings us to the next question — what added value does an automated test scenario provide? Will it actually save everyone time? Will it give us the confidence that the delivered code works and did not break anything? This is perhaps the most crucial consideration in defining and selecting what parts of a process should be automated.</p><p>Ideally, this decision should be made by the whole team, including business analysts and budget owners. We all know that creating automated tests, like maintaining a system, is not cheap; but if it’s important from a business point of view, then you will get the necessary support to implement it. Being agile in this process is crucial: when you see that something has gone wrong, stopping to re-evaluate in the early stages of a project will save you a lot of time, effort and money down the line.</p><p>Running all-automated tests and merely checking status reports after the fact is the dream of any QA engineer. But for now, it’s a pipe dream. Even in “fully” automated processes, with a bunch of tests, responsible developers personally check functionality and code before deploying; this is called manual testing. Maybe, one day, artificial intelligence will be able to find and even fix all issues and bugs in a tested app. But for now, it remains an interesting and challenging task for us mortals.</p></div>

<div><h2>The Goals</h2><p>I recently wanted to put a combo box widget among the items of a table list. While the standard way of doing this is simple, the result was not exactly what I wanted. Seeking to improve the usual solution to make the experience more friendly for the user, I searched for ready-made solutions on the internet. While I found some ideas in the <a href="https://wiki.qt.io/Combo_Boxes_in_Item_Views">Qt wiki</a> and on <a href="https://stackoverflow.com/questions/18831242/qt-start-editing-of-cell-after-one-click">Stack Overflow</a>, there was no complete solution that worked to my satisfaction.</p><p>Now, I want to share the solution that I finally hit upon. Here’s what I wanted to do, and why:</p><p>1. <strong>I wanted to put a combo box directly in a multi-column table list widget.</strong></p><p style="margin-left: 1em;"><strong>Why</strong>: To be able to quickly change a value for an item in the list. This is actually not hard; examples can be found right in the Qt documentation.</p><p>2. <strong>I wanted the combo box to always be visible.</strong></p><p style="margin-left: 1em;"><strong>Why</strong>: So the user would know the item was directly editable. By default, Qt hides the combo box, requiring the user to double-click the item to show the combo box. Yet the average user wouldn’t necessarily figure this out, and would remain unaware that an item is editable!</p><p>3. <strong>I wanted the combo box to display its contents on the first click.</strong></p><p style="margin-left: 1em;"><strong>Why</strong>: Normally, in Qt, the first click selects the item in the list; however, with a normal combo box, the first click just displays its contents. This discrepancy means that a combo box embedded in a list works differently than a combo box outside of it, which is off-putting for the user.</p><p>4. <strong>I wanted a click on a combo box to select the table row.</strong></p><p style="margin-left: 1em;"><strong>Why</strong>: Normally, a click on a combo box is absorbed by the combo box and the row is not selected, which could confuse the user.</p><p>5. <strong>I wanted the combo box to end an item’s editing as soon as the user selects the item.</strong></p><p style="margin-left: 1em;"><strong>Why</strong>: Normally, Qt leaves the list item in editing mode until the user moves away from the item either by using the keyboard or by clicking elsewhere. Again, this is inconsistent compared to how the combo box works outside a list view.</p><h2>The Solution</h2><p>Here is how I was able to achieve all of these goals:</p><p>1. <strong>Put the combo box directly in the multi-column list widget.</strong></p><p style="margin-left: 1em;"><strong>How</strong>: Using a <code>QStyledItemDelegate</code> that creates a combo box as an editor. This is standard Qt code, as shown in the <a href="https://wiki.qt.io/Combo_Boxes_in_Item_Views">Qt wiki</a>.</p><p>2. <strong>Make the combo box always visible.</strong></p><p style="margin-left: 1em;"><strong>How</strong>: This is also standard Qt code: override the <code>paint</code> and the <code>sizeHint</code> functions of the delegate. The problem is that the exact code required is not obvious from the documentation, especially when it comes to getting the standard style. See the code sample on GitHub for details.</p><p>3. <strong>Show the content of the combo box on the first click.</strong></p><p style="margin-left: 1em;"><strong>How</strong>: This requires three tricks. First, override the <code>mousePressEvent</code> function of the table widget in order to enter editing mode on the first click. In the <code>mousePressEvent</code> function, fire up a single-shot timer that calls the <code>edit</code> function of the table widget with the selected item index (the timer is required so that the trick for selecting the row will work later on.) Second, within the <code>setEditorData</code> function of the delegate, pre-select the current item in the combo box with a call to <code>setCurrentIndex</code>. Third, again in the <code>setEditorData</code> function, call the <code>showPopup</code> function of the combo box so that it shows its contents immediately.</p><p>4. <strong>Select the table row by clicking on the combo box.</strong></p><p style="margin-left: 1em;"><strong>How</strong>: We need to simultaneously select the row and fire up the editor. That’s why we delayed showing the editor; otherwise, the row selection would interfere. So, in the <code>mousePressEvent</code> function, call <code>setCurrentIndex</code> on the table selection model.</p><p>5. <strong>End item editing as soon as the user selects the item.</strong></p><p style="margin-left: 1em;"><strong>How</strong>: In the <code>createEditor</code> function of the delegate, when creating the combo box, immediately connect to its <code>currentTextChanged</code> signal. The connected function commits the data and ends the editor. This is done by calling the <code>commitData</code> and the <code>closeEditor</code> functions of the delegate.</p><h2>The Code</h2><p>The C++ code to have a permanently displayed combo box in a table widget is available in this <a href="https://github.com/pierrebai/QtComboBoxTableWidget">public repository on GitHub</a>.</p><p>(The example is provided as a Visual Studio 2017 solution.)</p></div>

<div><h2>Rushing the start-up phase</h2><p>At the launch of a new project, nothing seems impossible! You’re experiencing a honeymoon, enjoying the novelty, the possibilities are endless, and everyone is excited. The risks, on the other hand, are not immediately apparent, and analyzing them would require precious time and effort. Yet it’s precisely at this critical juncture that they must be scrutinized, since risk management is what enables you to anticipate potential problems and adapt your plan. Which isn’t to say that you must worry about every unforeseen development; you just need to do your due diligence.</p><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.webp" style="width: 100%; border-style:solid; border-width:1px;" alt=" " title=" "></source></source></source></picture></p><p>Unexpected developments: yes, but within reason, please! © iStock.</p><p>Often referred to as “Sprint 0”, “Analysis”, “Design”, or “Discovery”, this stage, whatever you call it, is crucial to the rest of your project. This is when you do the groundwork, build solid foundations, think the project through and prepare. It includes making a list of client needs, developing the backlog of tasks to be completed, defining the criteria for stories success, developing wireframes, drafting the test plan, creating environments, completing a feasibility study or UX assessment, etc.</p><p>As with any new initiative, we naturally want to grab a project and run with it. And this natural tendency can be spurred on by tight deadlines and an even tighter budget. This is how the first stage of a project, arguably the most important, is often rushed or even skipped. This leads to a lack of overall vision and its corollary, the need to rewrite code.</p><p>It’s sort of like building a house with no plan or list of required materials. Next thing you know, you’re moving a wall, or wasting time and money making multiple trips to the hardware store and other suppliers to obtain materials at the last minute.</p><h3>Solution</h3><p style="background-color: #dadac5; padding: 9px 12px;">Our experience has shown us time and time again that before even beginning a project, you should plan on spending 15 to 20% of the total budget on the preparatory stage. It may seem like a huge investment with very little payback, but nothing is further from the truth! This investment will yield efficiency gains and code-writing savings. Try it, you’ll be convinced!</p><h2 style="padding-top: 3em;">Unforeseen code refactoring</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa-en.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa-en.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa-en.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa-en.png" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></source></source></source></picture></p><p>Adapted from <a href="https://twitter.com/johncutlefish/status/961840154385072128">John Cutler</a>.</p><p>No matter what your deadline is, any major, unforeseen technological issue will feel like a train wreck.</p><p>Refactoring is an integral part of the process at any iteration or stage of development. Refactoring consists in rewriting source code to standardize it and enhance its internal structure, without affecting the outward behaviour of the code. By definition, it excludes adding any new features or correcting bugs. It makes programs easier to understand and maintain, helps to find bugs and speeds programming.</p><p>It’s sort of like cleaning out your closets and reorganizing your drawers, to make room for new content that is easier to access.</p><h3>Solutions</h3><p style="background-color: #dadac5; padding: 9px 12px;">When building a project on existing foundations, either because you’re using someone else’s code or because the source code comes from obsolete technology, set aside time for refactoring.</p><p style="background-color: #dadac5; padding: 9px 12px;">However, even when starting with a clean slate and building from the ground up, you still have to refactor! Set aside time for refactoring early in the project, and increasingly, throughout the project, as it evolves and gains new features. Build extra time for refactoring in half-way sprints and next-to-last sprints. Our experience has shown that setting aside 10% of the time for refactoring is optimal to ensure the program remains easy to understand and to debug and maintain it. Besides, it speeds up subsequent programming.</p><h2 style="padding-top: 3em;">Last-minute, unofficial additions and modifications</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></source></source></source></picture></p><p>© Spiria.</p><p>While you might think you’ll make the client happy by going beyond the original scope of the project and accepting last-minute changes, the fact is, he’ll be very unhappy if these changes compromise the project or the budget. You need to be honest with the client, document all changes, assess each and every request, and advise the client of any adverse impacts on their budget or deadlines. Even changes with minimal impact should be documented and monitored, since a series of negligible changes can add up to a considerable impact. As they say, the beating of a butterfly’s wings can cause a hurricane.</p><h3>Solution</h3><p style="background-color: #dadac5; padding: 9px 12px;">Keep a log of changes, just like you keep a log of risks. Ideally, the change log should be on-line and accessible to the client in real-time. Then, prioritize requests so as to avoid jeopardizing the initial objective of the sprints and the project with neat but non-essential enhancements. On larger projects, change requests warrant a regular, weekly meeting, coupled with a bug- and risk-management discussion.</p><p>In conclusion, to guarantee that best practices are consistently applied in your digital project, draw on a solid experience gained over a varied project portfolio, communicate effectively and transfer knowledge, in both the development and project management aspects of the project.</p><p>I strongly recommend keeping a list of lessons learned and a historical log of problems encountered and their solutions, then sharing these learnings with the entire project community. This will support the continuous improvement of your practices and turn individual and group learning into organisational learning. In the hyper-competitive environment in which we operate, such a pragmatic approach is at the heart of any learning organisation.</p></div>

<div><h2>Reconciling family and work life</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/julien-d.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/julien-d.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/julien-d.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/julien-d.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Julien, Senior Developer." title="Julien, Senior Developer."></source></source></source></picture></p><h3>Julien, senior developer</h3><p>Sooner or later comes a time when we have to reconcile our family — and work life, to take delivery of a new appliance on a Tuesday sometime between 9 and 5, to wait for the plumber after a flood in the bathroom, to go to the dentist, to get the winter tires put on, or to take the odd sick day. Of course, anyone can take advantage of the convenience of occasionally modifying their work schedule, taking a couple of hours off and making them up another day, or working from home. But when you have children, reconciling work and family life becomes a real necessity: ferrying the children to and from daycare whittles away precious minutes; and while doctors’ and vaccination appointments can be planned ahead, not so for the mid-morning calls from the daycare asking you to pick up your kid because of gastro (again!), which he will inevitably share with you over the next few days.</p><p>Not to mention the child who needs regular appointments with the maxillofacial surgeon, the ear-nose-throat specialist, the ophthalmologist or the audiologist. Or the child with the language delay with biweekly appointments with the speech therapist. Or, if you’re really unlucky, the child with a heart problem who had open-heart surgery early in life and needs regular follow-up appointments with the cardiologist. Or all of the above, in my case.</p><p>That’s when you fully appreciate the value of an employer that allows you to reconcile your work and family life. Spiria requires its employees to be flexible, but also offers flexibility to its employees. I have taken advantage of this more than once to care for things on the home front, either adjusting my schedule or working from home to get my work done on time, with the support of my teammates. Once, I was even able to find a replacement for myself for a long-term leave, to avoid a project being late. And I’ve never been made to feel like it was a problem to be accommodated so that I can look after my family: as long as I give everyone a heads-up about a potential scheduling conflict, they’re happy to accomodate. Spiria listens, understands and offers solutions so you can get through your week or year without losing your sanity. After an especially tough year, all I can say is, thank you!</p><h2>No junior developer could dream of a better first employer</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/antoine-f.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/antoine-f.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/antoine-f.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/antoine-f.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Antoine, Developer." title="Antoine, Developer."></source></source></source></picture></p><h3>Antoine, developer</h3><p>I never thought I would do anything else than work with computers. I did not know exactly how I would do that, but I always knew, from a very early age, that they were my best friends. Technology is my first, second, third and fourth passion. It’s just a part of who I am, of my friendships, and of my life in general.</p><p>“Work” is a strange word for me, because I’ve never really felt that coding was work! It’s what I love to do, and if I can get paid to do it, what could be better? Though it’s true that coding for fun is one thing, while working for a company as a coder is quite another!</p><p>Programmers are too often perceived as a monolithic block that can be moved from area A to area B, without consideration for what their workplace does for them. Well here’s some news for you: we are not robots, and yes, we care about the office and the general vibe of our workplace! What stacks are you working on? What are your relations like with your boss? Do other coworkers like to talk and share knowledge? Are developers just numbers?</p><p>From a junior perspective, finding a job in the software industry really feels like a swipe-right swipe-left Tindr approach. First the LinkedIn message, then the email message, and so on… When it comes to a company’s image, HR departments are very good at attracting young talent with a story that does not reflect the day-to-day routine. Companies try to look like Google to attract attention, but when it comes to the daily grind, reality quickly dispels the holograph. They’ll show off their innovative stack, but once you’re in, it’s just PHP and hacky Wordpress code.</p><p>As a company, if you lie about what you’re really all about, your employees will quickly realize that they have been duped and will start looking elsewhere. You could never say straight-out to a creative developer, “We only do PHP here, so just format and fit”. We are burgeoning talent, we need challenges and stimulation or we just get bored and move on.</p><p>It’s a fact: if the company understands the software industry, your developers will be on an endless honeymoon with their job! Waking up in the morning to go to work will be the best thing that could ever happen to them. My grandmother always told me that I would be lucky to be happy at work, and I really am.</p><p>Surveys say that not many workers like their job… but I am not one of those. Every morning, I feel blessed to get out of bed and go to work. My parents spent their whole lives trying to reach the place I’m in. Being in your early twenties and happy at work is such an opportunity; it’s hard to explain, you can only understand if you experience it.</p><p>Spiria infuses creativity, passion, honesty, integrity and inclusiveness into its very essence; it’s not just an image it projects. Spiria really is what it preaches and I could not imagine being happier than under its roof. Spiria is a company driven by the love of writing software and pushing boundaries!</p><p>Thank you so much! Never could a junior dev be happier than where I am right now. From brain to &lt;3, thank you. With love.</p><h2>My voice is heard and listened to</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/jose-m.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/jose-m.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/jose-m.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/jose-m.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Jose, QA analyst." title="Jose, QA analyst."></source></source></source></picture></p><h3>Jose, QA analyst</h3><p>In 2017, during my job interview with Jean Godard and Guy Verville, I saw the company spirit in them. I saw outstanding community teams, I saw that respect and frankness were the order of the day. And it was “yes” to everything.</p><p>I asked questions: “Will I be able to develop my skills?” “Yes, we’ll support you with that.” “My French isn’t so great; can you help me with that too?” “Yes, we’ll support you with that.” “If I can show that I can contribute more to the company, will you let me do so?” “Yes, we’ll support you with that, and point you in the right direction.” All these “yeses” and especially “we’ll support you with that” were a welcome surprise, and meant a lot. I’ve found this and more at Spiria: friends, smiles, and even family.</p><p>Spiria does something that few other companies do: it hears you and listens. It motivates you to become more involved in your work, knowing that you’ll never be alone and that help is always at hand: you just have to ask. A year-and-a-half later, I can say that “Yes, we’ll support you with that” is true and going strong. There is no limit to what I can do and what I can be in this exceptional team. And I strive to help junior and senior employees alike see what I saw right from Day One.</p><p>I’d like to give my sincerest thanks to Jean Godard, Guy Verville, the QA team and project teams I’ve worked on for their support. Like I once said, “Being part of the Spiria team means thinking in different languages, smiling in different ways, while feeling good among fun colleagues and friends.”</p><h2>Fun and well-being at work</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sandra-f.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sandra-f.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sandra-f.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/sandra-f.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Sandra, project manager." title="Sandra, project manager."></source></source></source></picture></p><h3>Sandra, project manager</h3><p>When you think of it, you spend more time at work than with your family. This is why it was so important for me to find a company whose values matched mine and who gave me the opportunity to grow as a professional.</p><p>Why Spiria? For the diversity of its projects, and its service offering. One thing’s for sure: at Spiria, I will never wait for challenges! Every project is unique, both in terms of the team and the technologies used. Every digital solution truly is custom-developed for the client.</p><p>In my line of work, I like having some discretion; I like being involved in decisions and putting my stamp on a project. Spiria gives its employees this leeway. It also gives them a whole range of tools to develop their skills, like language courses, external training, workshops on personal development, “Knowledge Fairs”, etc. There’s something for everyone!</p><p>Another thing about Spiria is that it believes in “fun”. Fun and well-being at work are the byword, with a slew of social activities, “4 to fun” events, the children’s Christmas party, Mr. Ice-Cream, fresh fruit baskets, great premises, and great people! Spiria cares about your physical and mental health.</p><p>And Spiria recognizes your contribution. Be it through the internal blog, the announcement pop-ups or your manager, Spiria takes time to share successes. As for failures, we’re not afraid to talk about them, in order to avoid repeating them.</p><p>When you get up in the morning and you’re motivated to tackle new challenges, you know that you’ve found happiness.</p><h2>Accessible, attentive management</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Sergii, QA analyst." title="Sergii, QA analyst."></source></source></source></picture></p><h3>Sergii, QA analyst</h3><p>Spiria is the first company I worked for after immigrating to Canada. I was lucky enough to find this job just a few weeks after my arrival. Before working at Spiria, I worked for a company that was developing its own product, which meant that I always worked on the same project. Spiria provides a radically different experience: an Agile environment, interesting projects for clients in different industries, and the opportunity for professional development.</p><p>Working here is a fascinating experience, at a time when the company is growing fast, with a mission and a vision for the future. They are building the right structure, creating the matrix where everyone can feel that they’re contributing to something great and important.</p><p>One of the marked differences between Spiria and my previous work experience is management’s approach. When a company is growing and teams are getting bigger and bigger, it’s easy to feel lost in the crowd and forgotten. But that’s not an issue at Spiria, where managers are always available and ready to listen. They are always open to any suggestion to enhance work processes or just general morale. They hold regular meetings where you can speak, talk about professional development and the next steps, give and receive feedback, or just chat about your week-end and the fun you had. These meetings make you feel like you’re part of something and help to develop professional relations.</p><p>I also appreciate Spiria’s trust and flexibility, allowing me to work from home, to come in before or after rush hour, or to stay home in case of unforeseen circumstances. All of this helps to build trust and honesty, which motivates you to be more productive and to give it your all.</p><p>But the best part is the excitement when a project is completed. You have the wonderful feeling of having accomplished your mission, quickly followed by the anticipation of your next project, which could be even more interesting and stimulating, and that’s fabulous!</p><p>A fun working environment, high-performance equipment, employee benefits, social activities, the chance to spend time with colleagues outside of work, and many other small details all contribute to convince me that I’m at the right place. I didn’t mention the excellent coffee, or the fridge full of milk, juice and fruit, because it seems to me that you should be able to take that for granted in the office of the 21st century.</p><p>In short, I’m just a Ukrainian guy who is enjoying life at Spiria, a company that gives me everything I need to pursue my professional development and to enjoy the best years of my life.</p></div>

<div><p>There was a time when quality assurance (QA) was nothing more or less than the last safety net before <a href="https://www.spiria.com/en/services/purpose-built-development/custom-software-development/">product</a> delivery. Developers churned out code, quality assurance teams flagged anomalies, and the process reiterated. The value of QA teams was measured in terms of the number of bugs they found, and the value of a developer by the number of bugs per line of code.</p><p>Just imagine, then, the endless arguments between QA and development teams. QA would claim they’d found a bug, only to have the developers (of which I was a part at one time) argue that it was a “design intent”, so as to avoid losing points. Seems crazy now, but that’s the way it was.</p><p>Of course, as time went by, this climate of confrontation yielded to one of greater mutual understanding, though I wouldn’t go so far as to call it cooperation.</p><p>But back to today’s situation. Development best practices require the implementation of a continuous quality control process. This means that every iteration should be followed by non-regression testing. Since these tests are cumulative, they become more and more onerous as development progresses, until the QA team spends more time running non-regression tests than integration tests. The worst part is that sooner or later, the QA team will decide to stop running non-regression tests in order to secure more time for feature validation.</p><p>Yet software developers agree: the vast majority of bugs (over 80%) are introduced in the codebase at the module design and editing stages. When too much time is spent on non-regression testing, bugs are only found at the integration testing phase, i.e. late in the process, and sometimes even too late.</p><p>Keep in mind that the cost of correcting a bug increases by a factor of 30 if detected only at the end of integration testing, and by a factor of 80 if detected at the production stage.</p><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/2923/shift-left-graph-en.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/2923/shift-left-graph-en.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/2923/shift-left-graph-en.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/2923/shift-left-graph-en.png" style="width: 100%; border-style:solid; border-width:1px;" alt="Shift left testing." title="Shift left testing."></source></source></source></picture></p><p>Ideally, “shift-left testing” methods should be implemented in order to detect bugs as soon as they crop up, i.e. as the code is written. The idea is to narrow the gap between the two peaks in the graphic above (from the presentation “<a href="https://fr.slideshare.net/agilemtl/pas-dagilit-sans-qualit">Pas d’agilité sans qualité”</a>, “No agility without quality”, given by François Boretto from Askida at Agile Tour Montreal 2018).</p><p>And this is where quality assurance comes in: how can this “shift-left” be implemented?</p><p>First of all, QA analysts must be involved upstream, at the scenario development stage. Analysts must be open to, and conversant with, several different technologies, and must be involved and embedded in the development team. Management must support and encourage this approach. Further, QA teams must be released from tedious non-regression tests.</p><p>In other words, what is required is a DevOps-familiar team that masters the concept of continuous development and integration. Out with basic testers, and in with QA analysts with the skills required to assemble a list of critical functionality tests and to automate these tests. Scripts can be executed at the development stage and then again at each iteration as a non-regression test. Now, there is just one thing to consider, and that is the development of functional tests. Then, non-regression tests execute automatically at stated intervals. And it goes without saying that analysts must have the skills required to manage and maintain a test environment themselves.</p><p>In other words, the skill set required for QA is converging with that required for developers. Not only must analysts be able to test, but they also need some knowledge in coding. Chances are, manual functional tests being performed at the time of code submission will become the exception rather than the rule. But as not everything can, or should, be automated, there will always be a (marginal) need for manual testing. Consequently, testers with no automation skills are bound to become irrelevant.</p><p>My take-away from the literature I’ve parsed (<a href="https://www.quora.com/What-is-latest-technology-trends-in-Software-testing">example</a>) is that henceforth, QA teams must develop their test automation and script writing skills. By evolving in this direction, QA teams will be able to perform functional tests earlier in the development cycle without compromising the frequency of non-regression tests.</p><p style="text-align: right;">Jean Godard, Ing.</p></div>

<div><p>Currently, the requirement is that all websites published after 2013 meet Level A. The following are requirements that I found were overlooked more often than others:</p><h2>1. Semantic Markup (Level A - 1.3.2)</h2><p><i>Semantic markup</i> is a fancy term for common-sense HTML usage. Page and section headings should be wrapped with heading tags (H1, H2, etc.). H1 heading should be used only once for the page title, while H2, H3, etc. tags can be used as many times as necessary.</p><p>It is important to use a structure for headings and paragraphs to display content because screen readers often use these structured headings to pinpoint the start and end of content. If a page has no headings, users will only see (or hear) a huge wall of text with no visual break or pauses.</p><h3>The “Thematic Break”</h3><p>When formatting HTML content, context changes can be marked with a “thematic break”, represented by the HR tag. This avoids a run-on sentence, and tells the screen reader that a change of topic warrants a pause when reading through the text.</p><h3>Language Shifts</h3><p>Imagine an English-speaking synthetic voice reading French or Spanish words as though they were English words. Using a language shift ensures that content that is read aloud by assistive technology, like screen readers, will be read accurately.</p><p>Example:</p><pre><code>&lt;span lang="FR"&gt;J’aime le chocolat.&lt;/span&gt; </code></pre><h2>2. Forms &amp; Labels (Level A - 3.3.2)</h2><p>Forms should always be logical, intuitive, properly labeled, and provide clear instructions. Required fields should be indicated and form labels should be present in the code, even if they are not present in the design.</p><pre><code>&lt;label for="email" class=”hidden”&gt;Email Address&lt;/label&gt; &lt;input class="form-control" id="email" name="email" type="text" placeholder="Email Address" /&gt; </code></pre><p>A label associated with an input will be spoken by screen readers when focus is on the field. It also allows the user to click the label to activate the control.</p><h2>3. Links: Text, Color and Focus (Level A - 2.4.4)</h2><p>People using screen readers will often use a pull-out list of all the links on a page. It is important to list links contextually. For example, a list of links all labeled “click here” is weak in terms of accessibility. Instead, provide explicit links with context, such as “Download the Annual Report”. This is much clearer for users.</p><h3>Hover &amp; Active States (Level A - 1.4.1)</h3><p>The hover state of a link cannot rely on color alone to convey meaning. Color information may not be available to a person who is color-blind, and is definitely unavailable to screen reader users. Adding an underscore in addition to color will help users recognize it as a link.</p><h2>4. Including Image Descriptions (Level A - 1.1.1)</h2><p>Adding alternative text to images is often an afterthought and results in image descriptions like “image” and “filename.jpg”; users are missing out on a key feature of accessibility.</p><p>It is important to have descriptive text for users who cannot see these images. One technique to determine the alternative text of an image would be to group images in the following three categories: simple, complex or decorative.</p><h3>Simple</h3><p>These images are photographs, icons or logos, and the descriptive text should be short and sweet.</p><pre><code>&lt;img src="flowers.jpg" alt="Flowers blossoming in a garden." /&gt; </code></pre><h3>Complex</h3><p>These images are diagrams or charts, and descriptive text will be more detailed.</p><pre><code>&lt;img src="diagram.jpg" alt="Figure 1. Percentages of screen reader usage rates in Canada" /&gt; </code></pre><h3>Decorative</h3><p>These images are purely decorative with the <i>alt</i> attribute being empty and a role attribute with a value of <i>presentation</i>. This will tell the screen reader to ignore the image.</p><pre><code>&lt;img src="spacer.png" alt="" role="presentation" /&gt; </code></pre><h2>5. Keyboard Navigation (Level A - 2.1.1)</h2><p>One of the most important facets of accessibility is the ability to manoeuver through a website with just a keyboard.</p><p>Users should be able to navigate the content and elements sequentially and cohesively (Level A - 2.4.3). Adding a tabindex attribute set to 0 to an element inserts the element into the tab order based on its location in the source code. This also allows any element to be focusable.</p><p>The focus state should be present and consistent across all navigational elements (Level AA - 2.4.7). It’s good practice, when creating custom components, to use focusable HTML elements when necessary. This allows you to take advantage of the default functionality; otherwise, keyboard focus and interaction support will have to be provided manually.</p><p>Finally, adding a skip-to-main-content link allows the screen reader to skip over the menu navigation block, avoiding having to tab through every link. (Level A 2.4.1.)</p><h3>Accessibility Resources</h3><ul lang="en" xml:lang="en"> <li><a href="http://contrast-finder.tanaguru.com">Contrast Finder</a>.</li> <li><a href="https://www.powermapper.com/products/sortsite/">SortSite</a>, a one-click website testing tool.</li> <li><a href="https://webaim.org">WebAIM</a>, training, certification and assistance</li></ul><h3>Sources</h3><ul lang="en" xml:lang="en"> <li>Ontario.ca: “<a href="https://www.ontario.ca/page/how-make-websites-accessible">How to make websites accessible</a>.”</li> <li><a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility Guidelines (WCAG) 2.1</a>.</li> <li>Mozilla: “<a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Handling common accessibility problems</a>.”</li> <li>University of Washington: “<a href="https://www.washington.edu/accessibility/checklist/images/">Making Images Accessible</a>.”</li> <li>WebAIM: “<a href="https://webaim.org/techniques/keyboard/">Keyboard Accessibility</a>.”</li></ul></div>