Accessibility Basics for WebEd: Discussed approach, tone, focus, etc. and changes to organizational structure and emphasis, including:
Before and After Demo (BAD) for WebEd: The group liked the approach by Suzette. Encouraged keeping at least one section designed for users not comfortable looking at markup.
Eval Preliminary for WebEd: not updated since last week.
ACTION all: Shawn encouraged participants to make notes and changes to the wiki based on the discussion.
Application Notes: Shadi submitted for group consideration his revised framework for the development of Application Notes (they may end up with a different name). The development is estimated to result in 30-40 articles developed over 2 1/2 to 3 years and funded in part by the WAI-ACT Project. Group participants said progress had been made but there is still somewhat of a lack of clarity about the final format and purpose. Denis and Sharron submitted examples of work that may be similar.
ACTION all: Finally, Shawn announced that there will be no April 6th meeting due to holidays. She also reminded everyone to check action items, remembering that there are general action items at the top of the EO page and to update availability for future EO teleconferences and especially availability for potential Face to Face meetings. Please indicate which of the days are best around TPAC.
Shawn: At this point, we are assuming that we will meet at TPAC in November in Lyon. Still need to choose days. Everyone should fill in the survey. Six have said yes but there is split on dates.
... if we don't get enough to meet at any of the others, we should count on that one at minimum.
Shawn: Welcome back Liam, for a quick catch up on what we are focused on these days...the biggest news is that we have posted a couple of pages on the EO wiki to work on additions to the WebEd Community Group. One is Accessibility Basics and another is Evaluation. We have done some updates on these.
... there is another idea to use the BAD demo as a third contribution.
Shawn: We have also published Working Draft of WCAG EM
Shawn: so let's look at WebEd Accessibility Basics. Not yet published to the WebEd wiki, still working internally on EO
Shawn: Suzette, I have made some edits to the starting page of the Basics.
... Suzette started it off with a "taster" a bit of the content that works really well as an intro
Suzette: Looking through the changes you made Shawn, it looks greatly improved, thanks!
Shawn: If we look at the topics, does this look good, is anything missing, miscatagorized...?
Suzette: Not sure if the order is correct, just worked from the sequence on the WAI Basics page
Shawn: I wonder about the Business Case
Suzette: It is a good response to the question of why, it is an updated resource, effective.
Denis: Why put How to Meet out front - it is more complex, harder to understand. Why not start with the WCAG2 itself and then bring in How to Meet? As it is now seems illogical.
Sharron: Good point in terms of logic.
Shawn: I hesitate to link directly to WCAG2 from here since it and many other useful docs are linked from the Overview
Denis: Yes, makes sense to link to the Overview, At A Glance and then put WCAG2 documents.
Shawn: OK the proposal is to delete How to Meet from those documents.
... Denis, go ahead and remove.
... Thoughts on moving Essential Components?
Sharron: Good idea, OK w/me
Suzette: Yes, it leads logically into the next topic
Shawn: Should we link to ATAG and UAAG as well?
... I think you did have those links and I removed them.
... so that if people see this page, they know there are standards that apply.
Denis: Then present the supporting docs before the Overview
... for logical consistency
... if I go back to how I was trying to understand how they all related, it took a very long time to think about User Agents and Authoring Tools. it should come at the end.
Shawn: So the choice is to present all the pieces as a broad overview and then narrow the focus to WCAG. OR to start with WCAG in detail and add others near the end with the idea that and by the way there are also standards for authoring and user agents.
... I was thinking that especially ATAG needs to be included and even WAI-ARIA. They need to be in there somehow.
<shawn> RESOLUTION: adding ATAG, UAAG, WAI-ARIA
Sharron: Denis' point is good about being confused with the addition of ATAG and UAAG. But I come to another conclusion. Rather than looping it on as an afterthought, how about making a clear, consise but broad overview of all of the components. It may be useful in changing the way people approach it -- so web developers don't feel like accessibility is all on my plate. Introduce the idea that there's a whole suite of inter-related, mutually supportive guidelines.
... if our goal is to formulate the ideal way to educate people, I strongly feel they need the whole context, the big picture.
<shadi> +1 to sharron -- maybe mention other roles too (not only specs)
Denis: If I would have had the broader picture at the start, my understanding may have been quicker. If we do want to include all of these - ATAG, UUAG and WAI-ARIA, we need to work on the organization of what is here. Not just bullet list, but more clear instruction and setting of what we are presenting, who it is intended for, and how they relate. Could regroup in a tree structure.
<shawn> guidelines section:
<shawn> Authoring Tool Accessibility Guidelines (ATAG) addresses authoring tools
<shawn> Web Content Accessibility Guidelines (WCAG) addresses Web content, and is used by developers, authoring tools, and accessibility evaluation tools
<shawn> User Agent Accessibility Guidelines (UAAG) addresses Web browsers and media players, including some aspects of assistive technologies
Shawn: From the top, in the Guidelines section is above.
... Instead of titling that section Essential Components, call it the Big Picture
... anyone can make those changes
Denis: I will put my ideas for reorg beneath what is there now.
Sharron: good idea
Shawn: Or in the Discussion tab
Shadi: Didn't work well because people don't look at it, they all miss it. I always needed to point people to it in the body of the wiki anyway, so did not use much.
Shadi: Where to place Web and Older Users, a suggestion to place it within How People w/Disabilities Use... But that may lead to assumption that age is a disability. How about within Biz Case along with Mobile?
Sharron: Are you saying to put Aging and Mobile as subtopics in Biz Case?
Shadi: Not sure how flow would work, but that is the idea.
<shadi> +1 to shawn -- "older people" may be too big for *this* page
Shawn: Yes, seems like this section on Web and Older Users takes up too much of the page, would like it to be more streamlined
Suzette: It may be too big, but putting people with people seems more logical to me. In Europe age may be a bigger driver than disability. I want my people in one place.
Shadi: Maybe just mention that there are additional benefits within Biz case and refer them to the How People section as illustration of principles.
Suzette: The people section gives a good buy-in point for newbies. May not have met a disabled person but can relate to grandparents and older neighbors and friends.
Shawn: What if we had a section called Meeting the Needs of All ...that approaches from the point that when you do accessibility it meets unanticipated needs of age, mobile, etc?
Suzette: There is a lot of impetus behind inclusion of older users.
Sharron: Agree with the logic that people should be with people
Liam: Hesitant to offer too much until I have more of a context. It may be good to remember that this is geared to people who need to change their minds. Should use moral and inspirational elements.
Shawn: Audience is primarily toward existing developers.
... that probably have preconceived notions of what accessibility is.
Denis: The only thing that I would change for the moment is not to combine the two sections, Age and How People but put them near to each other rather than separated by Essential Components.
Shadi: I don't feel strongly about where it falls, I know there is sensitivity to depicting age as disability. But somewhere we should include Mobile Web users, perhaps in a header to catch attention.
Denis: Talkking about other groups that benefit without detracting from the central message...we could be talking about low literacy, second language issues, limited bandwidth and such. Do we want to go in that direction? Note all the people who benefit?
Shadi: It's totally OK to mention and we do have such a list in the Biz Case.
<shawn> http://www.w3.org/standards/webdesign/accessibility#case "Accessibility supports social inclusion for people with disabilities as well as others, such as older people, people in rural areas, and people in developing countries.
<shawn> There is also a strong business case for accessibility. Accessibility overlaps with other best practices such as mobile web design, device independence, multi-modal interaction, usability, design for older users, and search engine optimization (SEO). Case studies show that accessible websites have better search results, reduced maintenance costs, and increased audience reach, among other benefits.
<shawn> Developing a Web Accessibility Business Case for Your Organization details the social, technical, financial, and legal benefits of web accessibility."
Shadi: older people may need to deserve a bit more airspace in the document however because there is such widespread concern for inclusion of that group.
Denis: One of the ways to present may be a section called "Who Benefits".
<shawn> Web Accessibility Benefits People With and Without Disabilities http://www.w3.org/WAI/bcase/soc.html#groups
Denis: PWD first, Older Users next, Mobile Users, then a final paragraph with the four or five other, general groups. Leading to conclusion that directly or indirectly the majority benefit.
Sharron:I like that approach
Liam: If fewer user groups benefited would we still do it? are we making a utilitarian argument?
... regardless of whether you can lump together enough user groups to make a majority, there is something about the nature of the web that makes it important to think about accessiiblity in any case.
Shawn: As you are editing, please try to use documents that we have already vetted. We can start at least with language we have already used.
Denis: Sometimes hard to find just what you need in existing pages.
Shadi: We probably need a credits section to reference documents that we draw from.
Shawn: Yes we have started an acknowledgment section...do we need credit as well for who is wrting this page or is it enough to credit what documents it is drawn from?
Shadi: The documents, so that if people want more information they know where to go. Suzette put initals next to text she had written herself.
Sharron Can we return to Liam's question? Don't we need to remind people that access for all is essential part of the web (even though have the business case info there too). It is good to have Liam back. Can we agree that we need to include the idealistic, inclusive argument as the primary one?
Liam: There is something inherantly right, a moral good, regardless of how many people or what other groups may benefit.
Denis: If there is one organization that needs to have that argument, it is the W3C. At the same time, we need to have arguments that bring others along and who are more concerned with budgets than with humanitarian issues.
...But when talking about a business case, then by its nature you are talking about financial concerns, profit motive, inclusion in terms of markets and dollars.
<shawn> Liam: this is
Liam: But I understood the purpose of this is education for individuals not companies
Liam: best way to get to individuals is through the heart, most want to do good.
Denis: and it is a very strong message
Liam: Not sure I agree that if anyone should be making that argument, it is the W3C, which is an engineering and standards organization
Denis: maybe not, perhaps WAI
Shadi: Both aspects must be included. We do not need to shy away from the humanitarian message, should be forthright. But we can also give them the business benefits as a bonus.
Suzette: One of the reasons I want the people part as an argument is not a rationale for WHY we should do this, but a component of the design process that allows designers to understand who the users are. In this case, users are people with needs different than the developers themselves.
Shawn: A slightly different approach but meets the same goal.
Suzette: It is not part of explaining why, but part of developing the requirement specs.
<shadi> hmmm - interesting point
Liam: Maybe we don't need the business case in this set of materials.
Sharron: Agree that in this document with its focus on what is accessibility, may not be needed.
Shawn: Or could be inlcuded nearer the end.
... the exisitng article features it rather prominently.
Andrew: It makes sense to me to put it near the end.
Denis: If you want to take a look...
suzette: Is the revised structure: what, who, how, then convincing others
Shawn: Sorry Denis, not enough time right now...many items on the agenda, let's look later.
... Suzette, yes suggested pathway looks like a good one to try.
Shawn: We want to add to the Discussion tab thoughts on who is the audience, what is the purpose and goals to inform the development.
... when to move to WebEd? not yet, need to figure out the nuances of what we will do there, so let's wait.
Shawn: Don't have updated materials so will skip this item.
Shawn: From the application Overview and a sample teaching exercise developed by Suzette. Have people had a chance to skim through?
Suzette: In creating a learning excercise, I thought of naming tasks. Then analyzed notes as a support for setting out learning outcomes and defining an aim for the exercise. If using it for 16 to 18 year olds, I considered that they may be approaching without knowledge of code.
...So begin by opening inaccessible version, have them ask several questions and once they have done that, compare to the accessible version. Then look at annotations to see the differences between how they present the information.
Shawn: It's great to have a version that does not require coding and CSS experince and knowledge.
Suzette: It is more exciting to look at code and see the result of browser testing tools but that requires a lot of extra loading of software. It has the advantage of giving an option to play a bit more.
Shawn: What do people think of this approach?
<AndrewA> nice to provide a sample walk through for non-tech folks.
Suzette: May be too detailed, could move onto the tab that has forms on it. There are particular issues there that will be good to explore.
Andrew: The type of things that you have presented Suzette are very good for those without technical skills.
Denis: I agree with the need to have a lighter walk through for those who do not code.
... somehow two versions of a BAD walkthrough for those with and without coding expertise.
Suzette: Shadi, do you have an idea of how to present layout issues?
... some of the annotations for the Home page seem related to layout. Which would be the best to pick out?
Shadi: The News page has layout and structure issues that affect reading order...the code order won't match what is on the screen
... but honestly there is fairly little on visual layout. Wanted the versions to look similar so it is not heavy on that aspect.
Suzette: It is a bit difficult to convey the need to leave layout tables behind and take up CSS
Shadi: The different types of audience questions should be addressed as we build trainings around BAD. There might be various messaging with the demo.
Shawn: Is the audience question adequately addressed in the Overview?
Shadi: Probably not.
Shawn: Thanks Suzette, found it very useful.
Shawn: Next symposium will be on mobile accessibility. We are considering another one, linked from here. Customizing text.
... would prefer to keep the scope with a focus limited to how it is here defined, but recognize that contributions might be limited by such a narrow focus. Any ideas of people who might contribute?
Liam: We get frustrated about the research regarding line length and such that is based on screens that are nothing like what we use now. research is outdated...we may be interested.
Denis: I know a group from Montreal who may be interested.
Shawn: Shall I send the email to forward? or contact directly?
Denis: Send to me please.
Shadi: We talked about this at a previous meeting and I took an action to update the page and create a conceptual framework for Application Notes (name may change).
... the page should look more meaty and should have added some clarity about what it is and what is the purpose. So take a minute to skim and then I have a couple of questions for the group.
... based on this, can you imagine what it will look like?
Sharron: Much clearer. I like the term "library"
Denis: I'll tell you what I understand. Develop library of short focused materials. Are we saying we will take one specific Success Criteria (SC) and think of how many ways we can illustrate how to meet the requirements, what is the problem addressed, how does this technique meet, who is it for?
Shadi: We are trying not to get people to think about SC, why did you jump to that?
Denis: Because I understood that is what we have set out to explain.
Shadi: In fact, we want to get away from SC and be more practical.
... will discuss the relevant SC and perhaps speak more narratively about what it is and how to mark it up and then refer if necessary to the Techniques. More like what you would do if you were trying to explain to a colleague
Andrew: So is the plan to provide explanation beyond just the Success Criteria to include what might be considered Best Practice and/or Advisory Techniques?
Shadi: Had not yet thought of that too much. If we consider tables, for example, don't know if will there be just one article on tables or three or four. Organized by Basic, complex, etc? Essentials vs optimization? They may be mixed together...
Denis: Will we try to do them all at once or build more going forward?
Shadi: We have resources to develop this through EO and the idea is to develop the "authoritative" articles that are fully vetted through the W3C process. But then we put it out there and people can draw from these and create their own courses and tutorials.
... part of the WAI-ACT project. Potentially 30-40 individual "notes" to be developed over the next 2 1/2 to 3 years
Shadi: Some are simple and straightforward, others esp those organized by audience/roles will be trickier and take longeer.
Shadi: Don't want to set the number in stone right now , but if you can provide feedback on the framework it will be useful.
Denis: Do you have a rough idea about how the structure of the tutorial itself will be formed?
Shadi: Two types of formats - a tutorial, follow at home kind of step by step through exisiting examples. Other would be more abstract and conceptual application of WCAG. Would appreciate to hear your suggestion.
Denis: Looks very much like what we have done, starting with WCAG and presenting an overview of the challenges faced and how to meet them. For example, keyboard navigation. Look at barriers, what the solutions are. We have a format that is not as evolved as what you are talking about. I am happy to share it.
Shadi: There are many resources that already cover many of the things we will address.
... we beleive it will be good to have an authoritative version that elevates the discussion and that people everywhere can fully rely on.
<AndrewA> as an example, do we envisage something along the lines of Roger Hudson's 'forms' pages - http://usability.com.au/resources/wcag2/ ?
<shadi> this is for us to decide :)
Shawn: Please update, especially for F2F
Shawn: no meeting next week.
... thanks and goodbye
<AndrewA> have a good weekend all :)