(unknown charset) RE: Skip to content link

Had to recall the elitist comment.
What you may not be factoring in is that for some it is not about tool 
options.
instead, perhaps understandably given their personal history, they  feel 
that 
*their* tool is what should be the only tool.
YOu must be disabled as I live disability, must do things as I do them, 
screen  readers are all that matter to access, or you are not getting a 
solution.
  Indeed about learning to use a tool. However,  consider just how 
much 
uniform understanding exists about the market, the economic resources 
available, even the negative associations with  the disability experience.
I mean I am writing from a country that for decades  legislated that those 
with disabilities are automatically a burden to society..and its Canada.
While I personally feel we will get their at some point, for now when the 
code  gets grounded in tool, i. e. we tested this with x, so you must use 
x or something is wrong with our ability to learn, its less easy to simply 
say  the user must work harder.
The code is a set of words, there are humans bringing their own 
dictionaries and experiences, well even   ideas of discrimination to 
interpreting  those words.
I recall when part of the adaptive field also included sitting down with a 
human in the same room to get the technology basics down.
Now, its a tutorial often in a space where you must already know how to use 
the  technology to reach.  or drafted with the assumption  you already 
know things, or worst yet in a room where one might feel embarrassed to 
seek help.
  Put in the time, sure, but those resources have to be there, factoring in 
the dignity and needs of an individual.  Perhaps even one new to living 
with the disability in question.
Kare



On Tue, 12 Mar 2024, Kevin Prince wrote:

> It's not the tool per se that we should be focusing on but ensuring that
> the code provides options to ALL users to choose tools and techniques
> that suit them.
> 
> The elitist comment is odd though - if you use a tool, and the code
> allows that tool to do its job, then it's not unreasonable to expect the
> tool user to invest some time in learning how to use that tool to the
> best effect. Sure, you can read a page by arrowing down an element at a
> time but as long as the code gives you headings, landmarks and that text
> is properly marked up then the code has done its job. It's not elitist to
> suggest that a person learn their tool: equally you can't dismiss their
> experience because they don't/havenn't yet learned all the bells and
> whistles but the answer is sometimes "you have to learn the bells and
> whistles to have a great experience - can I help you with that?" rather
> than rushing to fix code.
> 
> We can argue about UX of course (and I frequently do where it has a
> proportionately greater effect on AT users )
> 
> Kevin
> 
> Kevin Prince
> Product Accessibility & Usability Consultant
> 
> Foster Moore
> A Teranet Company
> 
> E kevin.prince@fostermoore.com
> Christchurch
> fostermoore.com
> -----Original Message-----
> From: Karen Lewellen <klewellen@shellworld.net>
> Sent: Wednesday, March 13, 2024 10:26 AM
> To: Kevin Prince <kevin.prince@fostermoore.com>
> Cc: Adam Cooper <cooperad@bigpond.com>; 'Tom Shaw'
> <tom-shaw@hotmail.com>; w3c-wai-ig@w3.org
> Subject: RE: Skip to content link
> 
> CAUTION: This email originated from outside of the organization.
> 
> 
> To be sure, I later saw your options comments.
> Still the use of equals at all suggests equal to.
> Actually my understanding is that the code is not about tool, but
> interaction. Meaning many use a number of tools to manage their
> interaction?
> Kare
> 
> 
> 
> On Tue, 12 Mar 2024, Kevin Prince wrote:
> 
> > Absolutely they can, I don't think I implied otherwise (and as
> > President of Deafblind New Zealand I wouldn't dareĆ°Y~S ). Maybe the ==
> > didn't come across as being Always and entirely equal to.
> >
> > Kevin Prince
> > Product Accessibility & Usability Consultant
> >
> > Foster Moore
> > A Teranet Company
> >
> > E kevin.prince@fostermoore.co
> > Christchurch
> > fostermoore.com
> > -----Original Message-----
> > From: Karen Lewellen <klewellen@shellworld.net>
> > Sent: Wednesday, March 13, 2024 9:47 AM
> > To: Kevin Prince <kevin.prince@fostermoore.com>
> > Cc: Adam Cooper <cooperad@bigpond.com>; 'Tom Shaw'
> > <tom-shaw@hotmail.com>; w3c-wai-ig@w3.org
> > Subject: RE: Skip to content link
> >
> > [You don't often get email from klewellen@shellworld.net. Learn why
> > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > CAUTION: This email originated from outside of the organization.
> >
> >
> > Kevin,
> > Perhaps I am naive, but why cannot a person end up with more than one
> > disability experience?
> > And, are there not several definitions of a keyboard user, i. e. one
> > using their keyboard to manage individual access needs?
> > Further, I am confused entirely by the screen reader users, as if all
> > users, and screen readers are uniform?
> > Karen
> >
> >
> >
> > On Tue, 12 Mar 2024, Kevin Prince wrote:
> >
> > > But keyboard users is not==screenreader users. And skip links are
> > > not
> > primarily for screenreaders users (who have a bunch of other tools).
> > >
> > > Kevin
> > >
> > > From: Adam Cooper <cooperad@bigpond.com>
> > > Sent: Friday, March 8, 2024 1:32 PM
> > > To: 'Tom Shaw' <tom-shaw@hotmail.com>; w3c-wai-ig@w3.org
> > > Subject: RE: Skip to content link
> > >
> > > You don't often get email from
> > > cooperad@bigpond.com<mailto:cooperad@bigpond.com>. Learn why this is
> > > important<https://aka.ms/LearnAboutSenderIdentification>
> > > CAUTION: This email originated from outside of the organization.
> > >
> > > As a screen reader user for about 20 years , I have never used
> > > either a
> > skip to link or a back to link to navigate a view because these
> > features are typically poorly implemented and support for conventional
> > implementations has been inconsistent during this time.
> > >
> > > By 'poor implementation' I mean mechanisms that don't actually move
> > virtual cursor focus, land on the same spot for every view regardless
> > of their content, land on the first natively focusable element in
> > content, skip past useful information, skip to irrelevant parts of the
> > screen, and so on ... the feature-presence checklist approach to WCAG
> > is much to blame here in my view.
> > >
> > >
> > >
> > > But, more importantly, why would I bother using a skip link when
> > > screen
> > reader applications provide much more efficient and diverse ways of
> > entering the content of a view ...
> > >
> > > people who are trained to use a screen reader in this country
> > > typically
> > don't use skip features either in my experience because their
> > navigational strategies - just like the functionality offered in
> > screen readers - is element based ... e.g., quick use key navigation
> > in JAWS-speak.
> > >
> > > Putting the very limited sample of the WebAIM SR users survey aside,
> > I'd be interested to know whether people who use a screen reader as a
> > result of a lack of functional vision actually use these features and
> > under what circumstances ... or whether this is just yet another
> > accessibility industry sacred cow.
> > >
> > >
> > >
> > >
> > >
> > > From: Tom Shaw <tom-shaw@hotmail.com<mailto:tom-shaw@hotmail.com>>
> > > Sent: Friday, March 8, 2024 12:12 AM
> > > To: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
> > > Subject: Skip to content link
> > >
> > > Hi there.
> > >
> > > I have a very long GOV.UK process with lots of pages. The first page
> > > I
> > activate the skip to content link and it works as expected, however,
> > for the rest of the hjourney users are now automatically taken to the
> > main content everytime because the anchor in the URL #main-content' is
> > always there. So it often skips the h1, hint text, back link
> > etc....therefore I'd say affecting SR and KO users. I understand this
> > is a potentially a backend mistake but I still feel this falls under
> > 2.4.3 Focus Order? Is this right?
> > >
> > > Thank you.
> > >
> > >
> > > Kevin Prince
> > >
> > > Product Accessibility & Usability Consultant
> > >
> > >
> > >
> > > E kevin.prince@fostermoore.com
> > >
> > > Christchurch
> > >
> > > fostermoore.com
> > >
> > > This email and its contents are confidential. If you are not the
> > intended recipient, you should contact the sender immediately, you
> > must not use, copy or disclose any of the information in the email,
> > and you must delete it from your system immediately.
> >
> >
> 
>

Received on Wednesday, 13 March 2024 01:06:12 UTC