2024 Testing

This year I wrote some blog posts about legal and certification stuff. like January Testing and May 2018 Testing. So it would be appropriate to shed some light on accessibility and laws.

Disclaimer

I am not a legal expert. So please have a look at my used sources. Or contact a legal expert.

I am just a tester finding test ideas about accessibility. Thanks for joining in advance.

What?

During #30DaysOfTesting I recommended to follow Karl Groves and Albert Gareev on Twitter for accessibility. Karl had interesting news for European software suppliers. Some law for accessibility was coming.

Accessibility is coming to EU.
[On the melody of “Santa Claus is coming to town.”]

I started my search engine and found the European Accessibility Act or EAA.
Great, a new abbreviation for upsetting the PO.

On November 8 the EU wrote a proposal to improve accessibility. In section 3.5 “The proposal” of Annex 1 is written, that the implementation should take place within 6 years.

A lot of readers might think:
“No worries, mate.
2024 is beyond the horizon.”

So what?

A lot of companies would think, that this is a rehearsal of the GDPR situation. A lot of companies still think, that everything is under control. Just have a read over a forgotten test.

Okay, a typical reaction about accessibility is:
“There is no law in place.”

Let me give several comments to this statement.

  • It is not ethical. People are dependent from the internet. There are online shops, online bank portals, online government points of access, and so on. People with limitations have a right to use them.
  • There are human rights and right no 9 states, that things must be accessible. Basically the EU bought companies some time.
  • The global organisation World Wide Web Consortium or W3C created Web Content Accessibility Guidelines to help people and companies to make applications accessible. WCAG or Web Content Accessibility Guidelines is mentioned in EAA. So it is a set of practical information to make websites accessible.
  • Actually there are American laws for accessibility.
    These laws are based on WCAG.

    Accessibility is coming from the States.
    [On the melody of “Santa Claus is coming to town.”]

    Companies are being sued because of these laws at this very moment. So watch out with shipping your software to the States.

  • Websites for European institutions must be accessible.
  • Maybe at the end of this blog post I have some other comments.
    : )
    Just scroll down and up.
    I can wait.

What now?

As a reader you have the right to ask for test ideas.
OK, let’s have a look at an OK button.

  • Is it possible to navigate to this button using the keyboard?
  • Is the contrast of the text “OK” and the background big enough?
  • Is OK written in clear font?
  • Are symbols and colours used to indicate, that a press of the button is a confirmation?
  • Is OK not offensive in this context?
  • Does the screen reader recognise the OK button?
  • Etc.

Imagine the dialog with the “OK” button.
Roll up your sleeves.

  • Are the consequences of pressing the OK button clear?
  • Is a pop up dialog really necessary?
  • And so on. And so forth.

What are we waiting for?

It takes time to find the right combination for accessibility.

Did I already mention, that American companies have a clear advantage?
Or the fact, that government websites in the Netherlands must be accessible to a certain degree.

Accessibility on Dutch goverment websites.
[On the melody of “Santa Claus is coming to town.”]

GDPR – The forgotten tests – Test 3

[Update July 30rd 2019] the last weeks I did some research and discovered that my advice was wrong. So I removed it.

My initial take was to describe a situation, that was not GDPR compliant. But I was wrong, so I wrote down the latest status .

This blog post is about the mysterious status code 451. It still contains some really interesting information.

[End update July 30rd 2019]

Disclaimer

I am not a legal expert. So please have a look at my used sources. Or contact a GDPR expert.

I am just a tester finding test ideas about GDPR. Thanks for joining in advance.

Experience report

This is my way to reflect on my research in GDPR of the last months. It took me lots of hours.

If I missed a legal or W3C link, you can always contact me. I am happy to update this blog post.

This spring I prepared a workshop about blogging. I tweeted about the use of sketch notes to find fieldstones. It got attention from @ConstanceHermit and Mike Rohde.

Mike had a familiar name. I bought his book about sketch noting.
He asked me for a sketch note for testing. OK. Wow. WOW.
Sure no problem.

I only had to wait for a good opportunity to put his request in practice. After a few months I saw a tweet about code on a web page:
“451: the website cannot be shown because of legal reasons.”

I visualised some scenarios and found some problems in the chosen solution. In case of impatience you can skip to the end of the article for the sketch notes. Be my guest.

Numbers are fast to communicate. If people want a pizza and call numbers, then I can go to the website and just enter the called numbers.

A pizza menu was used to abbreviate the pizza names: 16 is pizza Salami, etc. This way a protocol was set up.

The internet Hypertext Transfer Protocol is used for web sites. Status codes like 451 provide information to the user.

The problem with being a tester is to make an understandable message. This is quite hard. It is like telling how a car works without using names of car parts. I wanted to put 451 in the sketch note, but that was intimidating. I also skipped flow diagrams.

I also wanted to show off with test techniques. This was again: Not done. This is only nice for testers, but this is no good for people unfamiliar with testing. I can guarantee you that their number is way bigger than the number of testers.

Several drafts later.
One sketch note became 2 sketch notes. First I drew with a dark marker, then I used other markers for more details.

Then I set a new deadline for myself. I would use the sketch notes in a presentation. If a speaker could not make it at the test conference a week later, then I would volunteer. GDPR is still interesting stuff for testers. In legal terms it is good for the public interest.

Now I had to check my picture. And I hit the wall. It hurt.
Access is denied to the website because of tracking without consent

451 was used for legal demands. I clicked on the link to the official request to add an extra code to the HTTP protocol.
This looked pretty official.

In this case the ministry of justice contacted the internet service provider, which in turn shows a 451 to the user. Sorry access denied.

So this was not about web sites silencing themselves.
So all the hours spent were for nothing. I lost hours of work. I felt miserable. This is part of research.

The weekend before the test conference I looked on the internet. This time I searched on 451 and GDPR. The blog post ‘Is http 451 suitable for GDPR blocking?’ popped up.

So I started my due diligence.

Is it right
What I write?

The author is Terence Eden. That was the guy who had the idea for 451. I looked again in the official proposal for 451. Terence was mentioned. So my sketch note was almost good.

So I only had to change the picture. And I was all set.
Access is sometimes denied to the website because of tracking without consent
I shared my deadline with my kids and they talked about it the next days.

The evening before the conference I checked my sketch note about citizenship. GDPR was quite vague:
“Data subjects who are in the EU” [Article 2]

I could not find something about nationality. So a Dutchman in his own country is a data subject in EU. But a Dutchman in the US is not a data subject in the EU. Did I miss something?

So again I was facing a legal problem in my sketch note.

I used my search engine and found several answers on my question: is it possible to track EU citizens outside the EU?
On Quora there was majority in favour for not tracking. One legal looking website had a complex advice with lots of conditions.

Law is not about democracy, but about sticking to the rules.
Basically I hit the wall again.

Now I am a Dutchman. The big advantage is that the number of Dutch web pages is lower than the number of English web pages.

I entered several Dutch words in my search engine and I found an official web page
“Bedrijven buiten de EU die gegevens van EU-burgers verwerken, moeten een vertegenwoordiger in de EU aanwijzen.”

Please allow me to translate this in English by using the language button on the page:
“Non-EU based businesses processing EU citizen’s data have to appoint a representative in the EU.”

These are the first 2 times I found “EU citizen” on the official EU website pointing to GDPR.
“Is this legal stuff for the court?”
“Sorry no.”
“Really?”

There is a legal notice in the footnote containing a disclaimer. So I am quoting from an interpretation of the EU of GDPR. GDPR is leading and not the interpretation.

The day before first publication date I read article 2 again:
“This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to:

  • (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or
  • (b) the monitoring of their behaviour as far as their behaviour takes place within the Union.”

The location of the home of the user was not enough. Again I was trying to attempt to tweak this blog post.

Wait. In 2 (a) I found an interesting exception clause. What if an American shop offers products in the EU.
So I drew a shop in the EU.

Okay, here are the promised sketch notes. Sorry for the lengthy introduction.

In the first sketch note I point out that the web site uses the location of the laptop to identify an EU citizen. But this is different from GDPR. The nationality of the user and the location of the shop should be used instead.

Sketch note showing that a web site is denying access based on location instead of nationality and location shop because of tracking.

In the second sketch note there are two situations, which were not intended by the web site owner.

An American cannot access a website in the office in the EU. But GDPR is not applicable.

Suppose your American colleague comes to Germany to help you a hand. Then he wants to go to a website with an expensive subscription. It is not possible: 451. The web site owner will probably state something about GDPR. Hopefully a disclaimer was added for this case.

Looking at GDPR there is no violation. So no privacy penalties are involved.

The second sketch note is really worrying, because an EU citizen is tracked during her or his holidays in the US.

[Update July 30rd 2019]

My interpretation of GDPR  was, that this was not allowed.

This spring I heard that it was possible to track the behaviour of European citizens outside the European Union. I filed it for later research. Last month I did some research for my workshop about GDPR. In a blog post it was again stated that behaviour outside the EU could be tracked.

Use the source, Luke

So I searched in the original law text in English. Then I switched over to Dutch and I found an article stating the tracking possibility.

As a tester I immediately started to look for other loop holes.

What about an European tourist in an European embassy in the US? If I would go to an embassy, then I need some help. As a Dutch citizen I would go to the Dutch embassy which is based on Dutch territory.

In this paragraph I made a lot of assumptions, which I had to verify one by one.

I am Dutch. I have a passport, so this is true. The same for a Dutch embassy in the USA.

The 451 status code is given based on an IP address. In plain language every internet device has an address on the internet. If I ask for some information, this info should be sent to my phone and not to a laptop 3 towns away. According to me using 451 status code based on location is highly plausible.

It is not possible to determine, whether the smartphone is in an embassy. For an internet provider it is possible to determine the longitude and latitude of a smartphone. If this is exact enough, I have some doubts.

The IP address of my smartphone does not change. This assumption is wrong. The set of IP addresses for a region of the world is fixed. If I go to the US, then I get another IP address. So a fixed IP address for a smartphone all over the world is not true.

The final assumption was, that the Dutch embassy is based on Dutch territory. This is not true. More important it is to determine which law applies.  It is the law of the host as stated  in article 21 of the Vienna Convention of Diplomatic Relations.

[End update July 30rd 2019]

Tips for testing

  • Go as close to the source as possible.
    Read GDPR or find interpretation of the law given by the legislator or representative.
  • Check and double check information and sources.
  • Gamify testing by using different tools.
    I used sketch notes, mind maps, and the internet.
  • Get used to hitting the wall.

Note about experience report

This is my experience report about GDPR testing. I ran in some problems, but I was able to resolve them. I could just skip the problems encountered, but you, the reader, could get a false impression. Learning is stumbling and standing up. And walking again.