Software Testing Strategies is NOW AVAILABLE!!!

 I realize that I am terrible at self-promotion at times but I have a very good reason to step up my self-promotion for a change.

I WROTE A BOOK!

OK, now that that's out of my system, Matt Heusser and I co-wrote a book. That's the much more honest answer but hey, my name is on the cover, so I'm claiming that credit ;).

Matt and I spent more than a year working on this project that has become "Software Testing Strategies" and its subtitle is "A Testing Guide for the 2020s". We have endeavored to create a book that is timely and, we hope, timeless. Additionally, we did our best to bring some topics that may not be in other testing books. Through several years of working on podcasts together, writing articles together for various online journals, presenting talks at various conferences, and developing training materials to deliver as training courses as well as online and in-person classwork, we realized we had enough experiences between us to inform and develop a full book.

From our Amazon listing:

Software Testing Strategies covers a wide range of topics in the field of software testing, providing practical insights and strategies for professionals at every level. With equal emphasis on theoretical knowledge and practical application, this book is a valuable resource for programmers, testers, and anyone involved in software development.

The first part delves into the fundamentals of software testing, teaching you about test design, tooling, and automation. The chapters help you get to grips with specialized testing areas, including security, internationalization, accessibility, and performance.

The second part focuses on the integration of testing into the broader software delivery process, exploring different delivery models and puzzle pieces contributing to effective testing. You’ll discover how to craft your own test strategies and learn about lean approaches to software testing for optimizing processes.

The final part goes beyond technicalities, addressing the broader context of testing. The chapters cover case studies, experience reports, and testing responsibilities, and discuss the philosophy and ethics of software testing.

By the end of this book, you’ll be equipped to elevate your testing game, ensure software quality, and have an indispensable guide to the ever-evolving landscape of software quality assurance.

Who this book is for

This book is for a broad spectrum of professionals engaged in software development, including programmers, testers, and DevOps specialists. Tailored to those who aspire to elevate their testing practices beyond the basics, the book caters to anyone seeking practical insights and strategies to master the nuanced interplay between human intuition and automation. Whether you are a seasoned developer, meticulous tester, or DevOps professional, this comprehensive guide offers a transformative roadmap to become an adept strategist in the dynamic realm of software quality assurance.

Table of Contents

1. Testing and Designing Tests
2. Fundamental Issues in Tooling and Automation
3. Programmer-Facing Testing
4. Customer-Facing Tests
5. Specialized Testing
6. Testing Related Skills
7. Test Data Management
8. Delivery Models and Testing
9. The Puzzle Pieces of Good Testing
10. Putting Your Test Strategy Together
11. Lean Software Testing
12. Case Studies and Experience Reports
13. Testing Activities or a Testing Role?
14. Philosophy and Ethics in Software Testing
15. Words and Language About Work
16. Testing Strategy Applied

Sound interesting? If so, please go and visit the link and buy a copy. Have questions? Want us to delve into some of the ideas in future articles here? Leave a comment and let's chat.

Feeding on Frustration: The Rise of the "Recruiter Scam"

 This is truly not an article I wanted to write, but my hope is my experience may help some people out there.

To put it simply, I have been applying for a variety of jobs because, well, that's what you do when you are between jobs. I have, for the past several months, been working with an organization performing training for a cohort of learners. That started at the beginning of June, and it has recently been completed. With the classes finished, I am now the same "free agent" I was in May.

Thus, it should come as no surprise that I am applying for the jobs that are being posted and that I feel might make for a good fit. Additionally, this is part of my certifying for unemployment benefits. You have to show a paper trail of the companies you are applying to and demonstrate your active job search and the results of that search. Thus, I am making several inquiries each week. It's not surprising that the deluge of messages one gets when they are actively involved in this process makes it difficult to determine what is legitimate and what might be a scam.

Last weekend, as I was working through some things while waiting in my car to get an oil change, I received a message saying that they had reviewed my application and wanted to "short-list" me for interviews and potential hiring. To help with that, they sent me a questionnaire to fill out. I've done many of these, so I didn't at first think anything of it, though as I worked my way through the questions, I started to think, "Wow, this is pretty cool. So many of these questions feel almost tailor-made for me." Part of me was getting suspicious, but I thought, "Ah, you're being that paranoid tester again. It's not like there's anything in here they're asking that weird or harmful." So I decided to submit it.

A few days go by, and I receive an email message saying, "Congratulations! We are pleased to offer you the job of Remote Quality Assurance Engineer at (Company). To facilitate a formal job offer, please provide us with the following (full name, address, phone number, and email)". Again, at first, it seemed logical, but then... hang on... if they have my resume, it already contains all of that information. Why would they need to have me send it again? Now my tester spidy sense is tingling. This is starting to feel like a scam. Do I disengage at this point, or do I see if I can catch them red-handed?

I figured, "What the heck? Let's roll with it". My name, address, phone number, and email are readily available. We can discuss if that is an intelligent practice another time. In this case, I figured, "Let's go with it."

I received an offer letter. The company looks legitimate. It's a company I applied for. The job description looks beautiful. It matches all of the items I would be looking for... all of them. Now, for anyone who has applied for a job, have you ever seen a job description that was a perfect 10/10, or in this case, a perfect 13/13? Everything felt tailor-made for me. The pay rate also felt right in the pocket. However, here's where things started to go sideways.

"We will send you a check so that you can procure the needed equipment from our preferred vendors. Once you are set up and have everything in place, we can start the necessary training and get you up to speed. We can set up the payment for this procurement by direct deposit, or we can send you a check."   

Ohhhhh, yeahhhhhh!!! Now they are feeling confident (LOL!). 

They have someone willing to give them sensitive information. Did I mention that with the signed cover letter, I was to also send them a copy of my driver's license, front and back? I understand the idea of verifying identity and ability to legally work, but that's what I-9 verification services are for. They are also secure entities. I am not sending my license details over email. With this, I was pretty certain that I had a scammer. Thus I went and did the next things that felt obvious to me. I went back to look up the company and determine if the information they were sending me was accurate. Company name? Checks out. Address? Yes, accurate. Let's do a little search on the name of the person recruiting... oh, would you look at that? There is no LinkedIn profile for this person associated with this company. Hmmm, let's see their job listings... okay, there's the Quality Assurance Engineer's job listing. A quick review... now that's interesting. These are not the same requirements they sent to me. Not only that, but that perfect 13/13 job match was now reduced to an 8/13, with a few of the requirements that I was qualified for not even in the listing, and a few additional items that were not aligned with what I was working with. Yeah, that's a lot more typical. Also, the pay rate was lower than what the scammer was advertising.

With that, I scanned to see who the company listed as their official recruiters and I reached out to them via LinkedIn and simply asked if they were familiar with the individual who contacted me and if they were aware of the odd request to send me a check to buy equipment.  The net result was that, less than an hour later, I saw a post from the company warning people to steer clear of any email communications from one "Maxwell Keen" as they were posing as a recruiter for the company but did not nor had they ever worked with them.

All's well that end's well, right? We caught the scammer, I reported them, and now that's all done, right? Maybe, but I have a feeling that this person is still out there and probably looking for their next target, so with that, consider these some quick safeguards you an take.

- If you need to keep track of your job search, create an intermediate table in Excel or elsewhere that stores the information about the job and who you are communicating with, if possible. At the very least, review the job descriptions on LinkedIn and on their site and verify that they match.

- If there is a contact information space, note it down, especially if there is a contact person with a phone number. You don't need to contact them immediately, but you will want this information should you receive a reply back.

- Getting a questionnaire is fairly standard but it also makes it easy to "cheat" and write down the answers you search for. Again, it's not the most red of flags but I'd argue it's also not very helpful so be leery of anyone sending these and not asking for a phone call/screening.

- If you get an offer for a job where there has been no interview or phone screen or a direct conversation with a human being (either over Zoom or in person), expect that this is probably a scam of some sort. Otherwise, how are they vetting these people?

- Look to make sure that, if you receive an offer letter, there are no misspellings in the document. It's a simple thing, and perhaps petty, but offer letters have a fair amount of boilerplate text for legal purposes. Any legal document will be fine-toothed for any grammatical errors or misspellings. There may be some grammar variation but misspelled words should automatically give you pause.

- Any reputable company will either work with you to set you up with VPN or other security details to use your equipment as is or they will ship you out a system set up with the software they expect you to use. Being asked to receive a check to procure equipment is an indication that something illegal or shady is happening.

- References are something worth having and including upon request. as my friend Timothy Western pointed out, though, if they are asking for them too quickly or at the very beginning of the process, hold off on providing those. They may be harvesting that information from your references to target them. 

Some additional items you can do that should help determine if you are dealing with a reputable recruiter or a scammer:

- Look up recent news about the company to understand its current market and technical position and future outlook. Discussing the latest product launches, partnerships, or corporate changes can help flush out what they know or don't know about the company.

- Read up on employee testimonials on sites like GlassDoor and see if they match what the recruiter is telling you. While this may not necessarily tip you off if they're a scammer, it will help give you some inside perspectives on working conditions and employees' perspectives on their work culture.

- If possible, try to connect with current or past employees who can offer firsthand insights into the company. definitely see if there is a secondary recruiter there who can at least confirm the interactions you are having.

- If publicly available, review financial reports to assess the company's stability. Ask them some questions to determine what they might know and if their answers corroborate or refute your findings. 

Finally, make sure that everything you see in any communications can be traced back to interactions you initiated and make sense/match the experience you started with. 

Do not trust. Absolutely verify. 

Many of us are struggling with the reality of needing to find work. Let's do what we can to stop these parasites from making this already challenging search even more so.

Empathy is a Technical Skill With Andrea Goulet (PNSQC)

 

Today has been a whirlwind. I was up this morning before 5:00 a.m. to teach the penultimate class of my contract (sorry, I just love working that word into things ;) ) but suffice it to say the class is still happening while PNSQC is happening. That has made me a little tired and thus a little less blogging today. Add to that the fact I was called in to do a substitute talk in the afternoon (glad to do it but that was not on my dance card today) and I'm really wondering how we are at the last talk of the day and formal conference. regardless, we are here and I'm excited to hear our last speaker.

I appreciate Andrea talking about this topic, especially because I feel that there has been a lot of impersonal and disinterested work from many over the past several years. I was curious as to what this talk would be about. How can we look at Empathy as a technical skill? She walked us through an example with her husband where he was digging into a thorny technical problem that was interrupted by Andrea asking him for a moment. His reaction was... not pleasant. As Andrea explained, she realized that he was deeply focused on something so all-consuming that it was going to be a big deal to get his attention for needful things. Instead of it being an ugly altercation, they worked out a phrase (in this case, "Inception") to help see when a person is on a deep dive and needs to be in their focused state, at least for a little while longer. While I don't quite know that level of a dive, I have times in my own life when I get caught up in my own thoughts and I bristle when someone interrupts/intrudes. By realizing these things, we can not just recognize when we ourselves are focusing on deep dives, but we can also recognize when others are as well. This is a development of our own empathy to aid us in the process of understanding when people are dealing with things.

Okay, that's all cool, but why is this being called a technical thing? Because we are free and loose with the use of the word "technical". Technical comes from the Greek word "Techne", and techne means "skill". That means any skill is technical when we get down to it. It also means it's a skill that can be learned. Yes, we can learn to be empathetic. It's not something we are born with, it's something we develop and practice. Motivation likewise drives empathy. In many ways, empathy can be a little mercenary. That's why we get it wrong a lot of the time. We often want to reach out and help in ways that we would want to be helped, and thus our empathy is highly subjective and highly variable. Additionally, empathy grades on a curve. There are numerous ways in which we express and experience empathy. it's not a monoculture, it is expressed in numerous ways and under different circumstances and conditions. There are a variety of components, mechanisms, and processes that go into our understanding and expressions of empathy. It's how we collaborate and solve complex problems. In short, it's a core part of our desire and ability to work together.

Andrea showed us a diagram with a number of elements. We have a variety of inputs (compassion, communication) that drive the various mechanisms that end up with a set of outputs. Those outputs come down to:

• Developing an understanding of others 
• Creation of Trust
• A Feeling of Mutual Support
• An overall synergy of efforts   

 Empathy requires critical thinking. It's not all feelings. We have to have a clear understanding and rational vision of what people want, and not specifically what we want. 

On the whole, this is intriguing and not what I was expecting to hear. Regardless, I'm excited to see if I can approach this as a developed skill.

Automation, You're Doing It Wrong With Melissa Tondi (PNSQC)

This may feel a bit like deja -vu because Melissa has given a similar talk in other venues. The cool thing is I know each time she delivers the talk, it has some new avenues and ideas. So what will today have in store? Let's find out :).

What I like about Melissa's take is that she emphasizes what automation is NOT over what it is.

I like her opening phrase, "Test automation makes humans more efficient, not less essential" and I really appreciate that. Granted, I know a lot of people feel that test automation and its implementation is a less than enjoyable experience. Too often I feel we end up having to play a game of metrics over making any meaningful testing progress. I've also been part of what I call the "script factory" role where you learn how to write one test and then 95 out of 100 tests you write are going to be small variations on the theme of that test (login, navigate, find the element, confirm it exists, print out the message, tick the pass number, repeat). Could there be lots more than that and lots more creativity? Sure. Do we see that? Not often.

Is that automation's fault? No. Is it an issue with management and their desire to post favorable numbers? Oh yeah, definitely. In short, we are setting up a perverse expectation and reward system. When you gauge success in numbers, people will figure out the ways to meet that. Does it add any real value? Sadly, much of the time it does not.   

Another killer that I had the opportunity to work on and see change was the serial and monolithic suite of tests that take a lot of time to run. I saw this happen at Socialtext and one of the first big initiatives when I arrived there was to see the implementation of a docker suite that would break out our tests into groupings split into fours. Every test was randomized and shuffled to run on the four server gateways. We would bring up as many nodes as necessary to run the batches of tests. By doing this, we were able to cut our linear test runs down from 24 hours to just one. That was a huge win but it also helped us determine where we had tests that were not truly self-contained. It was interesting to see how tests were set up and how many tests were made larger specifically to allow us to do examinations but also to allow us to divvy up more tests than we would have been able to otherwise. 

Melissa brought up the great specter of "automate everything". While granted, this is impossible, it is still seen forlornly as "The Impossible Dream". More times than not, it's the process of taking all of the manual tests and putting them to code. Many of those tests will make sense, sure, but many of them will not. The amount of energy and effort necessary to cover all of the variations of certain tests will just become mind-numbing and, often, not tell us anything interesting. Additionally, many of our tests that are created in this legacy manner are there to test legacy code. Often, that code doesn't have hooks that will help us with testing, so we have to do end runs to make things work. Often, the code is just resistant to testing or requiring esoteric identification methods (the more esoteric, the more likely it will fail on you someday). Additionally, I've seen a lot of organizations that are looking for automated tests when they haven't done unit or integration tests at lower levels. This is something I've realized having recently taught a student group to learn C#. We went through the language basics and then later started talking about unit testing and frameworks. After I had gone through this, I determined if I were to do this again, I would do my best to teach unit testing, even if at fundamental levels, as soon as participants were creating classes that processed actions or returned a value beyond a print statement. Think about where we could be if every software developer was taught about and encouraged to use unit tests at the training wheels level!

Another suggestion that I find interesting and helpful is that a test that always passes is probably useless. Not because the test is necessarily working correctly and the code is genuinely good but because we got lucky and/or we don't have anything challenging enough in our test to actually run the risk of failing. If it's the latter, then yes, the test is relatively worthless. How to remedy that? I encourage creating two tests wherever possible, one positive and one negative. Both should pass if coded accurately but both approach the problem from opposite levels. If you want to be more aggressive, make some more negative tests to really push and see if we are doing the right things. This is especially valuable if you have put time into error-handling code. The more error-handling code we have, the more negative tests we need to create to make sure our ducks are in a row.

A final item Melissa mentions is the fact that we often rely on the experts too much. We should be looking at the option that the expert may not be there (And at some point if they genuinely leave, they WON'T be there to take care of it. Code gets stale rapidly if knowledgeable people are lost. Take the time to include as many people as possible in the chain (within reason) so that everyone who wants to and can is able to check out builds, run them, test them, and deploy them.

Continuous Testing Integration With CI/CD Pipeline (PNSQC)

Today, I'm taking a walk down memory lane. I'm listening to Junhe Liu describe integrating various automatic tests into the CI/CD pipeline.

It's interesting to think about where we are today compared to 30 years ago when I first came into the tech world. Waterfall development was all that I or anyone knew (we may not have wanted to call it that, or we'd dress it up. Realistically speaking, any given release was a linear process, and each sequence flowed into each other. While I had heard of Agile come the early 2000s, I didn't work on such a team (or one that presented itself as such) until 2011. 

Likewise, it was around the mid-200s that I started hearing the idea of Development and Operations being two great tastes that went better together being discussed ;). Again, it wouldn't be another decade until I saw it in practice but over time, I did indeed start to see this and I was able to participate in it. 

One of the interesting arrangements in the group I was working at (Socialtext), every member of the team had their turn at being the "Pump King". That's a piece of lore that I miss and it is a long story involving an old USB drive that was kept in a toy jack-o-lantern bucket, hence the person who took care of the protective pumpkin became known as the "Pump King" and after everything went online, the name stuck. The key point was that the Pump King was the person responsible for the Jenkins system and making sure that it was working, up to date, and patched when necessary, as well as running it to build and deploy our releases. Every few weeks, it would be my turn to do it as well. 

Thus it was that I was brought into the world of Continuous Delivery and Continuous Deployment, at least in a limited sense (most of the time this was related to staging releases). We actually had a three-tiered release approach. Each developer would deploy to demo machines to test out their code and make sure it worked in a more localized and limited capacity. Merging to the staging branch would trigger a staging build (or the pump king would call one up whenever they felt it warranted, typically at the start of each day. We'd run that and push changes and version numbering to our staging server, and then we'd run our general tests, as well as all the underlying automated tests with the Jenkins process, of which there were a *lot* of them. Finally, due to our service agreements, we would update our production server and then push uploads to customers who opted in to be updated at the same time. We never go to production daily pushes but weekly was more common towards the end of my time on that product.   

It was interesting to get into this mode and I was happy that we were all taught how to do it, not just one and when needed but that all of us were expected to be able to do it at any time. Thus all of us knew how to do it and all of us were expected to do it every time it was our turn to be Pump King. 

Learning, Upskilling, and Leading to Testing (Michael Larsen with Leandro Melendez at PNSQC)

You all may have noticed I have been quiet for a few hours. Part of it is that I was giving a talk on Accessibility (I will post a deeper dive into that later, but suffice it to say I shook things up a little, and I have a few fresh ideas to include in the future).

Also, I was busy chatting with our good friend Leandro Melendez (aka Señor Performo), and I figured it would be fun to share that here. I'm not 100% sure if this will appear for everyone or if you need a LinkedIn login. If you can't watch the video below, please let me know.

 

We had a wide-ranging conversation, much of it based on my recent experience being a testing trainer and how I got into that situation (the simple answer is a friend offered me an opportunity, and I jumped at it ;) ). That led to talking about ways we learn, how we interact with that learning, and where we use various analogs in our lives. This led us to talk about two learning dualities I picked up from Ronald Gross' "Peak Learning" book (Stringers vs. Groupers) and a little bit about how I got into testing in the first place.

It's a wide-ranging conversation, but it was fun participating, and I hope you will enjoy listening and watching it :).

Common Pitfalls/Cognitive Biases In Modern QA with Leandro Melendez (PNSQC)

Ah yes, another date with the legendary Señor Performo :). 

Leandro is always fun to hear present and I particularly liked the premise of his talk as I frequently find myself dealing with cognitive biases, both in the way of locating them when others use them but also to admonish myself when I do (and yes, I do fall prey to them from time to time). 



I've been in the process of teaching a class for the past few months related to software test automation, specifically learning about how to use a tool like Playwright with an automated testing framework. To that end, we have a capstone project that runs for three weeks. As anyone involved in software development knows, three weeks is both a lot of time and no time at all. This is by design, as there is no way to do everything that's needed, and because of that, there are things that we need to focus on that will force us to make decisions that will not be optimal. This fits into the conversation that Leandro is having today. How do you improve and get better when you have so many pressures and so little time to do it all? 

Note: I am not trying to throw shade at my students. I think they are doing a great job, especially in the limited time frame that they have (again, by design) and seeing what choices they make (as I'm literally a "disinterested shareholder" in this project, meaning I care about the end product but I'm trying my level best to not get involved or direct them as to what to do. In part, it's not the instructor's role to do that but also, I'm curious to see the what and the why concerning the choices that are made).

We often act irrationally under pressure and with time limitations. Often we are willing to settle for what works versus what is most important or helpful. I'm certainly guilty of that from time to time. An interesting aspect of this, and one I have seen, is the "man with a hammer" syndrome, where once we have something we feel works well, we start duplicating and working with it because we know we can have great wins with that. That's all well and good but at times, we can go overboard. Imagine that you have an application with navigation components. You may find that many of those components use similar elements, and with that, you can create a solution that will cover most of your navigation challenges. The good thing? We have comprehensive navigation coverage. The disadvantage? all of that work on Navigation, while important and necessary, has limited the work on other functionalities with the unit under test. Thus, it may be a better use of time to do some of the navigation aspects and get some coverage on other aspects of the application rather than have a comprehensive testing solution that covers every navigation parameter and little else to show for it. 

Another example that Leandro gives is "Living Among Wolves" or we can consider this an example of "conformance bias" meaning that when we do certain things or we are part of a particular environment, we take on the thinking of those people to fit in with the group. Sometimes this is explicit, sometimes it is implicit, and sometimes we are as surprised as anyone else that we are doing something we are not even aware of. 

The "sunk cost" appears in a lot of places. Often we will be so enamored with the fact that we have something working that we will keep running and working with that example as long as we can. We've already invested in it. We've put time into it, so it must be important. Is it? Or are we giving it an outsized importance merely because we've invested a lot of time into it? 

One of the lessons I learned some time back is that any test that never fails is probably not very well designed or it offers little value in the long run. It's often a good idea to approach tests both from a positive and a negative perspective. It's one thing to get lucky and get something that works in a positive/happy path test (or not necessarily lucky but limited in what's being done. Now, does your logic hold up when you inver the testing idea? Meaning can you create a negative test or multiple negative tests that will "fail" based on changing or adding bogus data or multiple bogus data examples. Better yet, are you doing effective error handling with your bogus data? The point is, that so many of our tests are balanced to only happy path, limited depth tests. If you have a lot of positive tests and you don't have many tests that handle negative aspects (so that the incorrect outcome is expected... and therefore makes a test "pass" instead of fail), can you really say you have tested the environment effectively?   

Ending with a Shameless plug for Leandro. Leandro is now an author, having written "The Hitchhikers Guide To Load Testing Projects", a fun walkthrough that will guide you through the phases or levels of an IT load testing project. https://amzn.to/37wqpyx

Amplifying Agile Quality Practices with Selena Delesie (PNSQC)

I had the opportunity and privilege to introduce Selena Delesie on the program today. It was fun to reminisce a bit because Selena and I were both in the same Foundations class for Black Box Software Testing all the way back in 2010. We also both served on the Board of Directors for AST, so we had a lot of memories and fun/challenging things to deal with over the years. Thus, it was a pleasure to introduce Selena as our first Keynote speaker. Also, part of her talk was discussed on a recent The Testing Show podcast, so if you want a sample, you can listen to that :).

The tool that Selena and Janet Gregory put together is called the Quality Practices Assessment Model (QPAM). The idea behind this is that there are ways to identify potential breakdowns in the quality of our work. Areas we should consider are:

• Feedback Loops
• Culture
• Learning and Improvement
• Development Approach
• Quality and Test Ownership
• Testing Breadth
• Code Quality and Technical Debt
• Test Automation and Tools
• Deployment Pipeline
• Defect Management

The fascinating thing is the order and how these are identified and examined. Selena makes the case that the order in which these are presented and examined is important and by examining them in this order or weighting, the best chances for overall and lasting improvement are possible. Yes, Defect management is important but it will be less effective if more weight is not given to the previously mentioned items.

A key aspect to this is that quality is not just a technical issue, it's also a social issue and it should not be dealt with in isolation. Selena introduces us to a group code-named "Team Venus" and identifies many of the issues they are facing and where those issues fall on the ten quality aspects. The key element is that each area is looked at holistically and in conjunction with the other areas, not in isolation. As anyone familiar with GeneralSystems Thinking can tell you, there is no such thing as a standalone and isolated change, any modifications made will have ripple effect. It's also critical to realize that a process alone is meaningless if the overall values are not solid or agreed upon. 

In the ten quality aspects that Selena referenced, there are four quadrants/dimensions to consider:

• Beginning
• Unifying
• Practicing
• Innovating

What I like about considering these as quadrants is the fact that these areas are not separate from each other but they are dependent on each other. Some areas of the ten practices will be closer aligned with a particular dimension. Additionally, it's common for teams to spend more time in a given quadrant/dimension for the ten areas than others. I like the diagram Selena uses that looks like a spider web. The center of the web means that that is an informational or foundational level, and the farther out from the center, the greater the expertise and experience. Ideally, of course, all of the aspects should be on the outer rim of the spider web but in practice, there will be color splotches in all four of the dimensions. That is normal and should not be discouraged, especially since each new team member will typically need to start from zero.

For those interested, the book and full model example for Team Venus is available in "Assessing Agile Quality Practices with QPAM" so if you want to learn more, go there.

Amping It Up!: Back at the Pacific Northwest Software Quality Conference

 

It's that time of year once again. I'm excited to be at PNSQC and in a new location. We are at the University Place Hotel and Conference Center, which is part of Portland State University. This is the first time PNSQC has been here but not the first time I've been here. A few years back, in 2018, they had run out of rooms at the primary hotel, so I had to find someplace else to stay. 

I happened upon University Place, and while it was a walk from the previous venue at the Portland World Trade Center, it was a comfortable hotel, and I liked my stay. As we were looking for different places to hold the conference this year I mentioned my experience and thought it would make for an excellent possible venue. And thus, here we are. It wasn't solely up to me but I definitely put in a good word ;).

This year's conference is a strange feeling for me, as it is one in which I am feeling unsure and unsteady after many years. I am at the tail end of a contract I've been working for several months. In a few weeks, barring any changes or new contracts, I will be out of work again. Thus I am attending this conference from a different headspace than usual. Previously, I was looking for small tips I could bring back to do my current job. This year, part of me feels the need for a literal reinvention. I'm having that uneasy feeling that I have too many potential options and not enough time to consider them all, so this year's talks are probably going to be focused on my current mental state. If you see me attending talks that may seem different or out of character, that's why.

Additionally, this year had an additional challenge and excitement in that I was the Marketing Chair for PNSQC this year. If you felt that there was either too much or not enough of a marketing presence for the conference, I get both the praise and/or the blame. Either way, for those who are here and for those following along, I'm happy you are here.

   

The Different Dimensions of Accessibility: Cognitive: Training for Accessibility (Part 6)

While often overlooked, cognitive disabilities are perhaps one of the most common yet least seen of the disability families we have discussed. Cognitive disabilities are varied and present some challenges that can affect how navigate and interact with online content. 

word cloud for cognitive disabilities: words include cognitive, disability, area, attention, experience, fatigue, Hemingway, memory, situation, stress, user

Cognitive disabilities cover a broad range of conditions. Memory, attention, comprehension, and problem-solving are all affected, and for some people, all of the boxes are checked. 

Primary Disabilities

Down Syndrome: a genetic condition where people have an extra copy of chromosome 21. Cognitive impairments, delayed development, and distinctive physical features are often seen in this condition. Levels of cognitive impairment can vary from mild to severe.

Dyslexia: a learning disability that can affect reading, spelling, and language comprehension. They may swap letters or read certain characters out of order or need to step back and slowly read the text to process what they are seeing.

Dyspraxia: Also referred to as Developmental Coordination Disorder. While often considered a mobility disability, dyspraxia can also have an effect on the actions of writing and typing and cause stress to cognitive functions as well.

Traumatic Brain Injury: A sudden impact to the head such as a concussion or bone breakage in the skull can cause long-term issues with memory, attention, and problem-solving.

Fetal Alcohol Spectrum Disorders: people exposed to pre-natal alcohol in high amounts during their development in pregnancy can develop a range of disabilities. these can affect memory, attention, impulse control, and social skills.

Secondary/Situational Disabilities

Cognitive disabilities are perhaps one of the areas where situational disabilities may be the most prevalent. There are numerous situations that can put a strain on our mental faculties and can cause us issues that are not necessarily long standing. Many of these share similarities but these are all situations any of us could find ourselves dealing with.

Cognitive Overload: stressed, fatigue, or just having a million things coming at us all at once. These situations can make it more difficult for us to process information and make decisions.

Reduced Attention Span: again, stress and fatigue can contribute to this, as well as side effects of medication or recreational alcohol or drug consumption. 

Memory Impairment: there can be a lot of situations that lead to this. Again, stress and fatigue but also just being in an unfamiliar or foreign environment, especially one where the language that is spoken/written is foreign to you. 

Design Considerations for Cognitive Disabilities

When we want to address Accessibility and accessibile design for cognitive issues, it's important to realize that each area is unique, and individuals within these categories can have varying strengths, challenges, and needs. This is definitely the area where one size will not fit all and a lot more judgment calls are required. Still, here are several suggestions that should help considerably and make the experience better for all users.

Avoid Complex Navigation: having multiple layers of nested content or menus of menus is not ideal. It's easy to lose track of where a user is and then trying to get back to that location could be challenging if not impossible. Try to limit menus to one layer at maximum if possible.

Avoid Overwhelming With Information: A wall of text is not welcoming to anyone and for people with cognitive disabilities it is even more daunting. Try to use space, break up large paragraphs, and aim for a simplicity of message where it makes sense. 

Allow for Longer Time Limits: Aim to make it so that timers or time pressures are minimized. Some systems require this but make it so that the value can be adjusted reasonably

Provide Alternative Means for Content Display: Have clear labels and do not assume that users will get by inference what is meant by using a color in isolation or a metaphor that may be well known but some people may not be aware of that meaning. Provide clear labels and alternatives that will provide more context if necessary.

Avoid High Contrast or Flashing Content: this is an example of where a suggestion that works well for one group could be a distraction or a problem for another. High contrast screens that help those with vision issues could be too stressful to read or look at for people with cognitive disabilities. Having the ability to easily adjust the contrast can be a big help. Overly aggressive flashing and strobing is just a bad approach overall, IMO.

Use fonts that are not overly busy or decorative: font choice can have a profound effect o the readability of online text and for people with cognitive issues, overly fancy fonts can be a struggle to read. aim to make sans-serif fonts and typical typefaces a standard or make it easy for these typefaces to be selected. 

Write For Everyone (and Learn to Love Hemingway): this is perhaps one of my favorite cognitive tools to use, the Hemingway Editor. I get occasional raised eyebrows when I mention that I think of Hemingway as an Accessibility tool but I really see it as such. Hemingway is designed to help you improve writing from a clarity standpoint and also to help fix/avoid overly complex prose or impenetrable walls of text. You can also set a reading comprehension level and see how well your writing falls into that level (or doesn't).

As I stated at the beginning, cognitive disabilities are perhaps the most common and also the most neglected because we don't necessarily "see' them. Understanding how many there are and how varied they are, we can see a lot of areas that we can do better and can look out for to help make the experience of being online and using digital products better and more usable. Again, it doesn't take much in this stressful and fast-moving world to feel overwhelmed. These additional Accessibility features might be the ticket to making better interfaces and experiences for all of us.

The Different Dimensions of Accessibility: Mobility: Training for Accessibility (Part 5)

 When we think about accessibility and people with disabilities, mobility is the area that we are most familiar with and the most obvious of disabilities. We also refer to these as physical or motor disabilities. Most of the accessibility options that we see in public and in infrastructure are specifically for mobility disability. This is also the disability family we are most familiar with and can most readily see. 

Word cloud related to mobility and motor disabilities.

There are many aspects that create unique challenges when it comes to mobility disability. On one hand, you could have someone with paralysis from the waist down with a spinal injury. this person will need to use a wheelchair to get around but they have full use of their arms, hands, and fingers, as well as eyesight and hearing. In the digital world sense, they are as able-bodied as anyone else. That is not the case for a person with severe arthritis, cerebral palsy, or paralysis that includes their arms or hands. In addition, limb amputation or missing limbs or parts of limbs create challenges in interacting with devices. 

Primary/Persistent Mobility Impairments

There are various mobility or motor disabilities that fall under the category of primary or persistent issues. 

Spinal Cord Injury: Individuals with spinal cord injuries may experience paralysis or limited mobility in their limbs. This can range from paralysis in their legs only but full control of arms, torso, hands, neck, etc., and then variations that also include fingers, hands, arms, neck, etc. 

Cerebral Palsy: Cerebral palsy is a neurological condition that can result in difficulty with moving or coordinating limbs and extremities. Fine motor control or the ability to use fingers independently may be limited or not possible. 

Muscular Dystrophy: This is a range of genetic conditions that often result in muscle weakness or limited dexterity due to difficulty in movement. It's a progressive condition that gets worse over time.

Multiple Sclerosis: This is a disease caused by an attack on the central nervous system, specifically the myelin that coats the nerves. It can impact the brain, spinal cord, and optic nerves. MS is an issue for visual and cognitive disabilities as well as mobility.

Arthritis: This is inflammation and pain in the joints. Holding onto items or typing on individual keys with multiple fingers or moving around and navigating a touch screen can be painful.

Amputation: A loss of limbs due to amputation is a significant issue when it comes to inputting information or navigating on systems, especially those designed around a keyboard and mouse or touch screens. 

Tremors/Convulsions: Tremors can be caused by a number of conditions, Parkinson's Disease being a common and well-known example. This makes fine movements or steady controlled touch or sliding motions challenging.

Secondary/Situational Mobility Impairments

Injuries: fractures to the arm, hand, or fingers can hinder the ability of an individual to perform tasks that they might otherwise be able to were they not injured. The same goes for post-surgical procedures. These are situations that can render our extremities in a limited range of motion or in some cases no motion at all. On the plus side, we may be back to normal in a few weeks or months but during that injury/recovery period, we may have little to no use of our arms, hands, or fingers.

Otherwise Engaged Hands:  This may sound silly but numerous situations would fall into the category of secondary or situational "mobility impairment". Some of these situations could be as temporary as "my hands are full" or "I'm driving a vehicle". We don't often think of these as impairments but they are situations where the user may not be able to use their hands or otherwise interact with a product when necessary. 

Adapting to Mobility Issues

There are a range of methods to work with that will allow individuals who have mobility issues to better interact with their devices. There are numerous examples of methods and tools that can help with mitigating mobility issues such as:

Alternative Input devices: These can range from joysticks, to blow tubes, to software that tracks eye movement, to capacitance devices that can be held in the mouth, to large button arrays that will allow individuals to more effectively press and order button pushes to enable certain command sequences.

Voice Recognition Software: In certain cases, controlling the system with voice directives will allow hands-free operation. Additionally, screen readers can also be helpful with mobility accessibility.

Ergonomic devices: These can be specialized or split-level keyboards, larger buttons, or alternative layouts. Large trackballs are also commonly used as input devices where using a mouse would not be possible.

Some additional factors worth considering are:

- Make it possible for actions that can be clicked to have large buttons on the screen or to have the ability to access via the keyboard (press Tab to highlight the item and press Enter to perform the desired button click)

- make it possible to allow for multiple keystrokes to be seen as a more complex action or one where the need to hold down multiple keys simultaneously can be performed in another manner.

- use dictation software or other means to allow the user to speak workflows and have the system respond to them.

- provide space on the screen so that form fields can be accessed and do not require the user to have to pinpoint exactly where they need to focus their attention.

- ensure that workflows can be accomplished without the need for a mouse or multiple nested steps.

- make it possible for users to set longer timeouts if they are needed at all as many mobility issues may require a longer time to accomplish the steps necessary.

Individuals with mobility or motor disabilities can have a variety of issues and therefore may need to have a variety of tools to enable them to perform key tasks and interact with online content. It may be a challenge to have a testing situation where all of the possibilities can be tested but there are many ways to simulate these scenarios. It may take some creativity and imagination but I strongly encourage modeling and thinking about how someone would interact with your systems and applications were they unable to have full use of or full control of their hands. Learning to adapt to and putting yourself into these situations will likely provide you with many suggestions you can bring back to the design and code teams to help ake these interactions better for people with mobility issues and by doing that, help make products that are more usable for everyone.

Yes, you can test anywhere, even the gym

​Taking a short break from the Accessibility content to ask some “what if” questions. Note, I’m not doing this to shame anyone or make broader comments, just to show that interesting things can be found everywhere :).

Thankfully, my gym is not very expensive, and during this "semi-enforced woodshedding period" I am getting to experience, I can still go to my local gym and get some much-needed body and mind adjustment. In any event, there's a lot of equipment in the gym with a mix of free weights, machines, cardio, and other apparatus to take advantage of.

With that, here’s my gym’s kettlebell rack:

My Gym's kettlebell rack, with medicine balls and slam balls as well

And over here is a bigger apparatus with a number of pulleys and a heavy bag. 

Separate equipment rack with pulleys, rope, and heavy bag

What it also has on it are these QR codes. 

QR codes on the heavy bag rack

These are used for a variety of functions, including bringing up tracking and exercise routines to use. One of them is for the heavy bag… which makes sense, as there is a heavy bag here.

But here’s something interesting. What other code is here?

Connect Kettlebell QR Code

Huh. A kettlebell code. Okay, so let me scan that and pick up… oh, wait!

Turning from the kettlebell QR code to see the kettlebell rack, on the other side of the gym

That’s quite a distance between the kettlebell code and the actual kettlebells. Is there a problem here?

Again, I’m approaching this as a “what if” and trying to think why this would be arranged this way and it’s not as ridiculous as it looks on the surface. This gym has a sister facility in the East Bay (actually, several) and the one I attend from time to time has both of these pieces of equipment. There, these pieces are facing each other and in that case, having the QR code on the pole and turning around to grab the kettlebell makes perfect sense. However, my resident gym layout doesn’t allow for that, so they had to split these pieces of equipment up.

My point is, there may be perfectly good reasons why something is set up the way it is. Whether or not something is an issue is up to interpretation. I definitely don’t think the distance between the two is a feature. Still, the fix could be easy and inexpensive (heck, next to free). Merely taking a picture of the QR code, printing it, and taping it to the kettlebell rack would be a huge benefit. Ordering a more permanent sticker I could not imagine costing more than a couple of dollars.

So there you go, weird and random quality and testing musings on a Saturday morning. You’re welcome :).

The Different Dimensions of Accessibility: Auditory: Training for Accessibility (Part 4)

 I was hopeful yesterday when I was making my post on the dimensions of accessibility that I'd be able to cover all four of the main areas in one blog post. I could have if I wanted to make a post that was exceptionally long but that's not my point in doing this. Instead, I realized that it made sense to break the main areas up and look at them independently and consider the realities that each area faces, both in the way of chronic/persistent conditions, as well as those that are transient/situational. If you are enjoying this series, thanks for coming along for the ride, there are lots more coming in the next several days.

Wordcloud for Auditory Accessibility: Keywords include: sound, difficulty, auditory accessibility, hearing, individual, disease, auditory information, person, Ménière's

Auditory Accessibility

When we are discussing auditory accessibility, we are specifically looking at challenges faced by individuals with hearing impairments. Just as visual impairment is a spectrum, so is auditory impairment. Additionally, there are both chronic/persistent issues that we consider to be primary issues as well as situational challenges that may be transient but certainly matter at that moment.

Chronic Auditory Challenges

Deafness: This term is not as cut and dry as many would believe. Just like blindness does not mean a 100% loss of sight, deafness does not necessarily mean a 100% loss of hearing. The term "deaf" refers to individuals with significant or profound hearing loss. What is significant or profound? A medical Audiologist would consider the severity of hearing loss in decibels (dB). In other words, at what decibel level would a sound have to be for a person to hear it? I am not an audiologist, so do not take what I am saying as gospel but the following values come from the American Speech-Language-Hearing Association (ASHA). 

Degree of hearing loss	Hearing loss range (dB HL)
Normal	–10 to 15
Slight	16 to 25
Mild	26 to 40
Moderate	41 to 55
Moderately severe	56 to 70
Severe	71 to 90
Profound	91+
Source: Clark, J. G. (1981). Uses and abuses of hearing loss classification. Asha, 23, 493–500.

To put this into perspective, a person with normal hearing would be able to distinguish sounds within the -10 to 15 dB range, while a person with severe or profound hearing loss would need to have the same sound ramped up to 71dB or above 91dB to hear the same sound. Those people within the severe to the profound range are what we consider to be "deaf". These are people for whom traditional methods of using devices like hearing aids or cochlear implants will not help.

Hard of Hearing: This is a broader category and may include people on any level of the auditory spectrum. For that matter, hard of hearing can absolutely be situational. People with mild or moderate hearing loss may struggle to understand or interpret sounds in noisy environments or may be limited to the frequencies that they can hear. We can also include conditions such as Tinnitus and Ménière's Disease. Tinnitus is the perception of sound where there is a ringing, buzzing, or hissing sound in the ears. It can prove to be a distraction when. auditory information is present. Ménière's disease is a disorder of the inner ear that affects both hearing and balance. People with Ménière's disease often describe experiencing vertigo, fluctuation of hearing levels, experiencing tinnitus, and a feeling of pressure inside their ears.

Auditory Processing Disorders: these are difficulties in processing and interpreting auditory information by the brain, even when the person experiencing them has normal hearing sensitivity. There are a variety of these disorders.  They may include:

• Auditory Discrimination Disorder: difficulty in differentiating similar sounds ('P', 'B', and 'D' may sound similar). 
• Auditory Figure-Ground Discrimination Disorder: difficulty understanding speech/sounds in the presence of background noise or many sources of sound.
• Auditory Sequencing Disorder: difficulty understanding and/or recalling the sequence of sounds or words.
• Auditory Integration Disorder: difficulty localizing or integrating sounds coming from different directions.
• Auditory Closure Disorder: difficulty filling in details of missing or incomplete sound information.
• Auditory Memory Disorder: difficulty recalling spoken information or sequences of instructions. 
• Auditory Attention Disorder: difficulty concentrating on sound/information presentation and keeping that focus for an extended period.

Situational Challenges

While the above examples could be seen as being persistent or chronic issues, any of them are also situational or temporary. More common examples of situational auditory issues would include:

Noisy Environments: Background noise in public spaces, workplaces, or crowded areas. My favorite example of this is trying to take a phone call in the middle of a rock concert. That's gijg to be an issue for just about everyone, not just hearing-impaired individuals.

Poor Audio Quality: As a podcast producer, I have had occasions where the recordings we had to work with were... not optimal. In some cases, they were downright bad because the technology we had at the time was just not up to the task but we had to run with it anyway.

Multitasking and Distraction: having to divide attention between numerous audio sources.

So that's a pretty big list of things to have to consider. How do we code and test for accessibility in these situations?

Captions and Transcripts: Provide accurate and synchronized captions or transcripts for audio and video content. Many services do this automatically and the results vary. Still, having a mostly correct transcript is better than not having one at all but if possible, provide a sequenced file that can be displayed in time with the information and that has been proofread and is as close to the audio as possible.

Volume Controls: allowing users to amplify the sound to their specific needs and levels.

Visual Cues and Alerts: Do not rely solely on auditory cues. Create visual options, such as flashing light, varying color or brightness for icons, or allowing for vibration through the mouse or keyboard, if possible.

Clear and Concise Content: where possible, provide simple and clean audio tracks. Avoid the background music if it can be seen as distracting, or allow for an option to separate the vocal track so that it doesn't compete with other sounds.

Avoid Audio-Only Interactions: Minimize interactions that are specifically sound driven. Make text-based or visual alternatives if possible.

Consider Multimodal Options: incorporate sign language interpreters, transcripts, or visual aids for presentations, conferences, or online events.

Sometimes, addressing auditory accessibility may conflict with other accessibility areas. There is no one-size-fits-all approach here. Changes made for auditory accessibility may not be ideal for visibility, mobility, or cognitive accessibility. This is where we have to make judgment calls and not only focus on compliance from a checklist. Still, by considering and implementing appropriate design and coding, and testing for them, we can ensure individuals with hearing impairments have as much access to auditory information and content as possible.

The Different Dimensions of Accessibility: Visual : Training for Accessibility (Part 3)

There are many ways in which we have made great strides in focusing on accessibility. The tools we have at our disposal to both allow for information to be accessible and the tools that are available to help us develop for, test for, and advocate for accessibility are growing all the time. It's an area that can be as deep and wide as you want to make it.

Word cloud for Visual Accessibility issues. Keywords used: Content, device, eye, images, accessibility, user, visual accessibility, contrast, fact, issue.

One factor that gets overlooked, however, is. that accessibility is not a one size fits all problem. In fact, what may work well as an accessibility fix for one issue may be totally inadequate for another. When we discuss accessibility, we typically group these issues into four main areas: visual, auditory, mobility, and cognitive. We can also consider the fact that there are levels of barriers faced depending on the severity and permanence of a particular disability. These range from total to partial, everyday to temporary, and even situational, where the environment a person is in may benefit from accessibility features that would not be necessary were they not in that particular environment at that time.

Today I'm going to focus on the area that tends to get the most attention, which is visual accessibility.

Visual Accessibility

There is a broad range of visual disabilities and impairments that people deal with. These can range from diminished vision and the way that light hits the eyes. There are a variety of visual challenges people can deal with at varying levels.

Persistent (or Chronic) Issues

At the top end of the spectrum are people who deal with complete or profound blindness. Being blind is not necessarily the total absence of light or color (for some, it is) but there are conditions where the inability to get a clear focus on something is significant enough to be considered total blindness. Less severe but as persistent is color blindness. This is where people have difficulty seeing a specific color or picking different colors from one another. In a world where color combinations are often used to impart meaning, this can lock out certain people or at the least make the intended message ambiguous. Photophobiamakes people sensitive to bright light, so very bright backgrounds or flashing content make it challenging to look at certain pages or apps, much less navigate them.

Less severe are conditions such as near and far-sightedness as well as amblyopia (often called "lazy eye"), strabismus (misalignment of the eyes), and astigmatism (the curvature of the eye is off, resulting in distorted vision). Age also plays a factor in the flexibility of the cornea. It's why so many people have to shift to using reading glasses when they reach about age 45 (perhaps the largest market for accessibility technology is the market for reading glasses).

Situational Challenges

There are also a variety of situations that people may find themselves in where their vision can be affected temporarily. eye injury, surgery, or everyday eye strain can put an everyday person with normative vision in a situation where they need to have accommodations to see effectively for a time. 

Often the lighting can change in which if a device or application cannot adjust the brightness or change the size of fonts, it can become a challenge in low or bright light environments. One example that is still common is the fact that many websites are not scaled or modified to work with phones or smaller devices, making the navigation and reading of these sites difficult if not impossible.

Perhaps the most common aspect of accessibility is the use of screen readers and by saying that an application or a service allows a screen reader to work with it, that makes the system accessible. It's definitely a good start but there's much more to visual accessibility than using a screen reader.

Some Basic Accommodations

Alt Text: by including alt text with images, the users of screen readers can hear what the image is displaying and can get a better understanding of what the image is looking to convey (note: descriptive text should explain what the image would be trying to convey to a sighted user).

Color Contrast: By making it possible to either have sufficient contrast o making it possible for the user to easily adjust the contrast, we make it so that backgrounds and foregrounds don't blend together and make the site unreadable to those who would have trouble differentiating the shades.

Use clear and legible fonts: this is an art but having fonts that are easy to distinguish, contrast strongly between letters, numbers, and symbols, and use space effectively will allow for more people to better ready the content that is displayed.

Responsive Design: this is where we can resize and reorder content depending on the display being used (and specifically using and defining an agent that reflects the screen/device being used. Responsive designs allow for a better layout specific to the device displaying the information and eliminate having to resize and zoom in to key areas.

Text Resizing: this will allow the users to adjust the text size easily, either through browser settings or built-in controls on the pages themselves to allow for resizing of fonts and yet and having those resizes scale to the rest of the page elements.

Screen Reader Adaptability: It's important to make sure that the content that we want to have people access can be understood clearly and that we don't burden them with words or content that doesn't matter to them. Also, most visually impaired users will not be able to rely on a mouse for navigation. Using a keyboard or a device that effectively moves focus to different elements is critical. Also, it is important to limit the number of steps required to perform certain actions unless absolutely necessary.

Forms, Buttons, and Sliders: Many of the "eye candy" elements of web pages and apps are difficult to maneuver through when using only the keyboard or screen reader prompts. Make it possible to allow for these interactions with the least amount of interference or the necessity for detailed shortcut steps where possible.

As you can see, there are a number of avenues to consider and situations to get familiar with when it comes to dealing with visual issues. With time and practice, we can all get a better feel and understanding for these challenges and make it possible that there are ways that people can interact with our content when they can't see it the same way that we do.

A Very Quick and Somewhat Incomplete History of Accessibility: Training for Accessibility: A Series (Part 2)

As I've been thinking about Accessibility and how I might construct training for it, I figured the History of Accessibility, at least as it relates to the United States, would be interesting. As the digital world has been with us since the end of World War II, many of the adaptations that are discussed came about after that, specifically starting with the 1960s.  

In the 1960s, researchers began exploring accessibility for people with disabilities. Early efforts focused on creating hardware and software adaptations for individuals with limited mobility or vision.

In 1973, the U.S. passed the Rehabilitation Act and specifically Section 504 was passed. This was an important step in that federally funded programs could not discriminate based on disability. Anyone who knows anything about federal programs gets that they can have a tremendous impact on software development, even back in the 70s. We see this today with the fact that lots of software get purchased by the federal government and they can often demand that certain requirements be met and companies will jump to make sure they are able to get those dollars. In this case, it made for a marketplace where accessibility technology had a chance to make money. 

The 1970s and 1980s were a time where Accessibility products and projects made a big jump. IBM introduced ScreenReader in the mid-1970s. While only available for IBM computers, it was still a working example where on-screen text could be reliably converted into recognizable (albeit synthesized) speech.  Apple OutSpoken provided a similar product for the Apple II, providing access to text-based applications.

The Refreshable Braille Display was another big jump, allowing users to type in to their computers and then read back the responses or actions from a flat display that would raise and lower small nubs that, when the user passed their fingers over them, would represent braille and allow blind or sight impaired users to "see" through touch, and moving to the next line would refresh all of the characters.  

A variety of alternate input devices became commonplace in the 1980s. An example I remember seeing early on in my late teens was a large trackball where the spinning ball was the size of a softball with large buttons. Sip-and-puff switches allowed users the ability to control devices and access switches by inhaling and exhaling.

In addition to the refreshable Braille Display, braille translation software made it possible to print off documents that were translated to braille.

A big step for Accessibility came with the popularization of the World Wide Web and other countries also stepping in and making laws that fought against discrimination of disabilities, as well as providing incentives for developing standards to help people with disabilities get access to information.

In the U.S. the Americans with Disabilities Act (ADA) of 1990 was passed and expanded on the Rehabilititation Act of 1973, though this was more of a physical infrastructure focus. In 1998, Section 504 got some additional strength with the passage of the ADA and Section 508, which specifically dealt with requiring federal agencies to comply with regulations making information and technology more readily available to people with disabilities. 

The UK passed the Disability Discrimination Act (DDA) in 1995. The EU likewise took center stage with the Web Accessibility Initiative (WAI) in 1997, sponsored by the World Wide Web Consortium (W3C). Australia introduced the Disability Discrimination Act (DDA) in 1992. 

The EU took steps to establish the World Wide Web Consortium (W3C), an international standards organization. It created the Web Content Accessibility Guidelines (WCAG) 1.0 in 1999, providing a framework for creating accessible websites. Today, most people who look at and consider Accessibility look at the WCAG requirements first, because if the WGAG requirements are met, a large percentage of any other country's Accessibility laws are included there. The WGAG standard continues to be debated and refined, and additional coverage has been added over the years. WCAG 2.1 is the current fully supported version but WCAG 2.2 and later versions have been in the works for quite some time.  

As time goes on and interaction with products becomes more defined by portability and touch, more accessibility features are being developed and are coming for mobile devices as well. Speech recognition, which has been an add-on for most home computer systems, is built in with most modern cell phones. Pinch to zoom and resizing are also tools that are accessible if not specifically designed for the purpose. Responsive Design is also a later development that helps considerably with accessibility. I've long said that the benefits one gets from examining agents and resizing for the display available get us 80% of the way to more accessible designs, as many of the elements needed to display the content also help with formatting data in a more accessible manner.

This is just the tip of an iceberg that could go on for a. considerable amount but this paints with a broad brush and gives some of the significant developments. I'm sure I missed several. If you feel there are some additional items or milestones I should have included, please let me know :).