Teksting by: Hans Aasland
Dagfinn: the next part of the IT conference is underway, and there is a course in how to check if a service is
universally designed. There are several people who will give a presentation now. We have to start with
Kjetil Hansen. Then comes Mette Sundal and then comes Petter (Haugen Andersen) in Slutten.
We will try to go through the different types of applications that we believe one should have the expertise to check. Again, this is recorded and posted afterwards.
So you do not have to follow very closely if it goes very fast in relation to
when additional software and the like are displayed.
If you think this lecture is so exciting that you would like to help text it,
then you register that you want to join subtitle video on it here, and then you can just enter:
I would like to subtitle that course in "testing Universal Design". Then I pass the word on to Kjetil, please.
Kjetil: Thank you. shall we see, shall i try to share screen, first and last. Does it work? (yes)
You do not see yourself out here on the right? (No it does not work like that loop) Okay, good! Yes, thanks for the introduction.
My name is Kjetil, I am a graphic designer and front-end developer. I have just started in the UX group at UiO.
Me, Mette and Petter will talk about how to check a services for universal design. We will talk about web applications, mobile and desktop.
I start with the web, where there is also a lot that applies to mobile and desktop.
Yes, I also had this fun opening slide as I hope everyone saw? Then I really go straight to the point:
When it comes to what you can check yourself, we have tried to find a balance. There are rules that are more important than others,
Then there are rules that are easier to check than other things. So here we have tried to take a selection that is both important,
and is affordable to check for someone without deep insight into how a service is structured. The first one we are going to look at
there is keyboard navigation. There are three rules. Depending on how well you know the WCAG regulations,
then they all have a number code; all these laws. The three rules for keyboard navigation are -
now there are slides in English here, by the way. I hope you carry on with that - the first rule is that all functionality
can be operated with keyboard. This means that one should not be dependent on using mice.
The next is that the focus is visible. This means that your cursor, when you move around with the keyboard, should be visible. It is thus focus.v
Bypass Blocks are web-specific. It's a way to skip blocks of navigation.
This is almost easier to show me example, so what I will do now.
First, we have an example that works. I have made this presentation a bit so that I have some examples that work,
also I have some that do not work. It's at least as fun to watch both.
If you are going to navigate the keyboard, you use the tab button to get through a web page. So if I now press tab,
then you see that "Skip to main content" appears in the upper left corner. That's the one rule we looked at, which is
liksom Skip Block; Skip Navigation; Skip Blocks and Navigation.
In addition, we see that, of course, I can see the focus, I can see where I am going.
So that requirement is met. Naturally enough then, all three requirements are met, with that I can also operate this website with keyboard.
On this one here: these work with accessibility, so it's a little extra elaborate.
But we can see on our own side that here an effort has also been made for it. It also works fine here,
and here we have also added several places you can jump to at the start here. Then you can jump to the main navigation
and you can jump to contact information, or you can go ahead and just scroll down the page, then.
So it's not really that hard to fulfill, that rule there.
But there is a simple designer who likes to turn off that focus marking. That's a bad idea.
We can look at an example - a fail example. It's Allente. It is the new merger of Canal Digital and Viasat.
If I start printing tabs here, then you see that nothing is highlighted,
but there's something pushing itself down here like that. Probably ends up in the menu or something like that.
You can see in the bottom left corner here that when I press loss several times - when I press loss many times?
It was stingy.
it works in town. Yes, here I think. You can see down here that it indicates here like that. Then you can see that I am somewhere.
So when I press tab now, I see that I scroll to different ones longer. I get that indicator in the bottom left corner of my browser.
So I'm here somewhere. It's the same way if I take the mouse over here, then I see where it goes.
So presumably, I'm in the menu or something, I think. In any case, it will be a fail.
But if I press tab enough times, I finally get in so that I understand where I am going.
So probably on this website, it's about opening that menu when I tabulate myself there. That could be a solution.
We move on to Contrast. This is one of the more familiar accessibility rules.
That rule says that plain text should have a minimum contrast ratio should be of 4.5: 1.
I will return to how to measure such a ratio. If it is large text,
then it is a milder requirement. But large text is also relatively large. It goes from 24 Pixels and up. So it is
some balancing act to relate to it here. Especially for example on a mobile solution, then you have to go lower
than this in some places. In a way, you can not build a website based on -
one should struggle at least, based on staying within that rule there.
This is a contrast meter from the web. There are many of them. Here you see that I have put in black against white. It provides the highest contrast possible.
You also see: here it now tests wcag AA, AAA etc. It then naturally passes everything.
Then we have - just another test, a blue color. Here you see the contrast ratio. If you remember, it was 4.5: 1
which was the minimum requirement. so this one is at 4.83. So it's inside. It's not very far inside, but it's inside.
You see it pass. It fails AAA, but AAA is outside the law.
It can be overkill to try to comply. If I turn these colors over and put the blue one behind instead,
then of course there is the same contrast and the same effect on it, if it is inverted. It does not matter.
We can see how - yes, we can take it here first.
This is a slide that I like to pull up with other graphic designers. Because, if we were to make up our minds when this word was well enough readable on this blue background,
so I'll probably lie in the middle here somewhere, right? Then I think that "Yes, there it is visible.
If I show this slide on a projector, it will often shift. I often have to go a little further down,
before I think it is well enough visible. Often the very top is completely gone if I show this on a projector in a meeting room.
This is a good example of why these rules are as strict as they are.
People sit on lots of different types of equipment, and there are lots of different environments to look at
a website or whatever it may be. Therefore, it is not up to me, or any other designers to choose, and then we have rules. That's how it must be.
Here are some fail examples. Randomly selected, by the way: scooter sides.
I have no penchant for scooters, that's not why.
If we look at it here. And then we can look at these tools we can use, to measure.
The contract checker we just looked at, we can use it to test a color on that VOI side.
Now I open Inspector here, for those of you who are familiar with it. Hope you are.
Or you can use some color detector to sample.
I think the pink is a little suspicious. It looks like there is a little bad contrast on it.
I'll get it. Then I go to that contact checker, then I put in that pink color. Then I will get to:
it fails. It is not that far from achieving it for large text, in fact. However, it failed as expected.
So then we tested that contract checker there. These other two are very nice browser plugins. There is one from webAIM, called WAVE.
And then there's one from Site Improve, which many may have heard of.
Which also has a browser extension, for different browsers.
If you install them, you get (icons in the browser bar, top right) - this is Site Improve, we also have WAVE next to it.
If I go to another test, then we can test this other scooter thing.
Then we can test Site Improve on it here. I open Site Improve, then it will do a Scan of that page.
Then it will make a summary of the different problems. You see here are these A-codes again.
AAA, you can ignore it. but all those on which it says A and AA, they are affected by Norwegian law.
So we can see here that here for example it is an AA at minimum contrast.
If I click on it, there are 14 cases of that error. Then you can find that error.
Then this will scroll there. I do not know if you saw it. That was in the background for what I clicked on. But if I choose here,
then you see that it marks the problem areas. Then it reads out what colors and what kind of ratio.
It takes a while to get used to using it, but as you learn more of these codes,
then it goes faster and faster to scan over, and understand what is wrong with a web page. We move on, we.
These tools are free, so it may be advisable to install them. Site Improve has a paid solution where you can get
generated an in-depth report of the entire site, not just page by page.
We move on to the next point, which is the use of color, which is then a separate requirement, which has been around for a long time.
That requirement states that color should not be used as the only way to convey information. You need something in addition to color,
to communicate, in case users do not see color. For example here, the most famous example is links.
The top one will fail, because where it says "here", it is a link. And it's just colored.
It will fail, while this one which then has an underline - it must not be an underline, but some visual indicator that is not just color,
it will pass. And this one down here will pass. It does not use color at all, but it has a visual indicator, an underline, which says it is a link.
This one, Time and Date, I use all the time. A calendar can be a little tricky.
There it is conventional to use colors. Holidays are red, for example. But, it is not under.
For a color-blind person, these red markings will… So, you see that all Sundays are red, you know that they are always red.
If there is a holiday inside here somewhere, then it can be more difficult for a color blind person to separate them from each other. So, this one uses color alone, so it fails.
Here is an infographic from Statistics Norway. No, it's from the Office of the Auditor General, in fact.
It uses color alone to indicate lower or higher competitiveness for the other mode of transport. It's what it says down here that those colors mean.
Very typical of an infographic or a graph, that it is a legend that lies next to it and explains what the different colors mean.
Here one must see color to understand the connection between these, and these.
One way to fix this is to add symbols as well. Now it does not depend on color alone.
Then we come to the one here, which is a very familiar sight. It's a pie chart.
It is only to report that most of the graphs on today are not in accordance with the requirements. This is a very typical way to set up.
You have a legend lying next to it, explaining what the different colors mean.
So, if you do not see color here, then you do not understand which piece of cake is what is Firefox for example.
One way to fix it: here a visual connection has been made between the piece of cake and the label.
Which means that you no longer need to see color to understand it here.
In fact, percentage values ​​are also stated here. Next to the labels. So, this here information will be available without the graph at all.
Then we have another rule. With things that move and flash, small animations, there are actually rules.
If an animation starts automatically and lasts more than 5 seconds and presents in parallel with other content,
there should be a mechanism by which the consumer can stop or hide this animation.
There is a good reason for that. It can be very annoying to have something moving in the side view, even for us who do not necessarily have any problems with it directly.
Then it can be a very cognitive strain to have such things going.
It is not always easy to comply with. You see someone using animations that just go and go and go.
I think NRK, among other things, I have seen a couple where they actually break this law. I have also sent questions about it to them, but have not received an answer.
Another rule is: do not design in a way that is known to cause seizures. There is a rule for how fast and intense something can flash,
which applies in addition to the top rule. So, do not do it.
We move on. Now we come to the part where we talk about the middle ground. It says that not all textual content has a text alternative.
The best known example of this is probably the alt text - caption.
It is not caption. It is all-text hidden in the code, which acts as a replacement for the photo,
for those who can not see photo. An alt-text is a lot more blunt, in with teaspoon description of what is actually picture of,
so that the user will understand what is going on in that image.
This is also an article about one thing we are proud of, namely that we use some artificial intelligence to generate these alt texts at UiO
Others who were out early with it were Facebook, they have used it for a long time. I actually got one myself, "image may contain cat",
because it was an image that did not upload. It turns out that they use such technology.
It is understandable that they choose to do so. If I share photos on Facebook, then it is probably difficult to get the user to add good alt texts to the photos that they share on Facebook.
We can look at a failing example of that rule. Brilleland. Not randomly selected.
Here, things should be taken care of, and that is mostly the case. But I found something, that mistake here.
Otherwise, it seems that it is a site that is made conscientiously with these requirements.
If we start site improve here, then we can see that we have an "image without text alternative",
where we have three cases of it. She, for example. You can have a code that says that the image is purely decorative, and that it then does not make sense to have all-text on it.
But this is not really such a picture, and it is a picture of a lady with sunglasses. This is about sunglasses, so it will increase understanding
in a blind person, for example, to get a good all-text on that image. That to here. Yes, here. The image here also lacks that text option.
Brilleland fails a little. Then we have actually come to my last slide, and it fits well in time.
I have one like that for the nerds at the end, I was about to say. One thing that developers can think of,
is that it is possible to have automated testing of these requirements in the actual Development / development pipeline.
You can connect to different services that detect just as Site Improve detects,
then one can also detect this mechanically. This is a project I was on before I came to UiO, where I discovered,
almost by chance, that the development that I worked with. He had posted some jsx-ally.
It's a react case that intercepts a mistake or two in the wild. That's great, then you can automate a bit.
I was told that NAV, among other things, does things like this,
and they have also set very high standards for the number of such errors that are allowed, before it builds at all.
And it's very natural, I think, because developers have always used such things,
to test that JS is OK and other code is written semantically ok,
so why not automate the accessibility check?
When coders talk about accessibility, it may look like that, because they have somehow found their way to write it.
If you see it here, it's code language for Accessibility. God knows why. Yes, thank you for me now,
I also give - how do I pass on the word, really? Dagfinn can probably fix that. Stop Share I must surely take.
Mette: sounds like a good start.
In the next section here, we thought we would go through a little more how we test for mobile apps. I'm then Mette Sundal. I work as an interaction designer in the mobile app team, in the web section at USIT.
Among other things, I did some testing of the mobile apps we have this summer. Among other things, the dictaphone app.
I'll take you through the process we had around it. Some of the first question is:
Why should we test now check design on mobile apps? First of all, public mobile applications are part of Norwegian law.
There are many of the requirements that Kjetil went through earlier in the presentation, which is then WCAG 2.0.
from 1 January 2023, we will also switch to WCAG 2.1, which contains 14 new requirements,
where several of them are also quite relevant for mobile.
So far, the UU Authority has not come up with any interpretation of the requirements, or checklist and test rules
for WCAG 2.1 and mobile apps, but it will come, and they have also conducted audits.
Among other things with Vipps, which deals with discrimination. If the visually impaired and blind have not been able to use one
share apps, which are seen as important to the public. Another good reason why we want to be concerned
universal design and running part of these tests, is that we want to deliver high quality apps,
which can be used by as many people as possible. Some of the new requirements that come in will, among other things, be the viewing direction.
It is very relevant on mobile phones, as you can often turn different paths.
Here I have shown How you can solve it with, among other things, Student Certificate. If you flip there horizontally, the screen will turn.
This can be especially useful if someone has devices where their mobile phone is stuck.
Say you use a wheelchair machine, where you have your mobile in front as a screen, then it is often locked in position.
So I thought I would talk a little bit about how we proceed when you want to test.
We want to test this Dictaphone app that Nettskjema uses.
It has become very popular at UiO. It is a way to conduct interviews, to take audio recordings along the way.
It is used by both researchers and students, and can be used by anyone who has access to the Web form.
The way we start is that we go through these requirements that Kjetil has also taken us through. And feel free to also read over on Uutilsynet's pages.
This is often a good place to start. Here we find that they have a page, which is about Universal Design of apps.
Then we can look at which requirements are most useful. It's also a little nice to look through the app you have,
and see what it contains. For example, if the app does not contain video or images to a large extent,
so you will not have to think about subtitling videos, or alternative text on pictures, because it is not there.
But, if I can take the demands as a contrast, which Kjetil talked about, is well present; must be able to change the text size.
You often have a number of tools on the phone for this, which can increase the text size. And then you should still be able to use the app to the same degree.
There are a number of other requirements. Like you have good navigation; that you do not invent your entire navigation,
but that you use navigation methods that are familiar, with mistakes and stuff, among other things.
Some of these requirements here we have also included in an Excel template, which we use when we go through what we want to test.
Then I and an interaction designer named Sara went through the Dictaphone app this summer.
Then write down what we have tested on, which, which criteria we have tested and then add comments,
and came the claim was approved or not approved. This is where a lot of interpretation of the requirement comes in. One can disagree on how claims are interpreted.
For mobile apps, you have some automated tools for developers; those who code up.
But when we go through testing, we do a lot manually. I have not found really good tools,
as one has for some browsers, as Kjetil showed. But you have some built-in tools on your mobile for accessibility.
Here we have a picture from the app, where we test the magnification of text.
We see that as I turned up the text size, the content began to slide into each other. We also see that the menu at the bottom starts to slide up.
So with even bigger text, it is possible that it will go beyond that framework. So I thought to see if we can view from mobile and.
Yes - then I'm in on my cell phone, which I use a lot for these tests. Then you see that we have something called accessibility, under the home screen here.
Here I can then turn on some settings. for example, I can increase the text size here. Then on off.
Here we see that I have set up the text size quite a lot, we will see what happens if I set up all the way to the max.
Some text that can be easier to read if, for example, you have impaired vision, or struggle a little to see, if you have not taken your glasses with you one day, for example.
If I now go to the app (dictaphone), you will see that I do not get all the text.
It might have been nice to add some scrolling functionality here, so that you can scroll all the way down and see what it says.
While here it will work better. Here I get more of the text, and can scroll down and get it all up,
even if it does not fit as much on one page.
Then we also have something called Voice-Over, which is the kind of voice reading that can be found on mobile phones.
It can be a little more complicated to use when you are not so familiar with it. Shall we see if I also get sound on it.
Voice-Over: Voice-over on. Settings; Availability; Back button; Screen saver on; Speech off. - Do not know if you get the sound of it now?
Mette: Do not know if you can hear the sound of it now?
Dagfinn: Yes, there is a bit of quick talk and a bit of "Bloop, bloop".
Mette: Yes, it's pretty fast. Lets see.
Voice-Over: Speak on. Settings back button. Settings. Settings active. Search settings active. Swipe up the dictaphone: Active. Swipe up: Dictaphone. Dictaphone settings. Settings back button.
Dagfinn: But now it's black, do not see the screen here. Is that how it should be?
Mette: Eh, yes that was it .. I think I came across a setting on it. Dagfinn: It makes sense, it should be able to get you through the mobile app while it is black.
Mette: Yes. If you do not see then, this is how you want to perceive the mobile app. Then you only depend on hearing what is happening around.
Voice-over: At the top of the screen. Starts help. To stop help, double-tap with four fingers or rub with two fingers, or you can press escape on the keyboard.
Mette: Yes. Then you use a lot more gestures and stuff like that, to swipe up and down. Voice-over: Touch: Read out object. Touch: read out object, double-tap with three fingers: then off or on sound.
Mette: And by going through that, you will be able to find out a little more about whether things are coded correctly. Dagfinn: But, you're in on the iPhone now. Is it similar on Android?
Mette: Yes, there is something similar on Android then. It's called Talk Back. Have not tested if it exists for Windows. Dagfinn: You do not need to test Windows Phone.
Mette: No, we do not have apps for Windows Phone either, I think. Dagfinn: Isn't it the case that you need to test this on a lot of phones? You really only need to test this on Android and iOS?
Mette: Yes, we have only tested it on Android and iOS. Dagfinn: And then it's like it's something - you have not experienced that it works on one iPhone and not on another?
Mette: It can be with screen sizes. You may want to test with the smallest screen sizes that are common.
Which is now maybe - have tested out with an Android, which is 360 pixels wide. Then you always see content in place.
It's a little nice to see that something is not pushed out, or that there are no buttons you can not access, so that you can no longer use the app.
Especially when you get larger text, and then you have blown the screen so much that you can no longer scroll, then you will be able to get buttons that are no longer available.
It happens in a bit like testing, then. At least unit. But then it is not so dangerous with slightly larger units, then.
Then you will most likely get a place, so the most important thing is to get to test on the slightly smaller ones, and get to test on both iOS and Android.
Dagfinn: Yes, I think that sounds affordable and, so to speak. Mette: Yes, that's it. Yes, I think maybe I'm passing the word on to Petter now, who will be going through a little more desktop applications.
Petter: Yes, thank you. Lets see. Then I managed to share screen and stuff.
There is a lot that goes into each other, as Kjetil said in the introduction.
And then there is the fact that it can be a little difficult to define what a desktop application is.
It has been in a way more common that a lot of things are in the browser and on mobile.
And in a way, large complex desktop applications, which are installed on a desktop PC in some office, have made it a little less common. At least maybe to carry out a regular job.
But it is still relevant and they have some advantages, absolutely.
Maybe you do not need a network connection to use them, and you can have far better performance to carry out heavy operations, which may be a little clumsy in a web application, which is often a little easier.
With that said, it may be difficult to distinguish between desktop applications and web applications in disguise.
Discovered it here for example with the design tool we use, called Figma.
It is available in the browser, and then it is also available in the desktop application. But by accident, I thought I was in the browser.
Then I click the shortcut key to open the Inspector window, to inspect the HTML code.
Then it turns out that the desktop version is also just a browser window, then. Chrome, it looks like.
But you get a little extra functionality by having a taskbar that is for that application, instead of having the browser taskbar at the top.
So what exactly does the law say about desktop applications?
It can be a little difficult to figure it out and, as mentioned earlier today. At the beginning of the UU project at UiO,
then it is the case that ICT solutions must meet the minimum requirements of Universal Design, but with the exception of working life.
For UiO, it may be a little difficult to make a difference there, because we have software that we use both internally,
but also towards students for teaching. Once it is a learning resource, then there are requirements for Universal Design.
For example, Zoom, which is used for teaching, is then included.
If it had only been used for internal communication for the employees, it could have had a slightly different function.
Then it is the case that there will be some new rules for public sects next year on Universal Design of intranets and extranets,
but the new rules do not include systems for case processing, registration of working hours and such things.
As such, there are really no specific requirements. But UiO, for example, is part of this inclusion charity and goal of an inclusive working life,
and then be able to ensure that the software that must be used in a work context is universally designed.
Now it is not the case that you have so many automated tests to lean on, such as in the browser.
As Kjetil showed, you have browser extensions that scan through the content for you.
You can still rely on the Web Content Accessibility Guidelines (WCAG) when testing a desktop application.
The four main principles are that it should be possible to perceive, possible to operate, understandable and robust.
Then it's like Mette and said that when it comes to mobile applications, that you have to manually go through the service of the application,
and then check if you can all interactive elements using TAB and SHIFT + TAB,
whether the sequence of keyboard navigation is logical and intuitive, whether it is possible to move with arrow keys inside interactive elements,
if you can make a choice with SPACE, end the interaction with ESC, and then if you can switch between windows and the like with CTRL + ALT button.
It is important that you are able to reach all parts of the program, simply.
Then the same goes with the text option. If you have many graphical elements in the user interface,
so it is important that these here have a textual alternative, which often appears if you hold the mouse pointer over,
or that will be read out, if you use a screen reader. For example, Voice Over. The same then applies to photos or videos, that they have text option.
Maybe not as common with photos or videos in a desktop application, as on a web page.
Then there is trying to use the software with a screen reader, such as Voice Over on mac,
and see if you can use all parts of the program using the screen reader and that it then reads out the state of the interactive element.
That things are selected, not selected, that it says whether you are on the drop-down menu, check box or text field,
to help you complete the task you are doing. So it is and if the screen reader reads out relevant help texts,
and tells if you have given the wrong input and the like.
The same principle applies to colors on the desktop as well.
Here and there you have to use manual tests, for example you can check if the user interface works for people with different types of color vision.
This here is built into mac OS. Do not know the hill it is on Windows, but there are also software such as Color Oracle, where you can simulate different types of color vision.
It can be helpful to find out if there is information in the user interface that is only conveyed using colors.
Then you can and check the contrast. If you want to make it a little easier - you may not easily get a color code in a desktop application.
Then you can use a tool like Color Contrast Analyzer. Here you then have a pipette tool,
which can allow you to select foreground color and background color to see if it is good.
In my lecture, it's black and white, so it's absolutely great.
Then you can also check if the user interface works in high contrast display.
It is something that people with impaired vision can use, to increase the contrasts between elements.
What one will see then is that if there is something that is below the applicable contrast requirements,
then it will often disappear when you turn up the contrast. Finally, there is something to keep in mind when evaluating desktop applications.
Since these types of applications are often quite complex and designed to perform many specialized tasks,
then this complexity can quickly go to the detriment of the user quality for users with disabilities.
An example of this is Universal and Media LT testing universal design in Zoom and Teams last year,
in connection with the fact that most of the teaching went over to these platforms, in addition to all others.
Then we saw that both are good at universal design, but there are differences in usability for the purpose.
For example, Zoom was more pointed and was faster to use with a keyboard and screen reader.
It had fewer features and optimized for video conferencing.
So had Microsoft Teams integrated solution for sharing Powerpoint Presentations,
which meant that if you used a screen reader, you could actually follow the presentation itself, and read out texts in there,
instead of just watching a video transfer. It can be something to think about if one evaluates several solutions against each other.
Beyond that, it is a difficult area. We do not have any formal test procedures for testing desktop applications.
Most of the things we have dealt with are web solutions and applications on mobile.
It will be exciting to see in the future if there is something we have to deal with. Thank you.
Dagfinn: Very good. I think and know it had quite a lot of applause now,
I'm absolutely sure. The audience is really cooking, but we have hidden this in this webinar.
I was trying to think if we had any desktop clients that we have highly recommended,
as critical clients in the past. Just in the small room I was sitting in here now, we came up with three actual clients that we highly recommend.
One is Mattermost which we recommend people to use,
Something else is actually Git's client, since we have moved from Bitbucket Git, we recommend a client there.
And we have the heavy recommendation we have given for several years, to install local Horizon Client,
to get both into the program kiosk of UiO, but and all access to enter the TSI.
They have probably not been tested on this. You had tested some of it?
Petter: No, I just want to say that the Mattermost desktop version is and Chrome. Dagfinn: Yes, it's all, then. Everyone is available in other things, subject it is and clients that we recommend.
In that sense, we should really - or we as - this is something that everyone can take responsibility for.
If you are in a process where you see "okay, see this client here" we can go out and say to our users
"Download this and use, then one should spend 2 hours where you say, yes,
rewind to the end of this video here, see quickly what it was Petter said we should check,
and then you check it at full speed at least, so we can have some idea whether this is inside or not.
The same applies when we start recommending the use of mobile apps. Mette works with the development of mobile apps,
so we can think that the apps that we make ourselves, it takes more responsibility for universal design,
if we did not do it when we made them, like the Dictaphone, then we do it at least now. Can clean up and launch a new version.
Part of the idea of ​​this that has been presented today is that everyone involved in processes where we
introduce and recommend products, should be able to make an evaluation of the UU in the application.
I hope that this course will be the most popular course video shown at UiO.
Tom, you can make some closing remarks here, maybe?
Tomm: I thought I should just follow up on some of the questions that came up in the chat. There was one who was at least eager there.
There is one named Stein Vidar. Then I thought of answering a couple of the ones I thought might be relevant to more.
Dagfinn: They probably do not necessarily see the chat the others, so you have to read out the question.
Tom: I'm going to read out the question. One is about this system which -
A bit off topic right on testing here, but this with image descriptions and what is used in Vortex to generate
descriptive text on pictures. He asks if it is available to us, and in the sense that Vortex
is available to you, then it is available to you. That is, everyone you want to upload there,
this happens automatically with. But if you would like to use the same system that Vortex uses,
so far it is also available. There is then an API in Google Cloud called Vision.
We have an agreement with Google Cloud, and just send an email to usit-cloud@usit.uio.no ,
and request a project with that API. They may have a few more things they want
ask yourself about it, then. But then it is at least possible to use that API as well
for purposes other than those for which we have used it. Then there were a couple of other questions that I really thought about
Kjetil should be allowed to try to answer.
Kjetil: Yes, thank you for that. Thank you Stein Vidar, for the difficult questions.
But now I have managed to think about it a bit, and one question is regarding the hiding of focus. Whether it is allowed to have -
that is, this with key selection of focus, then. Whether it is allowed to have on and off buttons for that. Then I think that:
Your on and off button is actually that someone starts using a keyboard. So that if the focus marking is sometimes undesirable,
so it is most often in cases where you use a mouse or touchscreen. That something is being highlighted
which gets stuck, for example, if you have something that opens and closes. You can easily with javascript
detect if the user is using a keyboard, mouse or touch. I probably would rather like that in general
basis I would probably rather - remember only the English word, but eraset focus, than try to turn it off.
You can style your own focus on how it should look to a certain degree, as long as it is within the requirements.
Then you can have a focus that is in the style of the graphic design. You can do that.
If you need to turn it off somewhere, I would do it a bit like that case by case.
A classic example is the hamburger menu on a mobile web solution.
There is often a focus marking stuck on it. When you tap on the mobile phone, you do not need that focus marking.
That was a long answer… I can answer one more thing that Stein Vidar has asked about. If you have a website
with fully the same functionality that satisfies UU requirements, and one has an app that does not
satisfies the requirements of law. I do not know why you want it -
You rarely have an app that does exactly the same thing. Often you have a native app to do some special things,
as a native app can and not a website can, you will probably not be able to get within that,
by saying that you can achieve exactly the same thing in our web solution, so this app does not follow the requirements.
It's probably a little difficult. And the scenario is perhaps a bit sought after, if it is allowed to say.
Have there been any more questions here now, Tomm? Tomm: I saw it was another question from Silje Vinter, about administrative systems.
She wonders if there is a transitional arrangement for them, or if they are permanent except for the requirements.
The answer to that is no - what Bjørnar talked about earlier today with the WCAG 2.1
and intranet and extranet, then there is nothing concrete.
One can not take for granted that there will be no claim later to put it that way, but for now it is
nothing on the plan for requirements for this type of Systems directly. But there is clearly a difference
Administrative Systems and. A few years ago, the Facilitation Act was sharply linked to -
especially with relevant for universities, related to the students and the students' teaching and use at UiO.
So, I'm not so sure that administrative systems that students have to use are exempt.
So we are still talking about internal systems for employees, administrative or not, they are exempt.
While there are students who will use it, I think it very quickly comes under the requirements.
So there it is, then. And she also asks if there is a difference between new and existing.
For the web, that's not the case anymore, at least not for WCAG 2.0.
There were the transitional arrangements versus new and existing, it went out in a way 01.01.2021.
So then you could no longer hide behind the fact that it was old IT.
So now there is at least no difference there, then. WCAG 2.0 applies to both new web solutions and
old web solutions, as of today in Norwegian law. Kjetil: There has been a follow-up from Stein Vidar here, where he writes ordering pizza.
At first I thought he suggested ordering pizza, had been a nice thing. I wonder if that's not the app he's talking about.
App versus website. If you have a native app you can order pizza in and you have an online solution that does exactly the same thing.
I think you will struggle to claim that you are within the requirements, because you you present exactly the same
the information and functionality of a parallel solution. But it's like that - dare not say it completely,
but you can send questions to UUtilsynet about it, then it is interesting to hear what they answer to it.
The general attitude to UU is that, as Dagfinn said a little at the beginning:
Is it expensive? Is it a lot of work? Then one should rather have that attitude to these rules,
that they provide a better user experience across, then. You also want that grandmother of 80 maybe,
manages to order pizza, for example. There's no reason why she should not have it,
if it was out of contrast, for example. Most of these requirements I would say are
sensible things and it's smart to follow it. It provides a better user experience.
That's the way it should be. Dagfinn: Then I think we will put a stop to it.
I will enter your offices with a thermos, so you will get a thermos even if you have not translated or subtitled a lecture.
It is still possible to sign up for it on the IT conference pages, at the link here,
where you can be allowed to get honor and glory if you help us text one of the courses from the IT conference.
Tomorrow we do not start at 10, then we start at 12. It is not such a themed day,
as the other days have been, where we have had scientific lectures and still with one theme, as today.
Tomorrow we start by seeing the hill KHM has started to 3D scan, among other things, Viking ships,
computer service on IT security, and a number of other quick talks on technical information things,
So we quit an hour later - or we start two hours later tomorrow. Thanks for the day today, and outside it's sunny,
so just go out and enjoy some of the last few summer days, at least here in the capital. Thank you for today.