E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Jonathan Avila
Date: Wed, May 04 2016 5:32PM
Subject: Browsers handling more widgets nativelyUsingtitle attribute on non-anchor elements?
No previous message | Next message →

> 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > wrote:
>
> On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton < = EMAIL ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
> > > archives at http://webaim.org/discussion/archives
>

From: Sharron Rush
Date: Thu, May 05 2016 3:56PM
Subject: Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?
← Previous message | Next message →

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 ADDRESS REMOVED = ]
> Sent: Tuesday, May 03, 2016 6:23 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Jim Allan < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> wrote:
> >
> > On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton <
> = EMAIL ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
> > > > > > archives at http://webaim.org/discussion/archives
> > >
> > > at http://webaim.org/discussion/archives
> >
>
> ---------- Forwarded message ----------
> From: "Morin, Gary (NIH/OD) [E]" < = EMAIL ADDRESS REMOVED = >
> To: _mallory < = EMAIL ADDRESS REMOVED = >, WebAIM Discussion List <
> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ]
> Sent: Wednesday, May 04, 2016 3:06 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =
>
>
>
> ---------- Forwarded message ----------
> From: "Paul J. Adam" < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
> > > > > > > > >
>
>
> > > > >

From: Birkir R. Gunnarsson
Date: Fri, May 13 2016 5:41PM
Subject: Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = ]
>> Sent: Tuesday, May 03, 2016 6:23 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Jim Allan < = EMAIL ADDRESS REMOVED = >
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> wrote:
>> >
>> > On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton <
>> = EMAIL ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >>
>> >> >> at http://webaim.org/discussion/archives
>> >>
>>
>> ---------- Forwarded message ----------
>> From: "Morin, Gary (NIH/OD) [E]" < = EMAIL ADDRESS REMOVED = >
>> To: _mallory < = EMAIL ADDRESS REMOVED = >, WebAIM Discussion List <
>> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ]
>> Sent: Wednesday, May 04, 2016 3:06 AM
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: "Paul J. Adam" < = EMAIL ADDRESS REMOVED = >
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>> > >> > >> > >> > >>
>>
>>
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Brandon Keith Biggs
Date: Fri, May 13 2016 8:31PM
Subject: Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ]
> >> Sent: Tuesday, May 03, 2016 6:23 PM
> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
> >>
> >>
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Jim Allan < = EMAIL ADDRESS REMOVED = >
> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> wrote:
> >> >
> >> > On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton <
> >> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> To: _mallory < = EMAIL ADDRESS REMOVED = >, WebAIM Discussion List <
> >> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ]
> >> Sent: Wednesday, May 04, 2016 3:06 AM
> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: "Paul J. Adam" < = EMAIL ADDRESS REMOVED = >
> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
> >> > > >> > > >> > > >> > > >>
> >>
> >>
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Birkir R. Gunnarsson
Date: Sat, May 14 2016 5:40AM
Subject: Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?
← Previous message | No next message

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ]
>> >> Sent: Tuesday, May 03, 2016 6:23 PM
>> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: Jim Allan < = EMAIL ADDRESS REMOVED = >
>> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> wrote:
>> >> >
>> >> > On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton <
>> >> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> To: _mallory < = EMAIL ADDRESS REMOVED = >, WebAIM Discussion List <
>> >> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ]
>> >> Sent: Wednesday, May 04, 2016 3:06 AM
>> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> >>
>> >>
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: "Paul J. Adam" < = EMAIL ADDRESS REMOVED = >
>> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>> >> > >> >> > >> >> > >> >> > >> >>
>> >>
>> >>
>> >> >> >> >> >> >> >> >> >>
>> > >> > >> > >> > >> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.