Good morning.
My name is Gian
. I'm the CEO of AccessibilityOz.
Thank you for attending our first
webinar on mobile accessibility.
The slides can be accessed from pz.
tt/mobile19.
Just a little bit of housekeeping.
We have a captioner.
Please let us know if the captioning
stops working or something like that.
We'll get back on it immediately.
If you have any questions, you can put
them in the chat and send [Inaudible],
my excellent executive assistant, who
will collect them.
I'll be answering them at the end.
If anything crashes or stops working,
put them in the chat.
Sam can notify me.
Thank you for coming today.
You may know that I'm running this
session again in 8 hours.
Probably longer than that.
10 hours.
I can't count.
It's at 7pm tonight EST.
It will cover the European, Pacific,
and Australian time zones.
If you know of anyone else who'd like
to attend, they can still register.
Yeah, we'll get started.
Thank you again for joining us.
I want to start by showing you a
picture of our team, about 2⁄3 of our
team at CSUn last year.
I started AccessibilityOz in 2011.
We're 8 years old.
I wanted to support people with
disabilities by employing them by
creating and testing accessible websites.
60% of my staff have a significant disability.
We all look for want of a better term, normal.
That's really important to know about
people with disabilities.
It's often hidden in plain sight.
It's something that you won't
necessarily be aware of when you're
talking to people, whether they have a
disability or not.
So, some of my staff have disabilities,
including things like dyslexia, moderate
version impairment, epilepsy, migraines,
severe vision impairment, physical
impairment, PTSD, Crohn's Disease,
multiple sclerosis, and cerebral palsy.
It's not just about vision impairments.
People think that screen reader
accessibility is the most important part
of accessibility.
It can be quite difficult, but there
are other things to be aware of, as well.
Sorry.
Excuse my voice.
I'm having some asthma problems today.
The largest group of people with
disabilities in the U.S.
are people with cognitive disabilities.
That's something that you definitely
have to be aware of when dealing
especially with mobile because mobile is
a unique opposition.
A little about our services.
I won't go into a lot of detail, but
we do order mobile testing.
We build AAA websites.
Each AAA website we've built has won
some design or content award.
We're proud of those sites.
We do video testing, user testing
consultation, training, etc.
If you're interested in engaging with
us, please do reach out.
We have 6 products.
One is missing from here.
One is OzART, the AccessibilityOz
automatic reporting tool (an automatic
testing tool), OzWiki, and OzPlayer, our
accessible video player.
I'd like to give you a free 6 months
access to OzWiki for attending.
You'll receive a password if you
registered for this webinar.
There are only two accessible video
players in the world.
One is OzPlayer.
The other is Idle Player [sp?
] If you're interested in those, look
at the presentation page.
The first video is a video of the
inaccessibility of the various video players.
We have a site called Accessibility
Voices, which is a series of blog posts
written by people with disabilities
about their experiences.
We're always looking for bloggers.
We pay bloggers.
If you have an accessibility
experience, whether good or bad, that
you'd like to write about, let us know.
We also have a series of fact sheets
written by category on coding, content,
images, interactive maps, javascript
forms, etc.
Each fact sheet talks about why the
accessibility of that category is important.
It has to testing and developer
checklist, which has correct and incorrect code.
We have a series of [Inaudible]
community colleges videos, which detail
their 16 videos and developers.
They detail why you should use HTML
headings, how to code a form or error
label, etc.
All of those links will be on the
present file.
We'll send an email after this with a
link to the recording, as well a link to
these products.
That's more than enough about AccessibilityOz.
A little about me.
I started in accessibility in 1998.
I worked on the first accessible
website in Australia and created their
first atmtatd accessibility tool in 2000.
I spent three years with the W3C
working group.
I spent time in the 2006 Melbourne
Commonwealth games, making their content
accessible.
I spent 6 years at [Inaudible] University.
Then I started AccessibilityOz in 2011.
We released OzPlayer in 20143 and
OzART in 2014.
We opened the U.
S.
office.
I spoke at [Inaudible] in 2015.
Last year, I was nominated for
aAustralian of the Year.
Let's talk about mobile.
You might think that we just need to
follow
WCAG2.
Unfortunately, WCAG2 doesn't really
apply well to mobile.
We wrote WCAG2 from 2000 to 2008.
Really, there wasn't the use of mobile
back then like we see today.
We tried to write it so it was
technology neutral and could apply to
devices like mobile, we didn't know what
the future would hold.
An example of WCAG2 is that it requires
that sites be accessible to the user,
but it doesn't require that sites be
accessible to just the touch screen or
just mouse user.
There are users who are restricted to
those input devices.
WCAG 2.
1 builds on accessibility of mobile and
addresses more criteria related to
touch, pointer gestures, etc.
It really doesn't cover all user needs
related to mobile accessibility.
2.
2 will probably come out in the next couple of years.
I'd expect that that will also address
mobile in a better way, but it really
doesn't go into enough detail.
One reason why is because they're a
jrthere are unique mobile accessibility
features on mobile and tablet devices.
There are native features like
talkback, narrator, voiceover, volume
control, hepatic keyboard, etc.
You might have seen the Apple release
about the new accessibility features in
iOS 13.
That will make testing and the
accessibility compliance of mobile sites
different as soon as iOS 13 is released.
Unlike a desktop, you're restricted
to accessibility features built into the
device.
We see that with Samsung, who has a
new screen reader called Voice Assistant.
Your Kindle Has a voice operational
view, etc.
Those kinds of things mean that
testing is very different because you're
restricted to only one feature and not a
variety of them that you could purchase
and implement.
There are a bunch of system and
accessibility settings like font size,
touch and hold delay, screen rotation,
etc.
For example, I was watching Netflix last night.
The only way to watch Netflix is in
the vertical view or landscape
orientation view.
For someone who's restricted to a
portrait orientation because their
device is attached to a wheelchair,
they'll find it difficult to watch Netflix.
Those are the kinds of things to take
into account in more detail in mobile
than desktop.
Let's talk about mobile usage.
In 2015, some people say 2014, when it
comes to the total amount of time people
spend online, people ended up spending
more time using a mobile and tablet than a desktop.
That means that of every 100 minutes
that someone spends online, over 50% or
50 minutes of those will be on a mobile
or tablet device.
It's important to ensure that your
content is available and works properly
on mobile, but that it's accessible to mobile.
It's not accurate to say that someone
with a disability is only going to
access your content via desktop.
For example, I had a vision impaired
personal assistant for two years.
She did most of her work on an iPhone
committed to a keyboard.
She doesn't need to carry around a
desktop or laptop with a big screen.
She can't see it.
Everything she accessed was the mobile
version of the site.
We'll talk about how that affects the
sites and content you have later in the session.
This is indicative of people who use
screen readers.
In 2009, 12% of people who used screen
readers also used it on their mobile or
tablet device.
That's increased to almost 90% in
October, 2017.
This is from the [Inaudible] screen
reader survey, an excellent survey.
There is a methodology that's
mobile accessibility guidelines.
.
At AccessibilityOz, we use them.
We found that some things were missing.
Sometimes they were difficult to
interpret because they merged the native
app requirements with the mobile site requirements.
You weren't sure if a requirement or
test was for a native app or mobile site.
We found a few things that weren't in
the BBC mobile guidelines.
Excuse me.
Sorry.
I'm part of a committee for the ICT
testing committee symposium run by Chris
Law [sp?
] in October yearly in Washington, D.C.
He wanted to create a committee to
write a mobile testing methodology.
I was chair of the committee.
For 2018, we met and wrote a mobile
testing methodology.
in conjunction with the other large
players in the accessibility industry,
including DQ, the pasillo [sp?
] group, etc.
We incorporated their methodologies
and ours into one big mobile testing methodology.
We released that in October last year.
That's what I'll talk about today.
Excuse me.
We're working on version 2 of the
methodology now.
If you're really interested in this or
feel you could contribute, we are always
looking for committee members.
We have two mobile committees, one for
the mobile site and the other for native
apps.
If you're more interested in native
apps, there's a committee for that, as well.
We focused on mobile sites, but I'll
talk about native apps today, as well.
A lot of things we cover in the
methodology are applicable to native
apps, as well.
Excuse me for a moment.
Sorry.
Just needed to cough.
The first step is identify what needs to
be tested.
This is really important.
There are basically three steps:
Identify the devices to test with.
Identify the site type, whether it's a
desktop, m.
dot, or responsive site.
If it's responsive, identify
variations of of the page.
The recommendations for browsers we
decided last year were:
Recommendations on screen] [Reading: Recommendations on screen]
A couple things to say about this.
iOS devices are the most popular in
the western world.
In the esastrn world and Asia, it's
Android devices.
You might want to modify these
depending on your Google statistics.
That will give you an idea of who's
using what.
The other thing is if you're using an
Android phone, make sure that you use Chrome.
If you're using Samsung and the
internet app with that, it's very
dependent on the actual own itself.
Chrome is what you'll see across a
bunch of Android devices.
We're talking about whether or not to
include Google Pixel and Samsung across
the devices to test on.
That's something we're talking about
at the moment.
It's really important to test with real devices.
This is something that I do a lot of
travel, as most of you probably know.
I spent about 6 months of the year in
the U.
S.
I've been traveling like that for the
last 5 years.
When I first started traveling, there
was no WiFi on the long haul flights.
So, 15 hours without WiFi is
definitely painful.
We'd often arrive at the tarmac and
there wasn't a gate ready because we're
arrive 30 minutes early.
I'd try to access the LAX WiFi.
One thing I would see at Las Angeles
International Airport WiFi access.
I have 25 minutes left on my WiFi.
It would say the page had to redirect.
Suddenly, I didn't feel safe giving my
credit card details.
This happens when you don't test with
real devices.
You need to test with real devices in
the field using the system.
jrThere are some times that you can use
simulators, but often, they won't give
you an accurate representation.
You absolutely need to test with real devices.
I mentioned the different types of sites.
There's desktop, m.
dot, and responsive.
A desktop site looks exactly the same on
a mobile as it does on a desktop or laptop.
You've got your header, left hand
navigation, header, and footer.
An m.
dot is instead of www.
You'll see the mobile version of the
site.
Sorry.
I'm going to adjust my audio.
what you'll see instead of www. You'll see the mobile version of the site. Sorry. I'm going to adjust my audio.
Hopefully that's better.
Basically,
Excuse me.
[Coughing]
Excuse me while I get something to my throat.
The best example of an m.
dot site is Facebook.
If you go to www.
facebook.
com, you'll get a different site than if
you go to m.
facebook.
com.
By far, the most common sites out
there are actually
responsive sites.
, in which the content changes or it's
laid out differently
depending usually on the break point of
a window.
It's important that each variation of
pages are tested and all functionality
is available on all variations of pages.
We've had clients with an image gallery.
They decide not to have the image
gallery on the mobile site.
That's something to be careful of.
You have to make sure that all
functionality is availability on all
variations of pages.
People are often restricted to one
particular variation because of their disability.
If that variation doesn't have all the
content, they won't be able to access
all that information.
Then it won't be accessible.
Variations of a page can be created
based on the browser being used, the
mobile device, but mostly, it's based on
the browser window sites.
Most cases, you can identify page
variations by changing window size on a desktop.
There's information on a mobile
methodology at pz.
tt/mobile19.
There's information there about how to
identify the variations of the page.
You know the difference between the
desktop and m.
dot sites.
There's two types of variations of a
page.
There's variation in content and
variation in the presentation of the
components displayed.
Variation in content is where something
is changed or missing.
Variation in presentation is where
you have the same content, but it's
displayed in a different order.
A good example of variation in content
is your hamburger menu, which is a
change in ctentontent.
Sorry.
Looking at the chat.
Variation in content -- instead of on a
desktop/laptop site, you've got your
navigation content.
On a mobile site you've often got a
hamburger menu.
Although that's a change in the page's
look, it's a variation in content.
You have to test that mobile hamburger
menu separately.
We would call that a variation in content.
A variation in presentation is something
more like this.
This is our website.
I can show you on the desktop site
that you've got all these services like this.
If you make it smaller, you can see
the services remain the same, but the
design changes.
The layout changes to 6x2 instead of 2x6.
That's a variation in presentation.
This little hamburger menu is a
variation in content.
Now you've identified your devices and
variations of pages to be tested.
Then you have to conduct the mobile testing.
We've broken the testing into 5 groups:
[Reading
on screen]
There are 5 testing mjdsMethods:
[Reading on screen]
The methodology goes into these in more detail.
Let's talk about the critical and
mobile-specific interoperability errors.
There are 5 traps under that.
We call them traps because they're
similar to what we'd see on WCAG2 on
desktop as a keyboard trap.
These traps are so serious that they
stop users from using systems entirely.
They often have to stop and restart
the browser.
The first one is a hover trap.
This is a desktop site on a mobile device.
If you looked at it on desktop and
moved over the dress, you get a zoomed
in portion over the screen.
On mobile, when you tap the dress, you
get the zoomed in portion, but there's
no way to get that portion to disappear.
You can't close it.
It overlaps the content.
You can't use the site.
We call that a hover trap.
This is an on-screen keyboard trap.
You've seen this before.
Your on-screen keyboard pops up.
There's nothing that you're meaning to
There's no way to dismiss it.
A lot of devices now have a way to
dismiss or close the on-screen keyboard,
but some don't.
One moment.
This is another example of an on-screen
keyboard trap.
It thinks that it's a text field
because it has an HTML type of text.
It's actually a dropdown.
Because it's a text field, it's pulled
up the on-screen keyboard.
It's overlapped the actual selection
instead of having it as a select box.
This is a screen reader swipe trap.
This is on LinkedIn.
They've fixed this.
You'd write a post, and you go to the
next page.
As someone who isn't a screen reader
user, you can post to public or connections.
If you're a screen reader user, you
can't read anything on this page, go
back, or forward.
We call this a screen reader swipe
trap.
This is a touch trap.
You scroll to the bottom of the page.
You often see this little arrow on in
bottom right corner that takes you back
to the top of the page.
These aren't always accessible.
About 10% of the time, the developer
has turned off the ability to swipe
using your finger .
As a visual user, this has nothing to
do with screen readers.
The only way to get off of this section
of the page is to activate that arrow or
a link.
You can swipe to drag back up to the top.
This is a zoom trap.
These don't happen as often anymore.
You see the map that says to use two
fingers to swipe or zoom.
The map takes up the entire screen
real estate of the mobile phone.
The only way to swipe up and down the
page is to get that small white area
outside the map.
If you hit the map, you end up moving
the map itself.
Those are the critical errors.
They're the big ones to look for.
Next, we look at mobile-specific
interaction, which includes things like
alternatives and keyboard accessibility.
Keyboard accessibility on mobile is
really important.
[Reading on screen]
This is a good example of incorrect
touch target and inactive space.
To open airbnb when looking at its
site, you have to hit that tiny little
gray red cross.
If you hit the icon, a couple pixels
to the right of it, you'll open the app.
This is a failure of both touch target
because the cross doesn't have a large
enough touch target, and inactive space.
There's not enough space between the
cross and activating the app.
This is another example of inactive space.
You have an edit and mark complete button.
They're the opposite of each other and
are next to each other.
This is problematic because you don't
have as much fine motor control on a
mobile device as on a desktop.
It's easy to hit something as marked
complete when you want to hit edit instead.
Use of color is important .
It's important to underline links on
mobile devices, your in-line links,
. With desktop, you can hover over
links to determine if it's actionable.
You can't do that on mobile devices.
This is using color alone for view and
release notes.
It needs to be underlined.
It's also important to indicate further
actionable items.
There's a theory that gray means inactive.
Here, you have gray text, add a
message, optional, add a name, etc.
That's not inactive at all.
Be careful about using gray to
indicate inactive content.
Don't use it to indicate inactive
content because people don't use gray
text at all because it doesn't meet
color contrast requirements.
Be aware that there's no scroll bar on mobile.
It's difficult to indicate additional
functionality by scrolling further down.
This is one of my favorite songs, "The
Chain" by Fleetwood Mac.
I'd get to the end of the song and
rewind it to the beginning.
I thought there must be a way to
repeat the song.
There is.
Scroll down to the repeat button.
Before you scroll down, it looks like
a complete page.
It looks like nothing's underneath it.
Indicate additional functionality
using an arrow or something.
That's definitely a good idea.
Text size is really important.
This is the Virgin app when I fly internationally.
In the bottom right-hand corner,
there's information about dates,
destination, local time, and origin.
Time, distance, etc.
[audio cut out]
When I access this site, I accessed it
on this app on an iPhone 6+.
I couldn't read the content in the corner.
I can read it now on a desktop screen.
This is an example of testing on a
simulator versus on a device.
I have 20/20 vision, but I couldn't
read that content.
If you're working with apps, be aware
that they inherit the text size from the system.
This is ABC.
On the left-hand side, that's what you
see when you specify that the iPhone has
the smallest possible text.
On the right is where the iPhone has
the largest possible text.
There's a difference.
You have to test both things.
Be aware that you need to inherit them
across the system.
This is the top of the article.
The left is the article with the
smallest screen and text size.
The right is the largest text size.
They look exactly the same.
You have to make sure there's
consistency across inheriting text size.
Be aware of reflow issues, ensuring that
things display properly.
This is addressed in WCAG 2.
1.
You want to avoid something like this
where your table is one letter large.
That's almost impossible to read.
Zero days allowed, reading one letter
at a time.
If you support reflow, make sure it
works properly.
This is the airbnb app with increased
text size.
site with increased text size.
They have a mobile site.
Airbnb says if the mobile site isn't
working, you can use the desktop version.
The problem is that it loses your
content, which is annoying, especially
if you've chosen a bunch of places.
Moving the content between sites, if
you have an [Inaudible] and desktop site
and really important.
Swipe isn't something all users can do.
This is the [Inaudible] site.
To get further down the page, it has
an arrow that says, "next.
" You can't tap that.
You have to swipe.
Then you'll get to the next page.
If you can't swipe,
some assistive technology can only
activate links, and you can't get past
that page.
This is another example.
Lufthansa.
It says to swipe to get to another link.
If you can't swipe, you can't enter.
This is another reason to test with real
devices.
This is a Qantas website.
They fly basically everywhere.
Most of their flights are domestic.
To fly from Sydney to Melbourne, it
lists absolutely every place that it
flies to, starting with Aberdeen, etc.
I don't know what those places are.
It took me 12 seconds to scroll to Melbourne.
If it takes me that long, it will take
someone with a disability minutes.
It will be completely inaccessible to
some users.
Also, be aware of expected behavior.
This is a Target website.
You select an ad.
It gives you this text that says that
your search for this item[
long number item].
] That's a bug in the system.
It's more common in mobile than
desktop because it takes up more screen
real estate.
People are unsure if they have the right page.
Expected behavior is really important.
Think about how people use your sites.
This is one of my favorite dress stores.
Its location is given in longitude and
latitude, which is difficult to input
into Lyft or Uber.
Think of how people will useare
actually going to use your system.
They need an address, not a longitude
and latitude.
Just one moment.
Unfortunately, when we book these
webinars, we don't take into account the
pollen in Washington, D.C.
I apologize for having to pause and cough.
The next thing to think about is mobile
and assistive technology support.
These are things like changes of state
and alternatives.
These are more important when doing
native app testing than mobile site
testing because in mobile site testing,
you can get alternatives and changes of
state pretty easily from HTML.
In native apps, you can't do that.
For example, what I mean by changes of
state are things like on jthis.
On the left-hand side, you have our
slide show playing.
You have a pause button.
That alternative should say, "pause.
" When you've paused it, that changes
to a play button.
That alternative should say, "Play.
" They often have the same alternative,
which is play/pause, which isn't helpful.
The recommended assistive technology and
devices combines we recommend are:
[Reading on screen]
This is what we recommend.
We're looking at the kinds of things
that we might need to change this to in
the next version.
Mobile and desktop relationship errors
are basically around how you need to
have the same content on mobile and
desktop .
This is Asana, which we don't use anymore.
When I did use it, it operated off of
my tasks constantly.
If it wasn't in my tasks, I didn't use it.
There's no my tasks on the mobile app.
or site.
I couldn't use it the way I wanted to
use it.
So, we moved to Trello.
If you're interested, tTrello did have
accessibility issues, but we've found
ways to work around them.
Be aware of things like broken functionality.
Christopher Burton is is one of my
favorite authors.
I finished his book on kindle.
Kindle asked if I wanted to rate the
next 20 pages of his next book.
I read it and hit the "buy now"
feature
ead the next 20 pages of his next book. I read it and hit the "buy now" feature.
It said the title wasn't available
for purchase.
Don't offer things to user that you
can't provide, especially on mobile.
If this happened on desktop, I could
search for this book elsewhere like a
different book shop.
I'm restricted to the Kindle Store.
If they don't have it, then I don't get it.
You don't want to offer people things
that you can't provide on mobile.
Lastly, non-specific mobile issues
common to mobile.
These are all WCAG2 things, but
they're things that people often forget
in terms of testing mobile.
We thought we'd add them here, as well.
These are things like:
[Reading on screen]
Things like pointer cancellation, which
is a failure of 2.
5.
2 on WCAG 2.
1 -- basically, the way that mobility
phones work is that you activate on
removal of touch.
If you tap your screen, the link
doesn't activate until you remove your finger.
For some reason, Kohl's changed that so
it activities on touch, not removal of touch.
If you swipe something I and hit South
Australia, and I just meant to swipe
down, it took me to the South Australia
stores.
They have several thousand stores in Australia.
This page lists all of them.
If I wanted to go to the top of the
page -- and there's no back to top link
-- it took me 16 seconds to scroll.
Pointer cancellation is definitely
something to look out for.
Movement that can't be stopped is a
failure of 2.
2.
1 timing adjustable.
This slide show doesn't pause.
Most people understand that slide shows
need a pause button on desktop, but they
don't understand that it's important on
mobile, as well.
It takes up a lot of screen real estate.
It's more confusing and distracting on
than on a desktop.
This is another reason to test everything.
This is K-Mart.
It says to shop our catalogues.
If you activate that on mobile, you
get a blank page because its' k'it's a
flash catalog.
iOS never supported flash, and it's
the most common operating system in the
western world.
This is another reason to test on everything.
Also think about consistency.
This fails 3.
2.
4 consistent identification.
You have a site in English, but you
have the JDPR content in another
language .
You don't know which is agreeing,
although you know which one is cookies,
because cookies is apparently the same
in that language as it is in English.
Be aware of meaningful sequence.
PjThe general population and people
with disabilities usually read only to
the submit button.
People who use assistive technologies
usually never get any content past the
submit button.
This is last Pass.
I started flying United For long haul
flights.
I'd put in my password to get the
credit card details to purchase
the WiFi.
I got this error: "No network connectivity detected.
" The problem is that u
nderneath the log-in button, there's an
option to log in offline.
That's something that you would expect
that you'd see, but you don't because
it's after the log-in button.
There are better ways to deal with this.
Instead of having this big error that
says there's no network connectivity
detected, you could ask if someone wants
to log in offline or just log in the person offline.
This kind of error is problematic in
different ways.
Again, this is more of an issue on
mobile than desktop because I could go
to the Last Pass site instead of the app
on desktop.
I have a bookmark.
There are different ways to get to
this content, but not on mobile.
iOS sometimes makes this mistake.
This is installing iOS 10.
At the bottom, there's an "install
now" grayed out.
I must have tapped that several times.
Why isn't this working?
It's because in tiny gray text on gray
background, it says that the update
requires at least 50% battery or to be
plugged in to power.
You could have it inactive or have a
pop up button that says that message or
not show the install now button at all.
Just have the text larger to be read
to say to charge your phone before you
can install this.
Color contrast is another big thing.
It's easier to change colors and
things like that on desktop than on
mobile for most people.
This is Amazon.
The most common thing people want to
do is to search.
The search here is gray text on white background.
What are you looking for?
This is problematic.
It means that many people won't be
able to see that or search.
Be aware of user of color.
This is Trello, which gives you a
thumbnail of the image in the top
section of the app.
There are little close buttons to
close the item in the top right hand corner.
It's white.
If the close button is on a white
image, you can't see anything.
Therefore, you lose the visual ability
to close that task.
Be aware of useless errors.
This is a Netflix error called error.
You have to provide error
identification around why something's an error.
Do I not have access because of the
time zone I'm in?
Have I not logged in properly?
Do I not have internet access?
That's an overview of the variety of
different tests that you can do.
We're actually going to be doing some
training of mobile training if you're interested.
One of them will be in Australia.
The other will be in Washington, D.C.
at the beginning of October.
We'll send you information about that
if you'd like to attend a one day
training course.
I'm
repeating this session this evening if
anyone's interested.
Let's go to questions.
SAm will send me questions.
am will send me questions.
Let me open the chat, as well.
[Laughter]
Thank you,
Graham.
Thank you, Lisa.
Absolutely.
Yes.
I will send you the PowerPoint presentation.
Blocking the PC link?
That's interesting.
Find out about the DC event.
I'll send a Dropbox link as well as the
PC link.
If you still can't get to it, let me know.
I'll send you the information.
Find out more about the DC event -- the
ICT disability testing symposium is late
September, early October.
I'll send you some information about that.
We're going to be doing the mobile
testing wrkshporkshop.
Let me get my calendar.
It's on September the 30th in DC.
I'll send that.
Thank you.
The automatic testing for mobile -- most
of the automatic reporting tools will do
mobile site automatic testing.
I'm pretty sure that DQ and Level
Access will have
automatic testing for mobile apps.
That's something that we're putting
into OzART in the next year or so.
There's not a lot that can be
automatically tested in mobile unfortunately.
Yes, the URL is the app URL.
Chris, I know what Percy's [sp?
] like.
That's why I don't live there.
I'll send the presentation to everyone.
Yes, it's OK to save the presentation.
I'll also send out a webinar.
I have a question.
[Reading attendee question]
Yes.
Sorry.
The 12 second slide is the one about
the Qantas app to search all the destinations.
You've got Sydney, a
Aberjeen, etc.
We saw that on Virgin where you have a
list of the alphabet on the right-hand side.
OpeIt opens it up to a full page.
[audio cut out]
On the other side, there's A through G.
You can select M for Melbourne and
scroll from there.
That's the best way to deal with that.
What's the difference between a native
and web mobile app?
Sorry.
Apologies if I didn't make this clear.
The mobile site is basically something
you look at on your browser on a mobile phone.
A native app is an app you download
from the store.
How can we test tool tips working
correctly on mobile devices?
Do you mean on native apps or mobile
sites?
x
sites?
The best way to is look at the HTML.
That's an Aria thing, so making sure
you're complaint with Aria.
Most automated accessibility testing
tools will automatically pick up if the
tool tip has been coded incorrectly.
Excellent.
Any other questions?
You're welcome.
Please feel free to reach out.
Now that I have You can reach us by y
enquiries.
Tweet at us.
We're more than happy to help in any
way.
I just saw another question.
I arrived late.
I'm not sure if this was covered.
Do I need to
[Reading question on screen]
Good question.
The answer is to test each variation
of the page.
If there's a variation that you caan
only access on mobile, then yes, you do
need -- sorry.
I got told I was too quiet.
Basically, you do need to test that if
you have things that are only seen on
mobile.
That's covered with the variations and
the page.
If there's a variation of the page that
you only see on mobile, in that case,
you'll need to test color and
magnification at that point, as well.
In some cases, you can do that on the desktop.
In most cases, you'll need to do that
on the device.
The methodology, the data methodology,
all the steps, all the requirements, are
on that presentation link.
I'll send it out as well as a document.
I'll send the PowerPoint as a
PowerPoint for people who don't have
access to that URL.
Any other questions?
[Laughter]
Thank you, Annette.
It's bizarre.
My doctor said I can't go outside.
I said it's allergies.
She's right.
I just can't go outside.
Thank you very much for bearing with me.
Apologies when my voice was going.
Hopefully, next time, I'll be
I'll be more able to talk.
I'll send everyone who's registered
the links.
I'll send a link to the present file,
but I'll assume that you can't access it.
I'll send an email with everything in
it, information about the training
session, a link to this webinar, and
links to the stats that I provided, and
the PowerPoint, and the methodology, as
well ozwiki access.
Excellent.
I think that's it.
Yes.
Please do email Sam at accessibilityoz.
com if you can't d'on't get anything or
something isn't working.
Thank you very much.
I'll Yes.
I'll send the recording.
Thank you, everyone.
I'll be in touch.
I hope you enjoyed it.
[End of meeting]