WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?

for

From: Brandon Keith Biggs
Date: May 13, 2016 8:31PM

Hello,
I got lost and must have clicked the wrong button and now I can't take the
survey. I found the first question, then could not find what to click next.

Also, what kind of training should one have to become a SME?
Thank you,


Brandon Keith Biggs <http://brandonkeithbiggs.com/>;

On Fri, May 13, 2016 at 4:41 PM, Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> I can attest to the fact that Brooks makes downright unreal pan o baklava.
> In my 6 months or so of working with him I can also say that the man
> appears to possess a brain cell or 3, and know what he is talking
> about. *grin*
> Seriously, accessibility is a process that involves various players,
> and we need more conversation, training, development and solutions
> floating down the chain.
> We can't put it all on the website developer (which includes actual
> developers, content developers etc.).
> Me and my buddy CB Averitt did a presentation on this at CSUN
> http://whoseline.a11yideas.com
> I am working on taking the feedback from surveys, the examples and
> adding a personal thought or 3, as many as I can muster, to create a
> blog or a series of blogs about accessibility and the various players
> involved.
> This discussion serves as a great background and feeds in to my
> thought process behind the writing.
>
>
>
>
> On 5/5/16, Sharron Rush < <EMAIL REMOVED> > wrote:
> > Dear Brooks,
> >
> > Your observations are spot on and should be widely distributed. I may
> > disagree with you to some extent about the responsibility of the W3C
> > however. It seems to me that it is not only the regulatory bodies but the
> > W3C itself that has let slip the importance and interdependence of
> > consistent accessibility support in operating systems, user agents, and
> > assistive technologies. After all, the W3C is not just any "voluntary
> > agency." It is *the* standards making body for the web and if they do
> not
> > emphasize the interdependence, who can the regulatory bodies look to for
> > guidance? I see great opportunity for the work that has been done on UAAG
> > and ATAG to be brought to the attention of the legislators and
> regulatory
> > bodies with greater urgency and emphasis.
> >
> > Thank you for the prompt to raise these issues in the coming weeks as
> part
> > of the ADA SANPRM public comment process. Much appreciated.
> >
> > Sincerely,
> > Sharron
> > --
> > Sharron Rush | Executive Director | Knowbility.org | @knowbility
> > *Equal access to technology for people with disabilities*
> >
> > On Thu, May 5, 2016 at 1:00 PM, you wrote
> >>
> >>
> >> Hi Chaals,
> >>
> >> Thank you for taking the time to address my response to Deborah's
> comment
> >> about her desire for browsers to natively handle some of the WAI-ARIA
> >> functions. I know most folks on this thread just check in to find
> answers
> >> on "in the weeds" issues like, what browser supports this or what
> >> attribute
> >> works best for that. However, I think from time to time it's good to
> >> raise
> >> our heads up out of the weeds and take a gander at some of the bigger
> >> questions on the horizon that drive our industry. So thanks for
> engaging
> >> me and the others on this broader topic.
> >>
> >> Quick note about my background: I've been a professional in the Web
> >> business since 1998, having served worked in the U.S. in public schools,
> >> state agencies, private business (Web design agency owner for a dozen
> >> years), plus I've worked as the accessibility lead at what was the
> fourth
> >> largest company in the world, as well as having served as principal
> >> accessibility consultant for one of the big agencies in the U.S. and
> have
> >> served as a consultant for several other a11y agencies you likely
> interact
> >> with on a daily basis in your committee work. I also make a pretty good
> >> pan of baklava. You can ask Birkir about that.
> >>
> >> Believe you me, I have a distinct understanding of the complexities
> >> involved with getting accessibility to work well for people of all
> >> abilities. You can also ask Birkir about that, as well. I certainly
> don't
> >> have as a clear of an understanding as you have, but enough to be
> >> conversant in this context. I have significant experience transferring
> >> theoretical accessibility knowledge to real people who need real
> solutions
> >> to do their work accessibly in the digital trenches as web/software
> >> production team members. That's why I'm shocked that so much emphasis
> has
> >> been placed on site owners and their designers and developers to get
> >> accessibility right on their own, without the strongly regulated support
> >> from the operating system, user agent, and assistive technology
> >> manufacturing industry. Granted, I'm no lawyer. However, I've studied
> >> U.S. accessibility regulatory law - and let me tell you, there is a
> >> glaring
> >> absence of guidance for the software industry, when compared to the
> >> burdens
> >> that have been unloaded on site/app owners in this country.
> >>
> >> I'm sure you have done so, but for others on this thread, take a look at
> >> the provisions of the laws that exist in the U.S. and across the globe
> >> that
> >> govern web accessibility. U.S. laws or laws-in-progress, such as the
> >> Twenty
> >> First Century Communications and Video Accessibility Act (CVAA), the
> >> Section 508 refresh, and the ADA refresh go out of their way to exclude
> >> from obligations the three types of software manufacturers that have
> such
> >> as strong bearing on the ultimate accessibility of web/app based digital
> >> content. I'm not guessing about this just to have something to say or
> >> posturing for Internet karma. I've been on the hook to figure this out
> >> for
> >> some of the largest organizations on earth. And let me tell you, it is
> a
> >> darn impossible task to achieve accessibility without strong support
> from
> >> the software technology that we all depend on to get web and app data
> from
> >> the ether into our brains. Any others on this thread who feel the same
> >> way? Let your voices be heard as a follow-up on this thread. Better
> yet,
> >> let the U.S. Department of Justice know how evolving accessibility law
> >> should be handled by directly responding to the call of comments that
> will
> >> soon be forthcoming as part of the new ADA SANPRM.
> >>
> >> I've personally trained thousands (no exaggeration) of web site
> >> developers, writers, designers, information architects, rich media
> >> developers, business owners, quality assurance / user acceptance testers
> >> and c-suite executives on the ins and outs of digital accessibility. I
> >> have also personally consulted with dozens of the world's biggest
> >> companies
> >> on how to make their digital content more accessible. I've watched this
> >> industry mutate into its current state, which frankly, seems farther
> from
> >> the goal of universal access than it was 10 years ago. The answers
> being
> >> offered by those "in the know" for questions that arise out of
> frustration
> >> at how to make complicated digital interfaces accessible are
> increasingly
> >> technically obfuscated solutions that invariably involve lopping more
> >> responsibilities onto the site / app owners plate. Is that really the
> >> right direction? Look man, if we can't get site owners to write decent
> alt
> >> text, how are we going to get them to custom script complex interaction
> >> patterns, state switching, focus management, etc. for a bevy of
> JS-powered
> >> widgets they thought were plug and play ready to go? As they say in the
> >> U.S. South, I think I'm preaching to the choir here...not much need for
> >> additional persuasion on this point. These site owners need some help
> >> from
> >> software manufacturers in making standard and automatic many of
> accessible
> >> accommodations that are required to make rich Internet applications
> >> accessible.
> >>
> >> Chaals, I have a tremendous amount of respect for the work you and
> others
> >> have completed, in terms of evolving markup, defining standards and
> >> serving
> >> up resources to help folks make their content accessible. No
> complaints,
> >> only praise for that work. I am, however, deeply frustrated at how much
> >> of
> >> a gap exists between theoretical accessibility and actual accessibility.
> >> And, I think the majority of where that gap lies now has a lot to do
> with
> >> the fact that too much is being asked of site / app owners and their
> >> design
> >> and development teams, and not enough is being asked of the software
> >> manufacturers.
> >>
> >> I don't think the W3C WAI or other voluntary standards bodies have left
> >> software manufacturers out of the mix. I never said that. What I said
> is
> >> that legislators, regulators and some industry thought leaders have left
> >> them out of the mix. In my opinion, we will never see a groundswell of
> >> support for digital equality unless all of the relevant forces at play
> are
> >> required by law to do their respective parts. Software provided by
> >> OS/UA/AT
> >> manufacturers is very relevant to digital accessibility. It must be
> >> regulated to harmonize the efforts we are demanding of digital content
> >> owners.
> >>
> >> So, as Sarah kindly pointed out in her post yesterday, we are going to
> get
> >> another chance to chime on how U.S. digital accessibility law gets
> shaped
> >> as part of the new Supplemental Advanced Notice of Proposed Rulemaking
> >> (SANPRM) that has just been issued by the United States Department of
> >> Justice.
> >>
> >> http://www.ada.gov/regs2016/sanprm_statement.html
> >>
> >> This supplemental piece to the ADA relates to government agency
> >> obligations. This is particularly interesting, in terms of how we the
> >> people might be able to get our government to commit to holding software
> >> manufacturers to a high standard modern accessibility support. Let's
> speak
> >> up on this and other issues critical to driving universal access of
> >> digital
> >> content. We've got a chance to do this in the coming weeks as part of
> the
> >> ADA SANPRM public comment process.
> >>
> >> Over and Out,
> >>
> >> Brooks Newton
> >>
> >> -----Original Message-----
> >> From: Chaals McCathie Nevile [mailto: <EMAIL REMOVED> ]
> >> Sent: Tuesday, May 03, 2016 6:23 PM
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Subject: [WebAIM] Browsers handling more widgets natively Re: Using
> title
> >> attribute on non-anchor elements?
> >>
> >> On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton
> >> < <EMAIL REMOVED> >
> >> wrote:
> >>
> >> > Deborah,
> >> >
> >> >
> >> > I'm a big fan of your notion that WAI-ARIA functionality could be
> >> > natively made available in the browser. That brings up what seems
> >> > like the obvious missing key piece to truly ubiquitous accessible
> >> > digital content development, which is standardized support for rich
> >> > internet applications at the browser level. We already have a very
> >> > well understood set of display and interaction conventions associated
> >> > with how browsers handle old school HTML elements, such as radio
> >> > buttons or links.
> >>
> >> So the first issue here is that it isn't actually as well-understood as
> >> you might think. There is quite a lot of magic in browser code, and the
> >> people who wrote it can't always remember why they decided something 11
> >> years ago - or went to work somewhere else on something else, or…
> >>
> >> > I think we need a similar standardized playbook where browsers
> >> > manufacturers are required to abide by a set list of display and
> >> > interaction conventions that govern the user experience for the most
> >> > common <div> powered widgets, prevalent types of dynamic content, and
> >> > other advanced content constructs that are not currently natively
> >> > supported at the browser level.
> >>
> >> This is a *lot* harder than it sounds…
> >>
> >> > Wouldn't it be great if a browser could do the "heavy lifting"
> >> > involved with making, let's say, a tab panel accessible? With some
> >> > very basic markup in place in the page source code, and maybe a little
> >> > basic CSS, the browser would know how to handle things like input
> >> > focus management, switching a tab's programmatic state and visible
> >> > display, keystroke mapping, etc. in an automatic and standardized way
> >> > that all users would be able to quickly understand and act upon.
> >>
> >> Yep. There is even a spec that people are developing to try and make
> that
> >> possible: https://discourse.wicg.io/t/panels-and-panelsets/1184
> >>
> >> There are also at least two ways for browsers to present this stuff to
> >> screen readers, through ARIA.
> >>
> >> And yet, the interaction models - what keys or commands are needed and
> how
> >> a given user can set those up for their particular environment - are
> still
> >> basically a mess of dirty hacks that mostly work for most people most of
> >> the time.
> >>
> >> Which is a long way from being able to say "we got the accessibility
> story
> >> right".
> >>
> >> After a decade of serious work.
> >>
> >> > Some might say it is a bit burdensome to require browser / user agent
> >> > manufactures, not to mention operating system and assistive technology
> >> > manufactures, to natively support access to modern digital content.
> >> >
> >> >
> >> > I don't it is too burdensome at all. Consider that we are currently
> >> > asking, actually requiring by law in many scenarios, individual
> >> > site/app owners to do the "heavy lifting" and to develop accessible
> >> > modern digital interfaces using what amounts to experimental poorly
> >> > documented and erratically supported combinations of JavaScript, CSS
> >> > and ARIA. And in addition to coming up with this coding wizardry on
> >> > their own, content owners are supposed to magically arrive at a
> >> > commonly accepted set of implementation standards (real code snippets)
> >> > that will function consistently and facilitate adoption by the
> >> > browsing public? Give me a break!
> >>
> >> I agree with you that trying to push these requirements toward content
> >> developers is moving in the wrong direction. It is important to work out
> >> how to bring them toward browsers.
> >>
> >> But it is also a very difficult task, and one that unfortunately many
> >> people are prepared to ask others to work on without expecting that they
> >> should themselves engage with the complexities and join th search for
> >> solutions.
> >>
> >> > Leaving the software manufacturers out of the accessibility
> >> > responsibility equation really isn't working out that well, in my
> >> > honest opinion.
> >>
> >> I don't think they are left out, to be honest.
> >>
> >> > I think that our regulators, legislators and some industry thought
> >> > leaders have left the heavy lifting, in this particular case, to the
> >> > wrong team. The centralized position of the software manufactures
> >> > influence on accessibility, not to mention their economies of scale,
> >> > makes them the right folks to drive this type of standardization of
> >> > how rich content is handled, which will in turn raise energetic
> >> > support in the accessible content development community and
> >> > ultimately, will lead to widespread user acceptance.
> >>
> >> I'm inclined to agree with some of this, and disagree with other bits.
> >>
> >> Browsers and AT are, because of their relatively central position - in
> >> particular because there are relatively few of them who need to get this
> >> right - a good place to solve the problem. That's the sense in which
> there
> >> is an economy of scale.
> >>
> >> On the other hand, for some incredibly complex software that is called
> on
> >> by millions of different people to handle millions of wildly different
> >> tasks in wildly different situations, there are a very small number of
> >> browser engineers on the planet, and a tiny number who have a reasonable
> >> level of experience in accessibility.
> >>
> >> Worse, as noted above, some serious part of that experience is pretty
> >> painful, with all the lessons learned being that you can't just take
> what
> >> someone tells you because they are a self-appointed accessibility
> expert,
> >> and think it will work on a global scale, across the enormous diversity
> of
> >> users and requirements they never even imagined.
> >>
> >> > So, let's all get together some weekend, order some pizza and come up
> >> > with a top 50 modern design patterns (I pick modals, what would you
> >> > pick?), figure out a standardized way to accessibly code these chunks
> >> > of content so that the OS/browser/AT chain will render the information
> >> > in a way that facilitates functionality for users of all abilities?
> >>
> >> I'll take user interaction - how you create an application with a set of
> >> controls, communicate those to users, and connect them to things that
> user
> >> can actually do effectively. My current thoughts on that are best
> >> documented at
> >>
> >>
> https://discourse.wicg.io/t/accesskeylabel-author-accessible-info-about-shortcuts/1392/2
> >> and http://discourse.wicg.io/t/user-interaction-with-web-apps/1177 and
> >> there is more thinking in the discussions around aria-kbdshortcut.
> >>
> >> I don't manage to do so much on weekends, but I spend a lot of time most
> >> weeks on the problems.
> >>
> >> For things related to HTML, which is one *part* of the puzzle, we
> welcome
> >> more people thinking about how to describe the problems accurately and
> >> helping us imagine, test, reimagine, re-test, and maybe sometimes even
> >> accept as done, real solutions.
> >>
> >> > Wait a second, maybe that's not so good for job security as an
> >> > accessibility specialist. That would make accessibility too easy.
> >> > Never mind.
> >>
> >> I'd love to believe we can get it done in a couple of years. But I'll
> bet
> >> a lot of money that this isn't going to be a threat to the need for
> >> accessibility specialists in the next decade. So there's not even a
> >> down-side to trying :)
> >>
> >> cheers
> >>
> >> --
> >> Charles McCathie Nevile - web standards - CTO Office, Yandex
> >> <EMAIL REMOVED> - - - Find more at http://yandex.com
> >>
> >>
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Jim Allan < <EMAIL REMOVED> >
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Cc:
> >> Date: Wed, 4 May 2016 15:30:20 -0500
> >> Subject: Re: [WebAIM] Maps
> >> maps.google.com
> >> you can get generated walking directions
> >>
> >>
> https://www.google.com/maps/dir/2400+Guadalupe+St,+Austin,+TX+78705/UT+Darrell+K+Royal-Texas+Memorial+Stadium+-+Red+McCombs+Red+Zone,+Austin,+TX/@30.2873676,-97.7392205,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x8644b57807fd77eb:0xd00cf484f084511d!2m2!1d-97.7417024!2d30.2881238!1m5!1m1!1s0x8644b59a5ef97363:0x39c0803dfefc56a5!2m2!1d-97.7323506!2d30.2849094!3e2
> >>
> >> On Wed, May 4, 2016 at 12:41 PM, L Snider < <EMAIL REMOVED> > wrote:
> >>
> >> > I really like the idea Pamela mentioned, as it helps everyone...I have
> >> > found that sometimes I can't read the map because the thing is too
> small
> >> > (even after zooming), so the text gives me some way to figure out how
> to
> >> > get places or know where they are-especially on mobile or tablet where
> >> the
> >> > screen is small.
> >> >
> >> > I am sure others will add, but this text area is a welcome addition
> for
> >> all
> >> > viewers (like me!).
> >> >
> >> > Cheers
> >> >
> >> > Lisa
> >> >
> >> > On Wed, May 4, 2016 at 12:36 PM, Pamela Riesmeyer < <EMAIL REMOVED> >
> >> > wrote:
> >> >
> >> > > I don't know if this is a good approach, but we decided to add text
> >> > > versions to our campus map PDF as supplemental pages.
> >> > >
> >> > > So, for the example you sent, we would identify where the stadium
> is,
> >> > then
> >> > > where each section or area of interest is, relative to the others
> and
> >> to
> >> > > the boundary streets, etc.
> >> > >
> >> > > We approached this as if we were giving someone directions over the
> >> > phone -
> >> > > again, not sure if it is the best approach, but...
> >> > > --
> >> > > Pamela Riesmeyer
> >> > > Web Accessibility Coordinator
> >> > > Purdue University Northwest
> >> > > Calumet Campus
> >> > >
> >> > >
> >> > > On Wed, May 4, 2016 at 12:26 PM, James Bailey < <EMAIL REMOVED> >
> >> > wrote:
> >> > >
> >> > > > Hello All,
> >> > > >
> >> > > > I am encountering web pages or PDFs that include maps. And these
> are
> >> > > > detailed maps of several blocks of campus or sports events and I
> am
> >> at
> >> > a
> >> > > > loss to as to how make them accessible. A few colleagues have
> >> > > > offered
> >> > > > ideas, but I need to see some completed examples. I searched this
> >> list
> >> > on
> >> > > > "map" and got no returns. An example map may be seen (this is not
> an
> >> > > > accessible version) at
> >> > http://adaptive-tech.uoregon.edu/map_example.pdf
> >> > > >
> >> > > > Thank in advance.
> >> > > >
> >> > > > James
> >> > > > --
> >> > > > James Bailey M.S.
> >> > > > Associate Director
> >> > > > Accessible Education Center
> >> > > > University of Oregon
> >> > > >
> >> > > >
> >> > > >
> >> > > > > >> > > > > >> > > > > >> > > > > >> > > >
> >> > > > >> > > > >> > > > >> > > > >> > >
> >> > > >> > > >> > > >> > > >> >
> >>
> >>
> >>
> >> --
> >> Jim Allan, Accessibility Coordinator
> >> Texas School for the Blind and Visually Impaired
> >> 1100 W. 45th St., Austin, Texas 78756
> >> voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
> >> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Jonathan Avila < <EMAIL REMOVED> >
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Cc:
> >> Date: Wed, 4 May 2016 23:32:59 +0000
> >> Subject: Re: [WebAIM] Browsers handling more widgets natively Re: Using
> >> title attribute on non-anchor elements?
> >> > I personally think of "role=" as a interim state and not a good way to
> >> specify components. Just as role="Navigation" can be handled with a Nav
> >> tag,
> >>
> >> I'd generally agree that many interactions cannot be defined for a
> single
> >> role and a pattern module such as that used by UIAutomation or
> >> AccessibilityTraits in iOS is one way to address this. For example, we
> >> could end up with a situation where tabs also have checkboxes and we
> would
> >> want a tab role with a checkbox pattern or something like that to be
> >> communicated and understand by AT. Some patterns could arguably be
> >> confusing to the user however, so it might be worth considering before
> >> implementing such a thing.
> >>
> >> Jonathan
> >>
> >> Jonathan Avila
> >> Chief Accessibility Officer
> >> SSB BART Group
> >> <EMAIL REMOVED>
> >> 703.637.8957 (Office)
> >>
> >> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> >> Check out our Digital Accessibility Webinars!
> >>
> >>
> >> -----Original Message-----
> >> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> >> Behalf Of Jonathan Cohn
> >> Sent: Wednesday, May 04, 2016 9:13 AM
> >> To: WebAIM Discussion List
> >> Subject: Re: [WebAIM] Browsers handling more widgets natively Re: Using
> >> title attribute on non-anchor elements?
> >>
> >> I personally think of "role=" as a interim state and not a good way to
> >> specify components. Just as role="Navigation" can be handled with a Nav
> >> tag, I think that models that are using non-native tags should be
> >> regularly
> >> evaluated and determine how to transition the role= attribute into a
> >> standard that can then have proper tags created.
> >>
> >> Since I have not developed much HTML though perhaps I am just dreaming
> the
> >> impossible dream.
> >>
> >> Best wishes,
> >>
> >> Jonathan
> >>
> >>
> >>
> >> > On 3 May 2016, at 19:23, Chaals McCathie Nevile <
> <EMAIL REMOVED> >
> >> wrote:
> >> >
> >> > On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton <
> >> <EMAIL REMOVED> > wrote:
> >> >
> >> >> Deborah,
> >> >>
> >> >>
> >> >> I'm a big fan of your notion that WAI-ARIA functionality could be
> >> >> natively made available in the browser. That brings up what seems
> >> >> like the obvious missing key piece to truly ubiquitous accessible
> >> >> digital content development, which is standardized support for rich
> >> >> internet applications at the browser level. We already have a very
> >> >> well understood set of display and interaction conventions associated
> >> with how browsers handle old school HTML elements, such as radio buttons
> >> or
> >> links.
> >> >
> >> > So the first issue here is that it isn't actually as well-understood
> >> > as you might think. There is quite a lot of magic in browser code, and
> >> > the people who wrote it can't always remember why they decided
> >> > something 11 years ago - or went to work somewhere else on something
> >> > else, or…
> >> >
> >> >> I think we need a similar standardized playbook where browsers
> >> >> manufacturers are required to abide by a set list of display and
> >> >> interaction conventions that govern the user experience for the most
> >> >> common <div> powered widgets, prevalent types of dynamic content, and
> >> >> other advanced content constructs that are not currently natively
> >> >> supported at the browser level.
> >> >
> >> > This is a *lot* harder than it sounds…
> >> >
> >> >> Wouldn't it be great if a browser could do the "heavy lifting"
> >> >> involved with making, let's say, a tab panel accessible? With some
> >> >> very basic markup in place in the page source code, and maybe a
> >> >> little basic CSS, the browser would know how to handle things like
> >> >> input focus management, switching a tab's programmatic state and
> >> >> visible display, keystroke mapping, etc. in an automatic and
> >> standardized way that all users would be able to quickly understand and
> >> act
> >> upon.
> >> >
> >> > Yep. There is even a spec that people are developing to try and make
> >> > that possible: https://discourse.wicg.io/t/panels-and-panelsets/1184
> >> >
> >> > There are also at least two ways for browsers to present this stuff to
> >> screen readers, through ARIA.
> >> >
> >> > And yet, the interaction models - what keys or commands are needed and
> >> how a given user can set those up for their particular environment - are
> >> still basically a mess of dirty hacks that mostly work for most people
> >> most
> >> of the time.
> >> >
> >> > Which is a long way from being able to say "we got the accessibility
> >> story right".
> >> >
> >> > After a decade of serious work.
> >> >
> >> >> Some might say it is a bit burdensome to require browser / user agent
> >> >> manufactures, not to mention operating system and assistive
> >> >> technology manufactures, to natively support access to modern digital
> >> content.
> >> >>
> >> >>
> >> >> I don't it is too burdensome at all. Consider that we are currently
> >> >> asking, actually requiring by law in many scenarios, individual
> >> >> site/app owners to do the "heavy lifting" and to develop accessible
> >> >> modern digital interfaces using what amounts to experimental poorly
> >> >> documented and erratically supported combinations of JavaScript, CSS
> >> >> and ARIA. And in addition to coming up with this coding wizardry on
> >> >> their own, content owners are supposed to magically arrive at a
> >> >> commonly accepted set of implementation standards (real code
> >> >> snippets) that will function consistently and facilitate adoption by
> >> the browsing public? Give me a break!
> >> >
> >> > I agree with you that trying to push these requirements toward content
> >> developers is moving in the wrong direction. It is important to work out
> >> how to bring them toward browsers.
> >> >
> >> > But it is also a very difficult task, and one that unfortunately many
> >> people are prepared to ask others to work on without expecting that they
> >> should themselves engage with the complexities and join th search for
> >> solutions.
> >> >
> >> >> Leaving the software manufacturers out of the accessibility
> >> >> responsibility equation really isn't working out that well, in my
> >> honest opinion.
> >> >
> >> > I don't think they are left out, to be honest.
> >> >
> >> >> I think that our regulators, legislators and some industry thought
> >> >> leaders have left the heavy lifting, in this particular case, to the
> >> >> wrong team. The centralized position of the software manufactures
> >> >> influence on accessibility, not to mention their economies of scale,
> >> >> makes them the right folks to drive this type of standardization of
> >> >> how rich content is handled, which will in turn raise energetic
> >> >> support in the accessible content development community and
> ultimately,
> >> will lead to widespread user acceptance.
> >> >
> >> > I'm inclined to agree with some of this, and disagree with other bits.
> >> >
> >> > Browsers and AT are, because of their relatively central position - in
> >> particular because there are relatively few of them who need to get this
> >> right - a good place to solve the problem. That's the sense in which
> there
> >> is an economy of scale.
> >> >
> >> > On the other hand, for some incredibly complex software that is called
> >> on by millions of different people to handle millions of wildly
> different
> >> tasks in wildly different situations, there are a very small number of
> >> browser engineers on the planet, and a tiny number who have a reasonable
> >> level of experience in accessibility.
> >> >
> >> > Worse, as noted above, some serious part of that experience is pretty
> >> painful, with all the lessons learned being that you can't just take
> what
> >> someone tells you because they are a self-appointed accessibility
> expert,
> >> and think it will work on a global scale, across the enormous diversity
> of
> >> users and requirements they never even imagined.
> >> >
> >> >> So, let's all get together some weekend, order some pizza and come up
> >> >> with a top 50 modern design patterns (I pick modals, what would you
> >> >> pick?), figure out a standardized way to accessibly code these chunks
> >> >> of content so that the OS/browser/AT chain will render the
> information
> >> in a way that facilitates functionality for users of all abilities?
> >> >
> >> > I'll take user interaction - how you create an application with a set
> of
> >> controls, communicate those to users, and connect them to things that
> user
> >> can actually do effectively. My current thoughts on that are best
> >> documented at
> >>
> https://discourse.wicg.io/t/accesskeylabel-author-accessible-info-about-shortcuts/1392/2
> >> and http://discourse.wicg.io/t/user-interaction-with-web-apps/1177 and
> >> there is more thinking in the discussions around aria-kbdshortcut.
> >> >
> >> > I don't manage to do so much on weekends, but I spend a lot of time
> most
> >> weeks on the problems.
> >> >
> >> > For things related to HTML, which is one *part* of the puzzle, we
> >> welcome more people thinking about how to describe the problems
> accurately
> >> and helping us imagine, test, reimagine, re-test, and maybe sometimes
> even
> >> accept as done, real solutions.
> >> >
> >> >> Wait a second, maybe that's not so good for job security as an
> >> >> accessibility specialist. That would make accessibility too easy.
> >> >> Never mind.
> >> >
> >> > I'd love to believe we can get it done in a couple of years. But I'll
> >> > bet a lot of money that this isn't going to be a threat to the need
> >> > for accessibility specialists in the next decade. So there's not even
> >> > a down-side to trying :)
> >> >
> >> > cheers
> >> >
> >> > --
> >> > Charles McCathie Nevile - web standards - CTO Office, Yandex
> >> > <EMAIL REMOVED> - - - Find more at http://yandex.com
> >> > > >> > > >> > archives at http://webaim.org/discussion/archives
> >> > > >>
> >> > >> > archives
> >> at http://webaim.org/discussion/archives
> >> > >>
> >>
> >> ---------- Forwarded message ----------
> >> From: "Morin, Gary (NIH/OD) [E]" < <EMAIL REMOVED> >
> >> To: _mallory < <EMAIL REMOVED> >, WebAIM Discussion List <
> >> <EMAIL REMOVED> >
> >> Cc:
> >> Date: Thu, 5 May 2016 13:14:51 +0000
> >> Subject: Re: [WebAIM] Accessible Maps - Best Practices
> >> As a speech recognition software (Dragon NaturallySpeaking), imitating
> the
> >> mouse and keyboard are extremely difficult when encountering interactive
> >> maps. Yes, I can see a map visually but if I want to zoom in or select
> >> specific building or location on a map to then navigate to that specific
> >> information, I'm up a creak. It MIGHT be that the building, for
> instance,
> >> is a clickable icon on the map, but what is the command for it? Do I
> need
> >> to know what the alt-text is in order to tell Dragon "Click Main
> Building"
> >> or "Click Residence Hall A"? if there is no legend or glossary, which
> has
> >> to map to the alt-text and to the computer/web command line, I would
> have
> >> to spend all day guessing what the label for each location is.
> Similarly,
> >> in online training, I've tried "Click Next" to go from one screen to
> >> another, because the arrow on-screen was visually labeled Next; turns
> out
> >> that the code was Forward - I had to somehow know to tell Dragon "Click
> >> Forward".
> >>
> >> Accessibility - and assistive technology - is not just about vision
> loss.
> >>
> >>
> >> Gary M. Morin, Program Analyst
> >> NIH Office of the Chief Information Officer
> >>
> >> 6555 Rock Spring Drive, Suite 300, Room 3NE-28
> >> Bethesda, MD. 20817, Mail Stop: 4801
> >>
> >> (301) 402-3924 Voice, (301) 451-9326 TTY/NTS
> >> (240) 200 5030 Videophone; (301) 402-4464 Fax
> >>
> >> NIH Section 508: http://508.nih.gov, NIH Section 508 Coordinators list:
> >>
> https://ocio.nih.gov/ITGovPolicy/NIH508/Pages/Section508Coordinators.aspx
> >>
> >> NIH Section 508 Team: mailto: <EMAIL REMOVED>
> ?subject=Section
> >> 508 Help or, for Section 508 Guidance,
> >> http://www.hhs.gov/web/508/index.html
> >>
> >> Consider the environment. Please don't print this e-mail unless you
> really
> >> need to.
> >>
> >> WHAT IF THE FIRST QUESTION WE ASKED WAS, "WHAT IS SO UNIQUE ABOUT THIS
> >> SITUATION THAT IT JUSTIFIES EXCLUSION? INSTEAD OF, "HOW MUCH DOES IT
> COST
> >> TO MAKE IT ACCESSIBLE?
> >>
> >>
> >> -----Original Message-----
> >> From: _mallory [mailto: <EMAIL REMOVED> ]
> >> Sent: Wednesday, May 04, 2016 3:06 AM
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Subject: Re: [WebAIM] Accessible Maps - Best Practices
> >>
> >> Yeah, another large part of map accessibility is working with keyboard
> and
> >> keyboard-imitating AT, for example.
> >>
> >> _mallory
> >>
> >> On Tue, May 03, 2016 at 11:41:36PM +0200, Olaf Drümmer wrote:
> >> > > On 03.05.2016, at 16:30, Brian Lovely < <EMAIL REMOVED> > wrote:
> >> > >
> >> > > That seems like a real challenge. It may be that, rather than
> attempt
> >> to make a map accessible, communicate the information that the map is
> >> supposed to convey in the context of the page. For instance, if it is a
> >> map
> >> of a city showing surrounding towns, you could list the names of the
> towns
> >> and their distance from the city.
> >> >
> >> > isn't this advice specific to accommodation of vision impairments?
> >> >
> >> > Olaf
> >> >
> >> > > >> > > >> > archives at http://webaim.org/discussion/archives
> >> > > >>
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Caitlin Geier < <EMAIL REMOVED> >
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Cc:
> >> Date: Wed, 4 May 2016 10:00:15 -0400
> >> Subject: [WebAIM] Needed: Participants for testing accessibility
> software
> >> Deque Systems is looking for people who work in software and web
> >> development who can help us improve our products! We build products that
> >> help people and organizations make their websites, applications, and
> >> digital content usable for people with disabilities.
> >>
> >>
> >>
> >> We're looking to talk to people in these roles:
> >>
> >>
> >> - Developers
> >> - QA Analysts
> >> - Accessibility Specialists
> >>
> >> We are currently recruiting for interviews and usability tests - no
> >> accessibility knowledge required! If we meet with you, we will thank you
> >> for your time with a $50 Amazon gift card. Please visit this link to
> sign
> >> up: http://goo.gl/forms/lvbSfB361G
> >>
> >>
> >> Thank you!
> >>
> >> --
> >> Caitlin Geier
> >> User Experience Designer
> >> <EMAIL REMOVED>
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: "Paul J. Adam" < <EMAIL REMOVED> >
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Cc:
> >> Date: Tue, 3 May 2016 09:21:42 -0500
> >> Subject: Re: [WebAIM] Seeking input on SC 2.4.7 & Screen Readers
> >> I would say yes, focus visible is always required. The user could have
> low
> >> vision with a screen magnifier and screen reader running at the same
> time
> >> and then would need to see their focus location.
> >>
> >> Paul J. Adam
> >> Accessibility Evangelist
> >> www.deque.com
> >>
> >> > On May 3, 2016, at 9:06 AM, Nicole < <EMAIL REMOVED> > wrote:
> >> >
> >> > While I have been a long time lurker on this list, this is my first
> >> posting. I am hoping to receive some clarification on SC 2.4.7 (Focus
> >> Visible) as it relates to screen readers.
> >> >
> >> > In the application I am testing, visible focus is present when
> >> navigating through the submenu items (links) of a drop down/fly out menu
> >> in
> >> any browser being tested. When the HTML submenu link receives visible
> >> focus in the form of a dotted rectangle.
> >> >
> >> > However, when I enable JAWS or NVDA, this visible focus is lost. The
> >> link context and the ability to interact with the submenu links are
> still
> >> intact. It is just the visible focus that is no longer present. Being
> a
> >> sighted user, I 'see' this. My question is...does this constitute a
> >> failure for 2.4.7?
> >> >
> >> >
> >> > --
> >> > Nicole Bergstrom
> >> > Web Accessibility Consultant
> >> > Fairfax, Virginia
> >> > (c) 703-307-2438
> >> > (e) <EMAIL REMOVED>
> >> > > >> > > >> > > >> > > >>
> >>
> >>
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >