WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Birkir R. Gunnarsson
Date: May 14, 2016 5:40AM

The survey is closed. We just never got the 4 hours it takes to remove
it and re-organize the website to display the results. It will be done
in the coming couple of weeks.
There is a list of links to examples below the text.




On 5/13/16, Brandon Keith Biggs < <EMAIL REMOVED> > wrote:
> 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.
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.